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

List:       kde-usability
Subject:    Re: Kicker find as you type
From:       Fred Schaettgen <kde.sch () ttgen ! net>
Date:       2005-05-06 10:48:48
Message-ID: 200505061248.48926.kde.sch () ttgen ! net
[Download RAW message or body]

On Friday, 6. May 2005 00:35, Thomas Zander wrote:
> On Thursday 05 May 2005 23:32, Aaron J. Seigo wrote:
> > On Thursday 05 May 2005 02:55, Thomas Zander wrote:
> > > As another poster said; you are mixing concepts which will give
> > > inconsistencies however hard you try.
> >
> > yes, and i'm asking what those inconsistencies are.
>
> Clicking outside the kmenu will totally remove all your text and
> selections. For one thing. But I already mentioned that in my previous post

And I think that's perfectly fine. If you click somewhere else, then you'll do 
that usually because you're done with the k-menu. It would only be an issue 
if you want want to append text via cut'n'paste to some text you typed 
already.

> :) If I press 'ALT' the normal behavior is _very_ different from the kmenu
> one (the kmenu disappears totally)

Inconsistent, maybe. But this has nothing to do with the search line.

> The KMenu does not visually take focus away from other applications (they
> still have the 'active' kwin decoration) but you still have focus in the
> kmenu.  -> confusing.
> Thats 3, Need I go on?

Again nothing to do with the search line. Ok, maybe you are just answering a 
question. But I guess it should "What inconsistencies does the search line 
introduce".

> You can say that those are not important, and I think you will :)  But then
> what is the usage of all these gui-concepts we have been sweating over to
> get consistent???
...
> Well; in all my years doing usability in KDE and in companies and all that
> I learned that consistency rules;  stepping out of the box is great, just
> keep yourself in check please :)

The K-Menu is a pretty unique piece of the KDE desktop. If you want it to be 
consistent, then I have to ask: consistent with what?
It happens to be based on a QPopupMenu, but that doesn't mean is has to appear 
like one. If it had been something else, like some sort of treeview, then no 
one would think of popup menus in first place.
It has different requirements than a regular menu, so it's fine if it looks 
and behaves differently. Consistency doesn't just mean that similar things 
look similar, but also different things look different. 

If it looked perfectly like a regular drop down menu, then nobody would have 
the idea to drag an item somewhere else - this didn't work a hundred times 
before in other menus, so why should it work now?
But if the K-Menu doesn't look like a regular popup menu, then no one can or 
will expect it to behave to same.

> In short; I don't want to address the kmenu scalability inside the kmenu. I
> feel it has to be done outside it.  Not because I really really want to;
> but because I have not found a good way of doing it. (please don't hesitate
> to surprise me!)

You can't find a good way of doing it if you demand that the KMenu must behave 
like all other menus, sure.

Fred
-- 
Fred Schaettgen
kde.sch@ttgen.net
_______________________________________________
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]