Kickoff patch review

[Aaron J. Seigo]

On Monday 31 March 2008, Rafael Fernández López wrote:
> something like http://media.ereslibre.es/2008/03/kickoff/kickoff3.png), less 
> aggresive.

honestly, this looks even worse.

> - When searching, the bottom tabs are plain nosense, giving the idea that
> we could search in "last used items" or on "logout". So, 2 main changes
> when searching on this patch:
>
> 	- Select the 1st match if any. When we search the first match is selected
> for just pressing enter.
> 	- Hide the bottom tabbar.

i like this ...

> From the previous discussions, we could say that the cluttering of the user
> eye is for me, not the best argument. Why ?, well it will depend of kickoff
> size, obsiously, in first case. And, we could say then that
> http://media.ereslibre.es/2008/03/kickoff/detailedview.png this clutters
> user eye, when nobody has filled a bug against detailed views yet because
> of this reason on the KDE history (afaik).

ignoring the fact that these are completely different use cases (selection 
versus hover, choice listing versus file view), i don't think that the "no 
bugs filed" principle holds water here. this is one of those things that i 
don't think people would file bug reports against because they won't identify 
it as a problem even if it is. 

consider: how many bug reports did we get about excessive use of frames, e.g. 
konqi? none that i know of until i started fixing them and blogging about it 
(thereby making people conscious of it).

compare where your eye is naturally brought to rest with the current kickoff 
selector and where your eye is brought to rest with the qstyle delegate 
painter.

anyways, like i said, i'm tired of arguing this point. so whatever. it just 
continues to boggle me that even our artists don't quite seem to notice the 
horrific aesthetics of this; i've brought this up with friends from the 
graphics world and they seem to "get it" so i don't know what's up with that. 
*shrug*

> I just think that LTR users will 
> expect the contents to be at the left, exactly as they were before being
> hovered.

this ignores the psycho-biology of human sight. but whatever.

> The strongest reason apart from that that I have for this thing getting in
> is consistency. I always bet for consistency, and giving our desktop a
> consistent look is a need I think.

yes, i get this. i just wish it didn't make all our listviews with icons and 
what not look like crap.

> - New background look.

-1 from me, but you already knew that. if anything, please don't use the 
selection style but the hover style. this is about *hover* not *selection*.

> - Search hides tabbars (please note that instead of hiding, we could add
> another tabbar with only one tab "Search Results" so this would be more
> intuitive, despite that we would have less room for the results
> themselves). - Search highlights the first match so users only need to
> click enter. - Mouse tracking is strict. No item is hovered if the mouse is
> not over an item (except on the search, of course, if point 3 is accepted).

+1

> - Pressing Up/Down on keyboard when no selection is made selects the last
> and first items respectively.

+1

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080331/5c7510a8/attachment-0001.pgp