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: > 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. I agree with the rest. Andre'
