On 12 February 2013 20:45, Andrew Chadwick <[email protected]> wrote:
> I've pushed a simple plugin framework to > > https://gitorious.org/~achadwick/mypaint/achadwick-mypaint/commits/plugins > Sorry for no reply. Picking it up now, since the topic was (already) brought up at LGM. > temporarily. Can I get some quick code review / opinions about whether > this is the right approach? I figured based on what Maxy said that > plugins would hook objects and callbacks into the running app via API > calls, accessed via the app singleton, but suggestions about how to > expose the entire Python API as an importable thing in plugin code via > a nice module name would be most welcome :-) > No objections from me, though I am not a big believer in (third-party) plugins for solving problems on the UI level. But being pragmatic, it allows people to just start hacking on MyPaint related thing without worrying about upstreaming, which may lower the barriers a bit, which is good. Since we are not making any promises on API, I think scripts and plugins should be required to specify the version of MyPaint they expect. That way we can at least warn (maybe error?) about likely incompatibility when using a different version than expected. Having Python module importable in scripts, especially the lib/ portion could be very useful I think. Here is a possible approach: - Install a wrapper "mypaint" Python module to the standard location. It exposes one method which will put the real MyPaint Python code on the path and import it, after consumers have declared what version they expect. Example usage: import mypaint mypaint.require("1.2") mypaint.lib.something() and mypaint.gui.something() # only accessible on mypaint after doing require Ideally it should be possible to also run/test scripts in the same way against the source tree by setting PYTHONPATH before above code. Plugins should be fairly safe, and not bomb out the application due to > ImportErrors during plugin activation and deactivation. This means > that MyPaint itself doesn't need to depend on some random lib just to > get extra functionality with an optional core plugin - the plugin > activation will just be observed to fail to load. We could perhaps do > with more feedback for the user, but the little dialog in the above > branch seems to work for now. > I think it would be very useful if the exception dialog could detect if an exception involved a plugin. In that case it I think it should say something like "Exception detected in plugin FooBarPlugin. Try to disable the plugin using the plugin manager to see if the issue goes away, or contact the plugin author". > One thing it might be nice to break out into our first set of core > plugins would be a file format mini-API, for filehandling.py. Consider > a layered .PSD loader done with PIL or something else: > http://stackoverflow.com/questions/6759459/python-psd-layers has a > quick HOWTO. > If we do this, the code in MyPaint for file handling should use the same API. That way it gets testing and maintenance in the mainline. I would think the API would be (mostly) on the lib/document.py level though, with only "registration" of the plugin happening in filehandling.py? Fancy extra tool subwindows, actions, overlays and modes would be nice > to make pluggable eventually. > > Selection buffers and other things that look like layers might be > tricky :) Still, we already have a couple of special layers; perhaps > somebody who understands that bit of the code could make a selection > tool for slicing and dicing. > > Is there anything else that's sort of optional that could be stripped > out of the static code code and into a plugin module? > -- Jon Nordby - www.jonnor.com
_______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
