Re: Broken i18n and the new UI handler.

[Havoc Pennington <hp redhat com>]

[people who didn't see the original post on gtk-devel-list see
bonobo/doc/ui-handler.txt]

Michael Meeks <michael helixcode com> writes:
> 
> 	I just noticed this monster thread on Gnome-hackers, and people
> talking about what I've been doing which is exciting:
>

If you're going to rewrite how all gnome apps do menus you should
maybe consider posting to gnome-hackers and gtk-devel-list ;-)
It looks like you have a pretty good plan.

> 	Ah; but of course, I killed the GnomeUIInfo too [ although
> there is a compat API that tries its best to convert it to XML; my
> current scheme expresses a menu thus:
> 
>         <menuitem name="New" verb="FileNew" _label="_New"
> 	_descr="Start a new document" pixtype="stock"
> 	pixname="Menu_New"/>
>

Which is, note, valid for the GMarkup parser I proposed for GLib.

Can you explain how "name" is different from "_label"? Is "name"
guaranteed unique for the menu item?

Why not specify the GtkAction/QAction part separate from the menu
item? i.e.

<action id="New" verb="FileNew" _label="_New" _descr="Start a new document"
 pixtype="blah" pixname="blah"/>

<menuitem action="New"/>
<button action="New"/> 

etc. Do you have a plan for this already? I'm not sure if actions and
verbs are exactly the same or not (so a verb is essentially a 
void (*do_verb)(void) callback with no args, an action is that plus
a bunch of info on how to display it).

One thing I haven't seen you mention is sensitivity; this should be
shared by all items displaying the same verb or action. So
set_sensitive(verb, TRUE) affects all the items.

Also, of course radio groups should be on the level of action/verb,
not on the level of menuitems and buttons, so some way to say which
things are exclusive. Probably you have that already.

Another issue is that later we likely want to add some way to specify
"extra" help, probably an URL for the help browser invoked by the
magic What's This pointer.

> 	etc. The UI ( menus / toolbars / status / keybindings ) is
> loaded from an XML file so that the user can edit their ui with
> impunity, not just the keybindings.

It's important to also support loading it from a string in memory,
some apps (embedded no-filesystem apps for example), will have reason
to do that, and it's trivial to support.

> Oh; and the 'name' string is never
> translated so you always get a reliable path to your menu:
> 
> 	/menu/submenu/#File/menuitem/#New
> 
> 	or somesuch.
> 

What does the # mean?

> 	Sure; but the thing is I just totaly re-wrote it and it is well on
> the way to being imeasurably better, and horribly extendible.
>

It looks like the right approach.

Are you keeping a separate, unstructured pool of verbs, from the
merged menus?

i.e. I would expect to see an amorphous hash from verb names to action
objects and callbacks, then trees for display that were the "view" for
the actions (which are the model).

Reason being, in your app you shouldn't have to care about the tree
structure at all, except in the case where you dynamically insert new
items (recent documents, etc.)

(Which does bring up the need to insert non-verb items probably,
though I can actually see Recent1 Recent2 verbs as a pretty clean
solution for recent documents.)
 
Random thought: what happens if the user goes mad rearranging all
their XML files and messes up your paths? Could we maybe do this:

 <menu>
  <menuitem/>
  <menuitem/>
  <insertion_point name="RecentDocsPoint"/>
 </menu>

So the user can move the insertion point around, and rather than using
a path you specify that insertion point?

> 	Perhaps this is the cmd / widget separation that Jody
> suggested to me and is implemented in the new UI handler. What this
> means is that a "verb" or "id" identifies eg. a toggle button and that
> the user can add as many eg. 'Bold' toolbar buttons and menu items as
> they like to the UI. The UI handler also synchronises state between
> them [the code for this would _really_ have benefited from Tim's
> GObject stuff, trying to add interfaces by bogus containment is a pain]
>

You should be able to firewall the user from the implementation in a
way that lets us move to interfaces later.
 
> 	Some people will hate the new UI handler, since it does force
> people to do it 'right' TM and have a CORBA object to handle local
> verbs [ cf. the huge mess of conditionals in the old code ]. This
> that your application is automaticaly scriptable in some sense which
> is good.
>

So I don't see the point of this; I suspect the conditionals were just
RTTI, and in many cases (including probably this one) the solution to
RTTI is a vtable.

Why not a GtkObject representing the CORBA UIHandler interface, then
implement it twice, once for local once for CORBA. Then people can
instantly switch to scriptable without changing any of their code, so
there shouldn't be any barrier to them doing it, but they can "opt
out" if they have a good reason. And I can think of reasons, including 
embedded devices.
 
Remember that all new non-GUI GtkObjects should likely become GObject
later, and to prepare for that do a ref/sink in the constructor for
the object so that it's never floating, and do everything in finalize
not destroy. GObject will have less overhead and generally be the
Right Thing for this in the future.
 
> 	Discuss; I would be most interested in design criticism of my
> work on gnome-components. There is a brief discussion of the new
> design in bonobo/doc/ui-handler.txt for those interested.
>

OK, see above. ;-)
 
> On Thu, 7 Sep 2000, Federico Mena Quintero wrote:
> > Applications should be converted to use Bonobo eventually and everyone
> > will be happy.
> 
> 	Hopefully.
> 

I do agree, but I think you're going to achieve this by doing things
Right, in part this means making Bonobo truly a basic technology
instead of super-high in the layer cake of libraries.

See my little ASCII art earlier in the thread.

> On 7 Sep 2000, Maciej Stachowiak wrote:
> > Ideally, we should have a solution which does not depend on Bonobo,
> > but that can be used with Bonobo. I love components as much as the
> > next guy (well, more), but the basic functionality of creating menus
> > and toolbars should not depend on the component model.
> 
> 	I disagree, we want uniformity across Gnome apps, and we want
> CORBA used everywhere, we want a high level of scriptability in every
> application [ which will have to extend to more than verbs =]. 

Your problem is the "we" here - we should be trying to expand the
number of developers that write apps on our platform, not just make
ourselves happy ;-)

Seriously; I do think you are doing this right, and it is going to be
a total waste of time to do it some similar but slightly not the same
other right way in GTK+ later. Let's not start the big theoretical
discussion again, but seriously it seems very practical to merge with
the GTK+ solution here, see below.

It's also true that for some applications being able to use this
without CORBA is a worthwhile thing, and I don't see how it's
especially hard to achieve.

> So I
> think that way lies madness. However, the core code XML model,
> overriding / reinstating code etc. is separated to an extent and I
> suppose could be split into gnome-libs at some stage.

Right. A simple object with vtable representing the CORBA interface
you are talking to makes the problem go away as far as I can think. 
I'll look at your implementation so far in a minute.

However again I think gnome-libs should depend on Bonobo controls in
GNOME 2.0, not the other way around, and I think the only gnome-libs
feature you're using here is stock pixmaps which are moved to GTK, so
this makes total sense. Also we need to use this stuff for MDI.
 
> 	Of course, and for the most part it does but currently
> gnome-libs is frozen and Bonobo is not so it makes sense to put it in
> Bonobo.
> 

Agreed for GNOME 1.4 but let's have a forward-thinking transition plan
for GTK+ 2.0 or 2.2.

My proposal would be to implement with GTK+ 2.0 in mind, using the
GMarkup parser and virtualizing the concept of the CORBA menu merge
interfaces. (Heck, this means we can also use UIHandler in MDI without
going via the CORBA stubs, a worthwhile efficiency hack.)

The disadvantages are: a) requires some more thought and care right
now b) not using full XML for the format.

I think b) is strongly mitigated because the GMarkup can be _read_ by
a standard XML parser, and because it will only be _written_ by hand
or using dedicated tools designed for exactly this application.  We
also have an upgrade path to full XML if we ever feel like it.

a) is mitigated because I am willing to help you if you will take the
help. I do not want to see a big mess in the menu/toolbar world; I
want to see ItemFactory and UIInfo deprecated, and I want to see us
unconditionally recommend this new API with no caveats. We have every
opportunity to do this at this point in time.

Havoc