On 6 Feb 2001, Jean-Marc Lasgouttes wrote:
> >>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
>
> John> I've spent some time thinking about the menu stuff a couple of
> John> months ago. It is an icky problem really; I'm definitely leaning
> John> towards having all item-creation / default.ui parsing in each
> John> frontend, and only having meaningful signals like :
>
> John> Signal1<void, const string> fileOpened;
>
> John> or similar.
>
> What will you be able to do in KDE that you cannot do right now?
Not generate a dynamic menu every time it's called (theoretically, the
hookes needed in kernel are simple in some cases, more complicated in
others)
Not have to mess around with the two menubar thing which is awkward to
interpret
Have specific toolbars that change depending on the mutating document and
transient properties (e.g. position). It shouldn't be the kernel's
responsibility to manage these sets, simply because they can differ
between frontends. IMHO these changes should be told to the frontends, and
then it is their responsibility to act
Organisation of menus according to relevant standards (possibly)
Simpler code
As simple as possible handling of the special cases :
| Dynamic | Static
---------------------------------------------------
BufferDependent | References, TOC | N/A
---------------------------------------------------
BufferIndependent | Lastfiles, Documents| *Formats
But Kalle is the one to ask really, he's the GUI whizz and he had a go at
the Qt2 menubar before
thanks
john
--
"Do you mean to tell me that "The Prince" is not the set textbook for
CS1072 Professional Issues ? What on earth do you learn in that course ?"
- David Lester
