Re: some thoughts on the menu framework

> Am Donnerstag, den 24.02.2005, 22:18 +1100 schrieb
> msevior@physics.unimelb.edu.au:
>> >
>> > Hi everyone!
>> >
>> > I am fairly certain that the founding fathers envisaged that the
>> > different ports of AW would use the same menu layout. It is clear now
>> > that this is not feasible -- it takes more than using native widgets
>> for
>> > the application to have a native feel. However, we are left with a
>> menu
>> > framework that was designed on that assumption, and requires
>> conditional
>> > compilation to behave as we need it to; I think there might be a case
>> > for redesigning the framework (after 2.4) to make it more flexible and
>> > portable.
>> >
>> > In particular, I wonder if it would not be good idea for the menu
>> layout
>> > to be stored in an xml file. I can see several advantages in that:
>> >
>> > a) Each platform would have a menu layout that could be tweaked
>> > independently of the others,
>> >
>> > b) It would make it easy to add/remove/change things without having to
>> > recompile,
>> >
>> > c) It would make it possible to tweak the menu layout at the user end.
>> > For example, it would make it possible for a user who uses AW on two
>> > different platforms to make AW use the same menu layout on both, or
>> for
>> > a sysadmin to remove certain menu items.
>> >
>> > The only real drawback I can see is if a particular distribution
>> decides
>> > to ship with its onw menu layout -- it would complicate bug reporting
>> > and user support.
>> >
>> > What do you think?
>> >
>>
>> Hi Tomas,
>> This makes excellent sense. Actually there is no need to wait
>> until after 2.4 either.
>>
>> If a developer has a passion for this, the menu's could be easily
>> defined
>> in an XML file and sythesized whenever we open a new frame. It's prolly
>> not more than 200 lines of code.
>>
>> We already store the entire menu layout in an in-memory array which is
>> first loaded from another array built during compilation.
>>
>> (This i how plugins add and subtract menu items.)
>>
>>
>> It would not be hard to have the in-mempry loaded from an a method in
>> XAP_App which in turn could be loaded from an XML file on-startup.
>>
>> I'm not interested in doing this myself but I'm happy to provide
>> pointers
>> to people who are.
>
> We briefly discussed this on irc, i'm posting some ideas.
>
> Gtk already has this [1], therefore it would not make much sense to
> reinvent the wheel. In fact gtk's format is pretty simple, it defines a
> name and an action per item.
> Gtk could use this natively for the most part, for the other platforms
> we'd have to write a parser and build up the menus natively.
> Maybe we'd like to map the action names to existing menu IDs for all
> platforms, so the code using the menus could stay pretty much the same.
>
> Then let's do it for toolbars too ;-)
> ... which would open the door to the ultimate 1337|\|355 [2] of editable
> toolbars. (not much use apart from that if the default layout is good
> though IMO :P
>
> [1] http://www.gtk.org/api/2.6/gtk/GtkUIManager.html
> [2] http://www.microsoft.com/athome/security/children/kidtalk.mspx
>

Ah GTK discovers AbiWord code :-)

It's already imeplemented for both menus and toolbars. We just need an XML
description. That's all.

If we do it using the cross platform architecture, then all platforms
benefit.

Look at

abi/src/wp/ap/xp/ap_Menu_Layouts.cpp

In particular see the method...

bool XAP_Menu_Factory::buildMenuLabelSet(const char * szLanguage_)

build menu's out of defined *.h files. It could almost as easily be built
out of an XML file at run time.

Cheers

Martin
> Best,
> - Rob
>
>
Received on Thu Feb 24 14:47:08 2005