Subject: Re: commit: Re: commit: Menu Strings stored in .strings
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Oct 31 2001 - 16:37:14 CST
On Wed, 31 Oct 2001, Tomas Frydrych wrote:
> > Dynamic menu Labels used to work by creating an entire copy of the menu's
> > stored in memory. We needed to do this because the old menu's were deleted
> > upon closing a frame. I think this is still the way to go because
> > otherwise menus and lables in widgets may get out of synch with the XP
> > menus and labels stored at the XAP_App level.
> >
> > Given this we need to modify you label code to return a copy of the stored
> > label set with the GenerateLabelSet method.
> >
> Martin,
>
> I do not follow this. What the createLabelSet method now does is
> that it creates two copies of the label set at the same time. I really
> do not understand why we possibly might need this, and it seems
> to me as a fairly substantial waste of system resources. Also, is
> this this is not to virtually guarantee precisely what it is meant to
> prevent, i.e., labels getting out of sync, for if either of these copies
> is modified the other one is useless. I really cannot get my head
> around this; either we need a copy in EV_Menu class, or we need
> a copy in XAP_Menu_Factory, but why should be need both
> escapes me. Can you please shed more light on this for me?
>
Hi Tomas,
I'm ccing the list because I think others would be interested in
this.
Your approach could be made to work. It requires a more radical change to
how abiword works and maybe requires some platform changes as well.
OK. Right now the EV_Menu_Layout and EV_Menu_Labelset classes are
destroyed upon exiting a frame. AbiWord was crashing when one frame was
closed with another already running. The solution I came up with was to
duplicate these classes from a copy stored in memory.
The other solution would be to NOT destroy these classes upon closing a
frame. However abiword has not been doing this until now so this would be
a more radical change. This would mean a pointer in the XAP_Frame is
permanently set to these classes and accessed from XAP_Frame. In fact the
menu_layout's are owned by the menu's themselves which makes sense form
the point of view of context menus.
In this approach the Frame does not own it's menus and menu's cannot be
created on the fly. This is how context menus work. These are generated on
the fly and destroyed after use. They use the same code as Main menu's. So
going with the "don't copy the Meny_layout class" model would require
rewriting this code too.
My approach took less than one line of code to fix a bad bug and keeps the
dynamic menu's framework we currently have in tact.
Now suppose you has a new menu item you want insert into a Menu label set.
You have to delete the menu widgets and recreate them anyway. This is what
must be done anyway and is relatively easy to implement.
It works now and is easy to a plugin to implement. Look at the aiksaraus
plugin to see the little amount of code required to implement a new menu.
Cheers
Martin
This archive was generated by hypermail 2b25 : Wed Oct 31 2001 - 16:37:35 CST