OK, I think I have some arguments now ;-)
So, if I was to rewrite this all (which I am not going to do, at least
not now), I would base this on four configuartion files:
1) "Action Config file": I'd describe there all lyx actions together
with default label, icon, shortcut(s), tooltip _AND_ rules that enable
or disable each action.
2) "Menu Config file": provides a default menubar description where menu
items are just using Lyx Actions defined above. Maybe optionally, allow
the overwriting of default labels (not sure this is useful). This config
file would describe only static menubar items and associated menu items
(menu items are allowed to be disabled/enabled i.e. grayed out via the
Lyx Action).
3) "Toolbar Config file": same as the menu config file. Items would just
use Lyx Actions.
4) "Context Menu Config File": There, we could describe every context
menu together with the rule(s) that makes this context menu being
created. This context menu would be available to the user via three
ways. Let me take the table example:
a) The keyboard cursor enter a table:
A new top level item "Table" is created on-the-fly on the
menubar.
b) The user press the "windows context menu key" (right to the
Alt-gr button) whenever the keyboard cursor is within a table:
The context menu appears at the right of the keyboard cursor.
c) The user right-click inside a table:
The context menu appears at the right of the mouse pointer.
This means that the Table settings dialog is not automatically
launched like it is now. The user would have to click
"Table settings" in the context menu.
The syntax of the first config file needs to be well thought out.
Personally, I would go for XML. In particular, the rule that permits the
enabling or the disabling of an action should be there instead of being
hard-coded. For example, the "increase-list-depth" action would be
enabled only if previous paragraph is of "list" type. Ex:
<action name=increase-list-depth>
<func name=""depth-increment" arg="">
<icon name="depth-increment.xpm"/>
<label name="&Increase depth"/>
<shortcut name="Alt+P Right"/>
<rules>
<buffer property="opened">
<previous>
<layout type="list">
<layout type="itemize">
<layout type="enumerate">
</previous>
<current>
</current>
<next>
</next>
</rule>
</action>
In this example, the <previous> tag represent the previous paragraph.
Same for <current> and <next>. We can add as many rule as we want. I am
not sure about the <buffer> tag. This would inform about current buffer
status, i.e. "Is there an opened document?".
I hope this is clear but feel free to ask for any additional
explanation. Maybe I should just switch to french and discuss that with
JMarc privately ;-).
In the context of the proposal above, I'll try to comment the
description below in line...
Jean-Marc Lasgouttes a écrit :
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I don't want to look presumptuous but, as far as I can
Abdelrazak> see, the only truly dynamic menu is the "Navigate" menu.
Abdelrazak> All the rest is static and it's easy to make an exception
Abdelrazak> for the "Open Recent" menu item. The "Navigate"
Abdelrazak> functionality can be put elsewhere (or made a special case
Abdelrazak> menu).
Removing functionality because it is a pain to implement is wrong. You
should argue from a UI point of view why you want to do this.
See above.
Abdelrazak> I have the feeling then that this would simplify the
Abdelrazak> MenuBackend class a lot because all the items could be set
Abdelrazak> at the beginning and no need to redo everything each time
Abdelrazak> you click the Menubar.
What is the exact simplification you get by setting things at the beginning?
If I am not mistaking some of the intelligence could be transfered to a
config file instead of the C++ code. The simplification would be to
reorganize the remaining intelligence between:
a) a Lyx Action backend that would construct LyxAction based on the
config file. These action would then be used by a QLAction which would
inherits QAction.
b) a simplified static menu backend.
c) a simplified toolbar backend
d) a context menu backend
Here are some of the features of Menubackend:
- read the structure from a file (we ship both the default structure,
and the 'classic' 1.3.x one, with some different labels for the same
functions).
This label overriding could be added to the static menu config file.
- create automatically the list of: recently opened files,
We can define a lyx action that would create this submenu on-the-fly:
i.e when you click on the "Open Recent" menu item and not when you click
on the "File" top level menu.
> open documents,
I would put that in a separate top level Item reserved to that:
"Windows". This would be shown only if there are more that one document
opened. Plus we can make use of QTabWidget in the future (a la firefox).
> table of contents,
Separate Top level menu item. I would even put this as a submenu of the
"standard context menu" (when you right-click)
view formats, export formats, import
formats, character styles,
Those are static menu items no?
float lists (list of figures...),
Submenu of Navigate.
floats,
>
selections that can be pasted (Edit>Paste recent).
Same as "Open Recent". Or maybe a new top level menu item: "Clipboard".
I would also put that as a submenu of the context menu.
- make some menu entries appear only when needed (Edit>Tabular
Settings...). Suppress some menus when they are empty.
This is not needed anymore with my proposal.
- disable a menu when all the entries inside it are disabled.
It is easy enough to delegate this to Qt. Or we could (as Qt does)
associates a lyx Action to every submenus. QtMenu keeps a list of
QAction childs.
- avoid consecutive separators, or separators at the beginning/end of
the menu (useful when some entries have been removed)
Not useful if Standard Menu become static Because there is no such entry
that can disappear. You have a full menu or you don't.
- add some support for Qt/Mac file moving (this is part of the
ugliness of the qt2 menu code, BTW)
I don't know about that.
- show an error on the console for wrong or duplicate shortcuts in
menus.
OK.
You could argue that some of the lists could only be updated when we
switch buffer, but it is not true for all (ToC, paste recent...).
Also, some entries appear or disappear depending on where the cursor
is.
This is what I don't like most about this. As I said I prefer whole
menus to appear or disappear. And IMHO context menus are much more
useful and powerful.
> And of course, some entries get enabled/disabled or checked on/off.
I think this should be delegated to the lyx action that would know what
rule makes it enabled or disabled as defined in the Action config file".
That's all for now. I realize that this proposal would mean a major
restructuring of the menu and toolbar backends and maybe this is not
worth it. I just wanted to put all this on paper in case somebody (maybe
you :-)) is interested to implement that. I managed to work on the Qt4
port alone but I don't know enough about lyx internals to implement it
myself. Plus, I won't have the time. In any case, I would be happy to
help of course.
Thanks,
Abdel.
Abdelrazak> IMHO, abstracting lyx action is enough.
We may discuss whether such or such feature is useful, but I am not
sure you can get rid of a proper model (in the MVC sense) of the menu
data. This is what menubackend does.
And I think that qt3 and qt4 will needs to be supported at the same
time for 1.5.
Abdelrazak> Agreed completely. And correct me if I'm wrong but it's OK
Abdelrazak> if one frontend doesn't use some GUII functionality, isn't
Abdelrazak> it? I think there are real benefits to this GUII stuff but
Abdelrazak> there is room for simplification.
I'd like to see the simplification first :) If you end up duplicating
lots of code for no reason, I do not see the point...
Abdelrazak> Please don't take this all personally, this is just an
Abdelrazak> opinion and I don't want to start a flame war. If you want
Abdelrazak> I'll just shut up now.
No problem, please don't shut up.
What we could try to do as a first step is see why your code crashes.
Rewriting a whole subsystem because of a crash is a bit extreme :)
JMarc
