G'day,
Ali Afshar wrote: <snip>
This looks really interesting. I was a bit put off by this when I investigated because I was worried of wxPython dependencies. I admit I didn't look particularly hard, and missed that the core probably has no UI toolkit dependencies. Browsing through the code there seems to be support for wx and qt4, which bodes very well for extending to other toolkits, and not relying on a single one.
You're exactly right - the core has no notion of GUI whatsoever... the 'workbench' plugin is where the GUI comes in and as you say we currently have support for both wx and qt4.
I like the use of decorator syntax to register for extension points, but I have slight reservations. They are very neat, but when does the registration occur? Is it possible to register entire objects as providers? Is it possible to register providers at run time?
There is no real 'registration' as such... When a plugin (or in fact any object) asks the application for the contributions to an extension point then an Envisage application scans all of its plugins looking for methods marked with the decorator, calls them, and concatenates all of the results...
In my opinion, this is not entirely the level of "plugin" we want to formalize for Pyxides. For sure it will be necessary for the core of any implementation to use something like this, but there is no need that everyone use the same system. If I am imagining Pyxides as IDE framework, we will need a higher level of plugin in addition to this level. But perhaps I am imagining too much!
Maybe, but your 'contribution methods' (those marked with the decorator) can return objects at any 'granularity' from strings to say, 'syntax highlighters'... Martin
