Bonobo UI handler work ...

[Michael Meeks <michael helixcode com>]

Hi Miguel,

	I just wrote a load of blurb explaining my recent work on the UI
handler...

* 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 ( in no particular order ):

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

        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. I implemented a
K/B accelerator merging function so multiple components can add
accelerators to the main 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.

* What is happening now

	I have had a large number of suggestions from Torsten of Sun fame,
which I will be thinking hard about and changing some of the IDL and
working out how best to deal with merging controls. I would very much
appreciate scrutiny of my design and comments on it. I am also considering
how best to deal with user customization of everything from layout to
accelerators.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot