[Geany-devel] Keybindings for GeanyPy

Matthew Brush mbrush at xxxxx
Sat Aug 6 05:28:29 UTC 2011

On 08/05/11 21:32, Lex Trotman wrote:
> On 6 August 2011 14:11, Matthew Brush<mbrush at codebrainz.ca>  wrote:
>> On 08/05/11 21:01, Lex Trotman wrote:
>>> [...]
>>>>> Otherwise I guess it "shouldn't" be too hard to add the extra
>>>>> functionality to Geany but getting stuff from the module is spread
>>>>> around a bit and you would need to be sure the module wasn't unloaded
>>>>> unexpectedly as well.
>>>> How can it be unloaded?
>>> Well I didn't read plugins.c in detail but I suspected that ATM when
>>> you deactivate a plugin in the plugin manager it will unload the
>>> module, but that would be bad for a shared module.
>>> In fact seems to close and re-open whenever you toggle the activate
>>> checkbox, see pm_plugin_toggled() calls plugin_free() which closes the
>>> module.
>>> Just means that you need to be careful when you patch it that the
>>> Python plugin isn't unloadable without unloading all its dependent
>>> plugins.
>> I think it'll be ok if it's using g_module_make_resident[1], which should
>> ensure that first Python interpreter (libpythonX.X.so) would never get
>> unloaded, and so always be Py_IsInitialized().  Basically, I don't care if
>> you can't reclaim your XX megabytes of RAM until you restart Geany :)
> Sounds fair, I havn't used more than about 2Gb of my 4Gb that I have
> noticed, despite firefox's best efforts.
> BTW what are the restrictions on what Python can be used when Geany
> calls a Python callback, I guess everything has to be a function that
> runs to completion.  Can it be a closure, can it use yield, can it use
> threads, can it do async I/O so as not to block Geany?

I forgot to mention, for callbacks, I was thinking of using 
PyGTK/Gobject-introspection on the GeanyObject which has all the signals 
on it (IIR).  So plugins would do:

     geany.object.connect('document-open', on_document_open_handler)

And so on...

Matthew Brush

More information about the Devel mailing list