Re: Broken i18n and the new UI handler.

[Michael Meeks <michael helixcode com>]

Hi Havoc,

On 9 Sep 2000, Havoc Pennington wrote:
> 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 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.

> 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 ?
   
> Can you explain how "name" is different from "_label"? Is "name"
> guaranteed unique for the menu item?

        This is the solution to the translation problems that are
bedeviling the GnomeUI stuff. Essentialy the Name provided a
programaticaly constant path regardless of translation, the _label is a
translated string.

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

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

        You can set sensitivity on a per verb basis; see bonobo/app.c and
that affects all items that connect to that verb.

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

        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 ]

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

        Yes of course, I want to add a lot to the UI handler, but getting
the API right is the most important thing.

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

        And of course, it already supports that.

> > 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?

        # 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.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'.   

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

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

> You should be able to firewall the user from the implementation in a
> way that lets us move to interfaces later.

        Of course, we simply re-write bonobo-ui-item.[ch] to be more sane.

> 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.
   
        Of course; I am fully aware that GObject rocks.
   
> 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.

        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.

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

        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>.
        
> Agreed for GNOME 1.4 but let's have a forward-thinking transition plan
> for GTK+ 2.0 or 2.2.

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

        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 ?

> 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. :-)

        Regards,
        
                Michael.

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