Andre Poenitz a écrit :
On Wed, Jan 18, 2006 at 03:43:58PM +0100, Abdelrazak Younes wrote:
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:
[...]
Ok up to:
Good enough!
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>
I would not add the <rules> part. Enabling/disablig should be done in
the core, otherwieyou'd end up coding C++ in XML.
And what's wrong with that? I mean, if it doesn't eat up CPU cycles, the
less hard-coded code the better. Think about the possibilities for an
experimented (and imaginative) user who will be enabled to invent new
ways of writing structured document with strict rules. Plus the fact
that it's easier to debug text than compiled code. I am maybe dreaming
loudly :-)
I agree with the rest.
Thanks for commenting,
Abdel.
Andre'