[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Build Configurable Context Menus into Kdelibs
From:       Sébastien_Laoût "\[temporar\]" <les83plus () free ! fr>
Date:       2004-07-23 17:34:15
Message-ID: 1090604055.7988.3.camel () localhost ! localdomain
[Download RAW message or body]

Erf, I haven't sent it to KDE Usability:

Le ven 23/07/2004 à 04:13, Henrique Pinto a écrit :
> Em Qui 22 Jul 2004 15:42, Sébastien Laoût [temporar] escreveu:
> > And because it's KXMLGUI, I think it should be trivial to put the SAME
> > code as the dialog to edit toolbars.
> 
> It is not that trivial. Context menus are not standarized. You can't take a 
> part of a XMLGUI file and tell "Hey, this is a context menu!".

What do you mean by "are not standardized" ?

What I think:
A KXMLGUI file contain <Menu /> items.
Each <Menu /> that is OUTSIDE <MenuBar /> IS *theorically* a popup menu.
Am I wrong and are those <Menu /> usefull other that popup menus ?

> (Actually, 
> most times you can, because developers give them sensible names, but, anyway, 
> the names are not standarized, and some menus aren't generated by XMLGUI.)

> But, if you think it is trivial, please implement it.

I haven't took a look at the KEditToolbar dialog but if we look at the
XML file, toolbars and menus are constructed the same : they contain
<Action name="" />, ect...
The KEditToolbar receive the actionCollection() when called, and since
popupmenus show actions that in the main menu, the actions are contained
in the actionCollection().

I see two problems:

1 As you said, popupmenus are not always constructed from KXMLGUI.
  We should then ask "Why ?"
  Before KXMLGUI menus and toolbars was not using it (of course).
  They are now forced: we can act the same for popup menus.
  I see some reasons: KXMLGUI is somewhat limited for "dynamic things"
  or "complicated things".
  I will write a paper soon on each problems I've seen in KXMLGUI
  in hope they will be solved in KDE 4.0 (by coding myself, if
  necessary).

2 The user could put for instance "tabs related actions" in a
  "selected file related popup menu" (because it could add all
  actions that are in actionCollection() to the popup menu even
  if the action is not related to the popup menu).
  Is it a problem?
  For consistency yes, I think. And I'm not sure even "power-users"
  could benefit to add this uglyness...
  Technically, it *shouldn't* be a problem, if the app is well formed.
  First solution: add XML tag to list all actions that are embeddable
  in a defined popup menu.
  e.g. :
  <!-- This is the list that will be show on left pane of the
       "popup menu editor" for the popup named "item_popup" -->
  <PopupMenuElementsOf name="item_popup">
    <Action name="cut">
    <Action name="copy">
    <Action name="paste">
    <Action name="open">
  </PopupMenuElementsOf>
  <!-- This is the popup menu the user has configured :
       He can add "open" action if he want, but not other
       such as "file_quit" because this action isn't listed
       above and isn't related to an item -->
  <Menu name="item_popup">
    <Action name="cut">
    <Action name="copy">
    <Action name="paste">
  </PopupMenuElements>

If you see what I want to say...

Hooooooo...

I've just thinked to an important think: a 3° (bigger) problem.

Menus contains sub-menu, whereas toolbars not...
:-)
Hey hey!
I was wrong/naive.
So I correct me: "it would need small code addition, and certainly some
usability reworking".

What I was saying is that for simple non-hierarchic menus it's possible.

Then, I've implemented it.

Basically, I've took kedittoolbar.h and kedittoolbar.cpp from KDElibs 
and i've copied them to my project (in KDevelop, to do very simple).
I then modified line 155 from:

  ToolbarList findToolbars(QDomElement elem)
  {
    static const QString &tagToolbar = KGlobal::staticQString( "ToolBar" );
    static const QString &attrNoEdit = KGlobal::staticQString( "noEdit" );
    ToolbarList list;

to:

  ToolbarList findToolbars(QDomElement elem)
  {
    static const QString &tagToolbar = KGlobal::staticQString( "Menu" );
    static const QString &attrNoEdit = KGlobal::staticQString( "noEdit" );
    ToolbarList list;

(replaced "ToolBar" by "Menu").
Then, in my mainwindow class file, I've replaced:

#include <kedittoolbar.h>

by:

#include "kedittoolbar.h"

Very simple: compiled and then now "Edit toolbars" menu entry show me
all the menus (not userfriendly but very good for a "proof of concept").

The first thing I see is that every menus, even in the menubar are show:
&File
&Edit
&Go
...
&Settings
basket_popup
tab_bar_popup
&Settings

1/ A simple addition to the code could eliminate every <Menu> items
   that have a <MenuBar> as a parent (direct or not).
   Not a programming chalenge :-)
2/ This structure allow to edit submenus.
   Cool! But not user-friendly tough.
3/ I've tried to modify a popup menu and then it works (I use KXMLGUI
   for all my popup menus, even if it conduce to redondancyes).
   Even by restarting the application it works, of course.

That's all.


_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]