Talk:Brainstorming/Interoperability
From MyPaint
[edit] Plug-In Architecture
GIMP has a stable, well-defined plugin API. The developers go great lengths to ensure not to change any functionality that could be used by a plugin. How would a plug-in architecture work for MyPaint? The codebase is not very stable at the moment, and the straight-forward approach to implement a plugin-socket is to just expose the whole code. Plugins would be written for a specific MyPaint version, and could be broken with every minor release. Is this acceptable?
And what functionality would plugins offer?
That said, moving towards a plugin-based architecture might help to keep code that implements the same feature together in one place (for example, implement the menu entry in the same file as the feature).
--maxy 18:30, 26 July 2009 (UTC)
- In general, I guess there are two benefits of a plug-ins; modularity and "independence". If one doesnt have a stable plugin API, the latter is lost. But one still gets increased modularity which can be very nice.
- I can currently think of two candidates for "plugin-izing": GUI windows/popups and file importers/exporters. As far as GUI goes we have most of the infrastructure in place allready. The only thing that would be needed is to move actions/menu entries out to separate files, and to formalize the interface (if the files containing GUI windows/popups should have a specific name or placement and how its going to be imported and called). This will probably clean up gui/drawwindow.py significantly and make it easier to add new GUI elements.
- One challenge might be how to set up the menu entries from several places?--Jonnor 14:28, 18 August 2009 (UTC)
- I just looked into the relevant tech we are using (gtk.UIManager/gtk.ActionGroup), and this seems quite easy to do. Is there any reasons why we would not want to do this?
- If you are talking about internal use of modules: definitively no reason against it, it should help to clean up the code.
- If you are talking about a module system to be used by third-party developers: no, except that it's another piece of code that must be kept be working well, thought through, and maintained. You have to think about how to make it useful, how to document it, and how to maintain or not maintain compatibility through version updates (of both modules and of mypaint). I really hope there will not be a "module manager" window; in most applications that have such a thing, I hate it. It gives me the feeling that I should download some modules from dubious untrusted sources in order to get all good features.
- If all you want is to have a hook when the user drops something into ~/.mypaint/modules or similar (without any docu or compatibility considerations), then well... doesn't seem very useful to me, but doesn't hurt much neither. All it really would be is a simpler and slightly more limited way for the user to patch mypaint. Offering binaries/sources that contain the functionality would probably be just as easy for the users (since "modules" are tied to a single mypaint version anyway). --maxy 16:52, 19 August 2009 (UTC)
- I was very unclear and straying from the original topic, but what I mainly want to do is to refactor/modularize the code we have now in gui/. I think that especially drawwindow.py is too large and hard to navigate. It has the code for everything from setting up the UI (menu/actions), to filehandling (open, save, load, etc), to layers and brush manipulation. I think that setting up the UI from each popup/window that it will help a bit.
- Perhaps one should also sort the code by "behaviour/function" rather than by window. After all, often one is interested is a specific area of functionality, and don't really care about what other functionality happens to be implemented in the same window. Mainly I am thinking about trying to split out the parts containing filehandling, into a separate source file. And possibly layers and brushes if it turns out to be a good solution. Any thoughts? Just thinking out loud here --Jonnor 11:01, 20 August 2009 (UTC)
- I fully agree that drawwindow.py contains too much code, and for too many different/unrelated things. It would be very nice to clean this up. I agree that filehandling is an excellent candidate for this. maxy 16:58, 20 August 2009 (UTC)
