On Thu, 2008-01-03 at 08:55 -0800, Rob McMullen wrote: > On Jan 3, 2008 7:43 AM, Oliver <[EMAIL PROTECTED]> wrote: > > 4. Configurable menu/toolbar: the problem with many IDE's that > > provide extension points is that the UI does not define where the > > plugin's UI should go. E.g. I have seen editors/IDE where all > > plugin menu items go in one "tools" menu. > > Amen, brother. In addition, some IDEs populate the menubar/toolbar > with every possible item and just disable the inapplicable items. > This is much more cluttered than simply leaving out the items that > don't apply to the sort of text file you're editing. Emacs does a > good job by dynamically modifying the menu depending on the major mode > and is what I tried to duplicate. > > This was not as easy is I had hoped -- I even tried a constraint > solver to allow plugins to define what menu items they came before or > after. I don't have a great solution to this currently, as the items > insert themselves at some location in one of the menus at a default > position, with the idea that there will be a menu location editor at > some point where the user can reposition everything at will. > > > So the goal must be to provide an architecture that > > allows developers to combine efforts. > > Indeed, that's the problem. But it's a big one. A flexible > architecture is extremely difficult to write, which is why everyone > (myself included) seems to start out writing a flexible architecture > but ends up constraining themselves and and making choices that limit > the flexibility in order to get something working. > > > I'll see if I can go over the interface of a few IDE/editors and give > > concrete examples of the above, that should show whether any of it > > makes sense in practice :)
PyGTK has the ability to modify menus and toolbars on the fly. It merges snippets of XML from various sources (in this case plugins), and can unmerge them. The user interface builder Gazpacho has a facility to edit this XML from a UI.
