[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-24 13:16:08
Message-ID: 1090674781.6384.4.camel () localhost ! localdomain
[Download RAW message or body]

Erf.
Please forget (delete) my previous mail.
THIS is the REAL mail that wasn't sent to KDE Usability:
(please accept my applogies)


Le ven 23/07/2004 à 20:57, Henrique Pinto a écrit :
> Not all context menus are done through XMLGUI.

They should ;o)

> > Each <Menu /> that is OUTSIDE <MenuBar /> IS *theorically* a popup menu.
> > Am I wrong and are those <Menu /> usefull other that popup menus ?
> 
> Nothing stops you from plugging them into a menubar.

It is possible ?
I'm interested, because I duplicate a menu in two or three places in the
KXMLGUI file.
I've searched in the KXMLGUI DTD but I see no tag to indicate "add the
sub-menu named 'name' here".
If it is possible, I would have one thing less to ask for KDE 4.

Yes, it is possible programmatically, but what is the interest of
KXMLGUI if code must be added?

> Now you face your biggest problem. The code in question might have been simple 
> to write, but the interface is surely not. The "Edit toolbars" dialog is not 
> suited for editing menus. And I can't think of any way of doing that in an 
> user-friendly way.

Hum... but it's not impossible.
Toolbars have a "editable" parameter.
Why not menus too?

As you said, it also need standardization.
Menus should too have a <text> tag, so the user have a nice indication
of what the menu does.
Eventually be named like "*_popup", but the "editable" parameter would
do the same.

Still a problem: in my app I have the "&Settings" menu in the toolbar,
but also in the tabs popupmenu (in case the user has disabled the
menubar he has a nice way to re-enable it).
So, this menu would be editable as a popup, and not editable as a
menubar menu.
But it's a very special case, isn't it?
That does nothing if the "&Settings" popupmenu is not editable.

OK, Toolbar editor is not well suited for popup editing, but the basis
are there.
The right listBox can be replaced by a tree, so we can edit hierarchical
menus (eventually, we can include <Menu> items and clicking them switch
the editor to this submenu to edit it).
The left list should also list submenus to add or remove them from/to
menus...

> > 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 :-)
> 
> Nonsense. Popup menus aren't different from "normal" menus, it makes sense to 
> edit both.

I'm not sure:
IMHO, menus in the menubar are immuable and show EVERY feature the app
has (cf. KDE guidestyle: "each feature in the toolbar must be in the
menubar"...).
If a user delete an item he could be lost if a feature has "disappeared"
and editing menubar is not so critical that popupmenus.
But I can be wrong, and there is the problem if a menu is in the menubar
and in a popupmenu.

But this discution is now out of scope of KDE Usability :-)

_______________________________________________
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]