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'



Reply via email to