On 2016-05-17 04:24 AM, Thomas Martitz wrote:<br>
> Am 17.05.2016 um 02:40 schrieb Matthew Brush:<br>
>> IMO, we shouldn't abuse GBoxed like that. Would be better to fix<br>
>> upstream to work properly than spread bug-generating hacks all over.<br>
>> Isn't there also some kind of annotation comment that can be used to<br>
>> hint gir-scanner that the parameter is just a raw pointer with a<br>
>> |G_TYPE_POINTER|?<br>
>><br>
><br>
> Using G_TYPE_POINTER subtypes has absolutely no benefit, apart from<br>
> being slightly "prettier" from a design POV.<br>
><br>
> However, you know upstream bug report[1] which is largely ignored. I've<br>
> been told that if I want this fixed I've got to do it myself. GI* stuff<br>
> is largely in maintainace mode with little development.<br>
><br>
> I've looked into the code and I won't be able to implement this support<br>
> any time soon. It's really a lot of code to change.<br>
><br>
> And then it would have to be reviewed and accepted which would take<br>
> months, and then years before the fixed program versions reach users<br>
> through updated packages.<br>
><br>
> Since there is no technical benefit I don't see the point of investing<br>
> so much of my time into that and delay deployment of my peasy plugin for<br>
> some years.<br>
><br>
<br>
There is a technical benefit, you just don't see it yet because there's <br>
no body of plugins to actually show the problem in real life. The very <br>
fact that you can't return `NULL` from the boxed copy function shows <br>
that PyGI is snarfing away what it thinks are copies of these objects <br>
when in reality it's only getting weak/unowned pointers to them.<br>
<br>
For example, what happens when a plugin stores a GeanyDocument in a <br>
list/dict/variable for longer than the document is open?<br>
<br>
Is there not some annotation comment or override you can use to guide GI <br>
to the right conclusions? I thought it had some mechanism for this, and <br>
it would be a lot better to add hacks and workarounds in the form of <br>
comments/meta-files than to the source code.<br>
<br>
>> I'm not super fond of exposing the GeanyObject either. IMO, if it /must/<br>
>> be exported to make this work, we shouldn't add Doxygen comments so it<br>
>> remains "private" and we can drop at will whenever we get around to<br>
>> moving those signals to the correct objects.<br>
>><br>
><br>
> Why that? My peasy plugin is a normal plugin and wants to use standard<br>
> Geany APIs. I thought if plugins require new APIs we consider adding them?<br>
><br>
<br>
But like the GBoxed hack, the only reason you need to expose this object <br>
in the plugin API is because of a limitation in some code generator <br>
tool. The signals on GeanyObject are already exposed to plugins.<br>
<br>
> Are there specific plans to "moving those signals to the correct<br>
> objects"? These object don't even exist. Unless there are plans to<br>
> change the status quo in the near future I think we should just expose<br>
> what we've got currently.<br>
><br>
<br>
Eventually it would be nice to fix this up (see all the threads about <br>
GObjectification of parts of the plugin API). If we expose it publicly <br>
now, we can never do that later.<br>
<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly or <a href="https://github.com/geany/geany/pull/1038#issuecomment-219734668">view it on GitHub</a><img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ4HwTjPXAbSIN3gQ-di1714y2mOUks5qCdA7gaJpZM4Ifw_7.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/pull/1038#issuecomment-219734668"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>