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

List:       kde-look
Subject:    On menus generally
From:       "Friedrich W. H. Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2000-03-30 13:27:23
[Download RAW message or body]

Hello!

I'm rather a newbie to all referring UI design, KDE 2 and programming
(not to the english language also it appears to be this way ;-) but
nevertheless fascinated of these. So I would like to throw my 2 cents,
too.
I have listened to this list a while and developed some ideas which seem
to be new to KDE in my eyes. If not please don't be angry at me I only
wanted to help. My time gets short again so I can't check enough but
don't want my ideas to be blown in the wind...

My suggestion:
Join the left, right and else mouse button menus with the menu bar menu
and the tool bars and have them all being configureable!

WHAT DO I MEAN BY JOIN:
As I have read somewhere there will be / is a new class in QT 2.* and
KDE 2, named Q/Kaction. It is to collect all the possibilities for the
user to interact with the program. These are somehow sorted in the menu
bar menus and in the tool bar if I understood all right. And finally
their appearance in the toolbar can be edited. Great. But only the
beginning I think.

I know this touches a very basic problem, where the wise men are still
on, so I want to tell my opinion: With a program I handle data. I do
this by causing actions on it while being informed of the datas status
by status indicators (By status I mean the content and its properties
too). So in a GUI the user has commonly a window where there are
elements which allow him to start actions (often via dialogs) and
elements which show the status. Sometimes they are joined (examples:
text widgets, combo boxes, switches). Now in KDE we have as graphical
elements for action rising:
 * the menubar and its menus
 * the toolbar(s)
 * the mouse button menus
 * (forgotten anything?)

Some of them are static, some are generic/dynamic. But they are all
somehow equal: they are connected to some action. 

I only divide by menu and item. A menu has items, an item causes an
action or starts a new menu. So the toolbar and the other menus are the
same they only differ in the way they look like (the toolbar somehow
just acts like a graphic shortcut). 

Traditional the menubar has all available actions, the toolbar some of
them, same with the mousebutton menus but mostly depending on the
clicked context.

But all menus and menuitems are the same. Each menuitem is connected to
an action, has a name and/or a symbol and some helptext. Do you agree
with me?

(Uups I am writing a lot but don't know how to shorten sorry)


WHAT DO I MEAN BY CONFIGUREABLE:
There are many people argueing about what menus should be like: menubar
at top of window, at top of screen, by clicking a mousebutton...
I think: configureable. So everyone has the freedom to choice, at least
to try another style. Who wants to tell what is really the best
solution? 

The programmer tells KAction what actions there are, which name and/or
icon they have and how they are sorted in a standard menu and the
toolbar(s). Here is my first concrete suggestion: He does so with all
the mouse button menus, too.

My second concrete suggestion: In the menu configure dialog the user
should be able to change all menus. Changing means: He can resort items,
remove or insert some in a menu, perhaps change properties (text,
symbol), and what's more, create new menus. Each menu could be inserted
as an item into another menu. So the user has total control of his
access to the actions. Menus can be disabled (to store the configuration
of one which might be used only in some special cases) and connected to
the defined menucalls by the program.
Dynamic menus can be treated this way: the program tells the
menucontroller (kaction?) to create the according menu which will be
expanded with the dynamic items before shown.

My third concrete suggestion: Let's have tearoff menus!!!! I think they
do fit right in my solution. Aren't they simply dynamically created
toolbars which don't have vertical items with symbols but horizontal
items with texts?

So it would be possible to put the top menu on the middle mouse button
and the local menu on the left and another local menu on the right or to
replace the top menu at the top by a menu with only needed items or ...

I have no idea right now whether it is possible to have a global
configuration which tells when to show which type of menu but perhaps it
could be possible if we define such things like topmenu( has all items
in), local menu mouse button, top menu mouse button... Any experiences,
ideas, suggestions?

So, very long text, hope you think it was worth reading and this is a
nice idea. At least I would like to have it this way. Think of
fullfeatured programs like kword...

Please comment...

Friedrich

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