>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Well, Jean-Marc goaded me into combining the Menubar and
Angus> Toolbar. Now default.ui can contain (this is just an example!)
Angus> Menubar "toolbar"
Do you really plan to have Menubar and toolbar described as
equivalent? How does the frontend differentiate between them? I would
have kept the Toolbar keyword.
Angus> Menu "Layouts|L" "layouts_list_menu"
So you would have real menus in toolbars. Why not.
Angus> Combox "layouts_list_combox"
The original idea (was it from Baruch?) was to use the Menu keyword
and structure for comboxes (actually, the frontend would be free to
present the list as a menu or combox or...).
Angus> Icon "file-open"
Or
Item "interesting bubble help" "file-open"
So it seems we have two differents POVs: I had the idea to use the
same backend to describe two different objects, and you plan to merge
these two different objects into an hybrid one. Is that right? I do
not say you got it wrong, I am just thinking about the possibilities.
Angus> If I can open Menu "layouts_list_menu" by name, then it's only
Angus> reasonable to be able to open the Combox "layouts_list_combox"
Angus> by name also.
Sure.
Angus> Menubar "name" Position SomePosition ShowOn ShowEvent Menu ...
Angus> Icon ... etc End
Angus> where SomePosition = (Top, NewLine, Append) and ShowEvent is
Angus> currently (Buffer, NoBuffer), but could concievably be extended
Angus> to InsetXXX as well.
Yes, this is more sensible than what we have currently (hardcoded names).
Angus> This way, all Menubar behaviour can be controlled by the user.
Yes.
Angus> Moreover, I can treat the Menubars as just another Dialog and
Angus> move them behind the Dialogs.h "firewall". Communication by the
Angus> LyX kernel will be (is!) by signals only.
That would be the major cleanup in this area, I think.
JMarc
