Stuff Michael Meeks is doing

* 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.