[Github-comments] [geany/geany] Gi signals (#1038)

Matthew Brush notifications at xxxxx
Tue May 17 14:27:07 UTC 2016


On 2016-05-17 04:24 AM, Thomas Martitz wrote:
> Am 17.05.2016 um 02:40 schrieb Matthew Brush:
>> IMO, we shouldn't abuse GBoxed like that. Would be better to fix
>> upstream to work properly than spread bug-generating hacks all over.
>> Isn't there also some kind of annotation comment that can be used to
>> hint gir-scanner that the parameter is just a raw pointer with a
>> |G_TYPE_POINTER|?
>>
>
> Using G_TYPE_POINTER subtypes has absolutely no benefit, apart from
> being slightly "prettier" from a design POV.
>
> However, you know upstream bug report[1] which is largely ignored. I've
> been told that if I want this fixed I've got to do it myself. GI* stuff
> is largely in maintainace mode with little development.
>
> I've looked into the code and I won't be able to implement this support
> any time soon. It's really a lot of code to change.
>
> And then it would have to be reviewed and accepted which would take
> months, and then years before the fixed program versions reach users
> through updated packages.
>
> Since there is no technical benefit I don't see the point of investing
> so much of my time into that and delay deployment of my peasy plugin for
> some years.
>

There is a technical benefit, you just don't see it yet because there's 
no body of plugins to actually show the problem in real life. The very 
fact that you can't return `NULL` from the boxed copy function shows 
that PyGI is snarfing away what it thinks are copies of these objects 
when in reality it's only getting weak/unowned pointers to them.

For example, what happens when a plugin stores a GeanyDocument in a 
list/dict/variable for longer than the document is open?

Is there not some annotation comment or override you can use to guide GI 
to the right conclusions? I thought it had some mechanism for this, and 
it would be a lot better to add hacks and workarounds in the form of 
comments/meta-files than to the source code.

>> I'm not super fond of exposing the GeanyObject either. IMO, if it /must/
>> be exported to make this work, we shouldn't add Doxygen comments so it
>> remains "private" and we can drop at will whenever we get around to
>> moving those signals to the correct objects.
>>
>
> Why that? My peasy plugin is a normal plugin and wants to use standard
> Geany APIs. I thought if plugins require new APIs we consider adding them?
>

But like the GBoxed hack, the only reason you need to expose this object 
in the plugin API is because of a limitation in some code generator 
tool. The signals on GeanyObject are already exposed to plugins.

> Are there specific plans to "moving those signals to the correct
> objects"? These object don't even exist. Unless there are plans to
> change the status quo in the near future I think we should just expose
> what we've got currently.
>

Eventually it would be nice to fix this up (see all the threads about 
GObjectification of parts of the plugin API). If we expose it publicly 
now, we can never do that later.



---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1038#issuecomment-219734668
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.geany.org/pipermail/github-comments/attachments/20160517/ffa8c309/attachment.html>


More information about the Github-comments mailing list