Re: Broken i18n and the new UI handler.

[Havoc Pennington <hp redhat com>]

Michael Meeks <michael helixcode com> writes: 
>         Ah indeed, but I have a quandry; I like to produce code and then
> say lets do something with it as opposed to talking fire and achieving
> nothing.
>

As do I, don't imply otherwise. HOWEVER, there is a place for just
getting something done with the fastest hack, and there is a place for
fixing things properly.

The very most basic GUI APIs that people will be using on all UNIX for
years to come are a place where we can take a little extra time to get
it right. Part of getting things right is peer review and considering
_all_ the issues, not just our immediate needs. Thus this thread. ;-)

If you want to say "OK, this is just my lame hack for 1.4, we won't
support it long-term" then I'll be right off your case. If you are
saying "in the past two weeks and in the next two weeks I am writing
the definitive menu API we all get to use forever" (which you said ;-)
then we need to have this thread and you need to be open to everyone's
input.

We do, after all, have three or four current menu APIs, plus we've
researched what Qt and Swing and Gtk-- have, and you've researched
what COM/ActiveX/whatever have I assume, and Evolution/Nautilus have
been using the old UIHandler, so we have quite a lot of collective
wisdom on this matter.

So, don't throw the "no talk I am coding" bone over here, I'm happy to
code and code plenty, but talk has its place.

Anyway, enough on this, let's just look at the technical issues.

> > Which is, note, valid for the GMarkup parser I proposed for GLib.
> 
>         Currently I am using libxml; I havn't looked at GMarkup, however
> one think I need is the ability to associate extra model information to
> each xml node; is this easy / feasible with GMarkup ?
>    

It doesn't do that right now, you could add it, or if nothing else you
can use datasets or a hash.

(Though, exporting xmlNode and using it as your main data structure is
not a good idea IMO, it is very, very error-prone - I did this for the
GConf XML backend and had to rewrite it 3 times before it had the
smallest chance of being unbuggy. xmlNode is big and complicated, if
nothing else it's using massive RAM.)
 
> > Why not specify the GtkAction/QAction part separate from the menu     
> > item? i.e.
> 
>         This is done with the verb / id. but this acts as a state sync
> label. So it is quite possible to have three items with different labels
> that do the same thing; a marginaly useful feature.
>

I was wondering whether to add an additional level of indirection, so 
you have:
 
 verb -> actions invoking the verb -> menu/toolbar items derived from
  the action
 
However that seems like messy overcomplexity to me this morning.

Another option is to have default
labels/pixmaps/accels/etc. optionally associated with a verb, and then
if a menu/toolbar item doesn't specify these things, you use the
defaults for that verb. This is maybe the cleanest solution.

(You probably want the defaults on the verb anyway to present to the
user in a menu editor; if I choose the FileOpen verb I should
automatically get a default menuitem for it, without having to pick an
icon and label manually.)
 
>         You can set sensitivity on a per verb basis; see bonobo/app.c and
> that affects all items that connect to that verb.
>

Nice.
 
>         Radio groups have a 'radiogroup' string that is an unstructured
> identifier that ties radio items together. This means that radio items no
> longer have to be adjacent [ though that is a rather peripheral feature ]
>

Nice.

(BTW, is there some sort of namespacing of verbs/names/radiogroup
names/etc.? What happens if I have a container such as Nautilus that
has lots of its own menu items, and a third-party control that gets 
embedded, and they randomly picked the same name for totally unrelated 
things?)
 
>         Yes of course, I want to add a lot to the UI handler, but getting
> the API right is the most important thing.
>

(Of course that's why I'm suggesting you go ahead and look at GTK+ and
GNOME 2.0 plans, because you can't get the API right otherwise
IMNSHO.)

> > >     /menu/submenu/#File/menuitem/#New
> > >
> > >     or somesuch.
> > >
> >
> > What does the # mean?
> 
>         # denotes a name node. The reason for this then is that the path
> can be used to create a path correctly before it is there, and so that  
> subsequent merges work well. This is part of the strategy for supporting
> crazy ordering on merging / overriding.
>

I failed to parse this. ;-) Example? (Maybe this is obvious to current
users of Bonobo.)
 
> > 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).
> 
>         A hash would be nice; I think I just do umpteen string compares
> for now. The Verb space is structured per ui-component registering
> callbacks. However, if you examine the Microsoft Office menu editor, you
> will find that it seems to use a similar concept of verbs, however it
> names them in a structured way eg. 'FileOpen'.   
>

By "amorphous hash" I didn't mean it had to be implemented as a hash,
just keeping the verbs in a separate data structure from any menu
trees that might happen to use the verbs.
 
> > (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.)
> 
>         This is what bonobo controls are for.
>

What I meant was, if you want to say take the widget tree generated
from the XML string, and insert additional menu items in it that are
not generated from an XML string or at least don't have associated
verbs (such as recent documents), you should be able to do that.

So the only way to do that at this point is to provide a bonobo
control to be added as the child of a menu item? (I wonder if
plug/socket will survive that treatment ;-)
 
> > So the user can move the insertion point around, and rather than using 
> > a path you specify that insertion point?
> 
>         Um; this would be possible to implement with the current API, you
> just grab the whole tree, parse it, find the node, generate the path and
> then set the stuff [ not efficient :-]. My problem is that I want to stop
> the CORBA API getting bloated at any cost, but perhaps this should go in 
> anyway.
> 

Worth considering, it seems cleaner than paths to me. (At the moment
to insert recent documents I essentially have to say "put the recent
documents after the /File/Open item", right? So if the user edited
whatever item it is around, recent docs would follow it. Or do you
have a better plan in mind already?)

>         I am _Not_ interested in discussing Gnome 2.0 at this stage, not
> Not nOt noT nOT NOt. The pain in my life at the moment is getting bonobo
> ready for Gnome 1.4 and making sure that apps use it correctly and
> efficiently. I _cannot_ afford the time to start even thinking about
> splitting it into 15 pieces, adding conditional builds, screwing with   
> automake etc. It is a waste of time.
>

If you can't discuss GNOME 2.0 there's no way you can get this API
right in the available time; you should just focus on getting Nautilus
and Evolution to work, whatever that involves in the opinion of those
involved, and then mark this API "do not use, experimental." That's
just the situation. I see no way around it.
 
>         I need a solution for Gnome 1.4 and cannot get sidetracked into
> merging with Gtk any time in the next weeks. Perhaps for Gnome 2.0 yes,
> whatever, I just hope that the Gtk 2.0 freeze is not going to obviate
> doing the right thing WRT deciding what code belongs where in the Gnome /
> Gtk / Bonobo mix <hint>.
>

I also hope so. Another option we have, if we freeze GTK 2.0, is to
release a binary/source compatible GTK 2.2 that only adds features
and doesn't break anything. I don't know if that will happen, but it's
an option that's been discussed. The GTK 2.2 could even be released by
GNOME 2.0, and we could look at GTK 2.0 itself as mostly a way to let
GTK-only apps upgrade and test things out, i.e. an intermediate
stabilization step.

My worry is that by releasing the Bonobo API we get locked into having
to do things a certain way. If you release the Bonobo API in such a
way that that doesn't happen, i.e. you remain fully willing to break
the hell out of it, then we're in good shape.
         
> > Agreed for GNOME 1.4 but let's have a forward-thinking transition plan
> > for GTK+ 2.0 or 2.2.
> 
>         In due course.
>

Again, if the 1.4 release locks us in, this is not an acceptable
answer. If the 1.4 release is just a short-term hack we can break
later and we won't tell people to use, then cool.
 
I don't actually think we can solve this well in the 1.4 timeframe,
so IMO it should be a deprecated hack from the very beginnning.

>         I would perhaps be happy with b) but I need to discuss with Daniel
> my XML Guru, and evaluate GMarkup. Tell me, does GMarkup store the decoded
> node / property content internaly or does it store the external
> representation. IE. do I get &lt;Control&gt;t or <Control>t most
> efficiently ?
>

At the moment there is no way to get &lt;Control&gt; - GMarkup
escapes/unescapes things internally and just gives you the final
literal string in UTF8 encoding.
 
> > 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   
> 
>         I would very much appreciate your help; please send me private 
> mail CC'd to Miguel, patches, great wads of hardware etc. :-)
> 

OK what I want to do is talk about (and implement) GTK+-level
interfaces, etc.  so that should likely go via gtk-devel-list, also it
means you need to be ready to talk about GTK+/GNOME 2.0, so we should
maybe postpone. Though if you do postpone that means being prepared to
break the hell out of the Bonobo interfaces going out with 1.4, or at
least to deprecate them.

What I think would be super cool is to be able to simply write a
widget with attached menus, and if you insert it in MDI, as a panel
applet, as a Bonobo control, whatever, things Just Work. You don't
have to learn a new API to use Bonobo, you just call
bonobo_control_from_widget() on your widget and the existing menus on
that widget get exported. 

The buzzword-enabled description of this feature is that GTK+ has
"native support for embedded controls" and we can say that a
full-blown Bonobo control with menus genuinely requires no extra
coding over a standard GTK+ widget, because all widgets can add menus.

Sketching how this would work:

 /* For creator of the content area */
 GtkMenuBlob *blob = gtk_menu_blob_new (xml_string);
 gtk_widget_set_menu_blob (my_content_area, blob); 


 /* For embedder of the content area: MDI, Bonobo container, GnomeApp, 
    whatever */
 GtkMenuBlob *blob = gtk_widget_get_menu_blob (content_area);
 if (blob)
   /* merge blob in */;

Bonobo just proxies the blob across the wire, so Bonobo controls work
just like any other widget.

This gives us a really sweet abstraction layer and makes Bonobization
or componentization of a properly-written GTK+ app a two-line patch.

Since GTK+ needs a new menu API whatever you do in Bonobo, I will
probably end up having to implement this anyway, it would just be far
cooler for GNOME and less tiresome all around to integrate with
Bonobo.

Havoc