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

List:       kde-usability
Subject:    Re: [PATCH] Kicker applet context menu simplification
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-04-19 11:57:19
Message-ID: BAY7-F347uPa9AhuM7O0005a824 () hotmail ! com
[Download RAW message or body]

>From: Maurizio Colucci <seguso.forever@tin.it>
>Date: Sun, 18 Apr 2004 21:25:07 +0200
>
>On Sunday 18 April 2004 19:45, Jamethiel Knorth wrote:
>
>No, the purpose is to solve two logical inconsistencies: 1) The container 
>is
>semantically different from the contained items. So when you right click a
>contained item, the popup menu should not relate to the container. 2) for
>ordinary windows, there is the distinction control area / content area. For
>the panel, there is not. The two concepts could be unified, resulting in a
>cleaner paradigm.
>
>I believe you either don't understand or you don't care about these
>inconsistencies. If you don't care, keep in mind that it is for
>inconsistencies like this that KDE is generally considered "messy".

Sometime inconsistencies are inexcusable, sometimes there are very good 
reasons for them. The control area on the window exists because it is of 
regular importance. The display of the title is of particular use, there are 
many reasons to have an area to grab for window motion, and there need to be 
clear ways to close/minimize/maximize/restore windows. These actions are 
regular activities, so this must be in plain view.

The panel is not like a window. The panel is always there but little 
changes. The panel is rarely resized or moved or rearranged. Thus, the 
controls which allow such activities need not be in plain view. Adding a 
control button removes a great deal of flexibility from the panel. In normal 
operation as the situation is currently, the panel can be customized in any 
way whatsoever and still be fully useable. You are proposing to remove that 
functionality for the sake of cleaning up those context menus. The value of 
flexibility and a better look trumps the value of consistency in this case.

I say that with the utmost care, as I value consistency very highly. The 
inconsistency between the menu items is bad. However, having 'consistency' 
between windows and the panel is bad as well. they are not the same and 
should not be treated the same. The panel is in no manner a window. The 
rules do not apply the same. The panel is used and treated differently and 
should be used and treated differently. If there was a desire to treat the 
panel like a window, the functionality could quickly be put into a floating 
window somewhere, but this is not done.

The only consistency you propose to add is to better define the meaning of 
the context menus for applets.



Also, possibly you could supply a mockup of what this control area would 
look like. Mayhaps you have an idea of how to actually integrate this to 
make it acceptable. I have doubts, although it would be nice.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/

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