On 24/10/11 01:30, Manuel Quiñones wrote: > I would like to open discussion on making a plug-in system. What > do you think? Is this in MyPaint's plan? I would like to code it if > there is consensus.
I'd like a plug-in system, but we'd need to define the interface quite tightly, or at least set some goals. How do you envision it working? Some handwaving and possible stumbling blocks: - we currently have a semi-pluggable system that allows individual tool windows to be loaded based on their name. IMO this is too minimal for a plugin system, and needs improvement (and disentangling from the sidebar horror in gui/layout.py) - I want to push for GtkBuilder UI defs (marginally pluggable) plus UIManager defs (highly pluggable, and we do it already in the toolbar) as the main way of defining UI. I hate writing boilerplate GTK code :) - how do you envisage a plugin adding to or overriding core behaviour, if it needs to? Lots of named hooks everywhere? Some sort of bus-like subscribe/publish rearrangement of the observers schemes in use? - I'd rather have some sort of plugin-manager responsible for the loaded plugins list, merging and demerging UI, and hooking/unhooking/whatever the core behaviour rather than letting plugins monkeypatch core behaviour themselves. - Plugins need pretty icons :) so that's something you have to expose along with a name, description, prefs editor if needed. Basically a plugin turns into a small distributed package of stuff. Suggestions of how to organise such a thing welcome! Would a package directory with an __init__.py exposing all of the above via its __all__ suffice and permit enough flexibility? It would be good to make distribution - Plugin code has to not bomb. If it does, the plugin should be unloaded as gracefully as possible. - Version checking for compatibility: useful? - How do we handle localisation for plugins? -- Andrew Chadwick _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
