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

List:       kde-usability
Subject:    Re: [PATCH] Kicker applet context menu simplification
From:       Maurizio Colucci <seguso.forever () tin ! it>
Date:       2004-04-19 15:46:14
Message-ID: 200404191746.15136.seguso.forever () tin ! it
[Download RAW message or body]

On Monday 19 April 2004 13:57, Jamethiel Knorth wrote:
> >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. 

Agreed.

> The control area on the window exists because it is of 
> regular importance.

IMO it does not exist because it is regularly used. It exists because it is a 
way to allow the user to refer to the "container", as opposite to the 
"contained". It is *big* because it is regularly used.

> 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.

Yes.

> The panel is not like a window. The panel is always there but little
> changes. The panel is rarely resized or moved or rearranged. 

Rarely, yes. But *sometimes* you need to add something to the panel or move 
the panel, etc. 

> Thus, the 
> controls which allow such activities need not be in plain view.

Agreed, not in plain view, but they must be accessible *somehow*. 
And this "somehow" should not be the right mouse button, due to the 
inconsistency.

> Adding a 
> control button removes a great deal of flexibility from the panel. 

I don't see why.

> 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.

 There must be a mistake. :-) I am not proposing to remove any functionality. 
I am proposing to add something.

> The value of flexibility and a better look

A control area would make the panel look worse?

> 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. 

Does not follow. IMO, two concepts should always be unified if there is no 
reason not to. (for obvious reasons of minimality) 

You still have not supplied a reason not to.

> 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.

I totally agree with you: I am *not* proposing to have the same behavior for 
panel and window. I am just proposing that they both have a control area. The 
actual options available from the control area should be completely 
different, and the control areas should have a completely different size.
What's wrong with that?

> 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.

No, you have ignored point (1).

>
> 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.

The panel control area could be something like the blue area in the picture.

cheers,

Maurizio

["controlArea.jpg" (image/jpeg)]

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