Stuff Michael Meeks is doing
Older items: 2008: ( J F M A M J J A ), 2007: ( J F M A M J J A S O N D ), 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
* Rational For the last week and a bit I have been re-writing the UI handler code, the fruits of my labours have been growing in CVS. But first, a summary of some of the problems I dimly remember with the old UI handler: a) Huge IDL interface, massive stubs / skel contribution b) No status bar support c) Doesn't allow menu / toolbar editing a-la MS Office d) No cmd / widget separation for menus / toolbars e) No Help Menu support f) Leaks memory around the place g) Out of order merging may be bad. h) Non expandable i) Nasty placeholders j) Broken paths with translations k) Broken position double accounting l) No K/B accelerator merging And probably some more I havn't discovered yet. Still, the old UI handler contained a large corpus of useful code, it was mostly frustrated by its API and structure. * Nice Features So; the new UI handler fixes most of the above and adds a lot of nice features people had requested, eg. Placeholders that can (optionaly) add separators at top and bottom when they are occupied. Also there is proto global keybinding support so many different components can merge keybindings into the same app. Another nice feature is the cmd / widget separation that Jody suggested to me. In fact, this makes it easy to make the whole thing editable. Either way, lets say we have an operation with id = 'Bold'. We have a toggle menu item and 2 toggle toolbar items with id == 'Bold'. Then when we toggle any of these all of them update their state. Another type of command is the 'Verb', all menu items and many single press toolbar items are implemented via verbs such as 'Open', 'Close', 'SaveAs' etc. This essentialy means that anything that can be done by the menu system can be automated via the CORBA API with no need to write idl. It also means that advanced features can be exposed as verbs an ( in future ) the user could add new commands into their menus and toolbars with a GUI ( much like office does ). * How it works The master model of the UI is stored in an XML tree internaly. As new toolbars and menus are merged into the UI the model is updated, signals are emitted on nodes 'overridden', 'reinstated', 'removed'. The merging code is separated into bonobo-ui-xml.[ch]. As the trees are merged dirty bits are set on nodes that have been altered. After the merge this information is used to re-build those parts of the UI that need it. Currently there is no dtd for the xml, however the source is rather trivial, and there are plenty of examples in my test case bonobo/test-app. I will be writing one ASAP. The tree can be queried and manipulated via a CORBA API, in addition to this controls can be inserted into the API. * State of play The UI handler is rapidly moving towards a stage where we can feasibly do a switch to it from the old code. I am however writing a compatibility API since this shouldn't be too tough and will make the transition far easier and sweeter. I have tagged CVS with 'BEFORE_NEW_UI_HANDLER' but this is simply to enable me to do some more destructive pruning of unused features in the old UI handler.