making kickoff have full-width selection rects (on hover)

[Aaron J. Seigo]

On Wednesday 27 February 2008, Will Stephenson wrote:
> On Wednesday 27 February 2008 17:54:23 Aaron J. Seigo wrote:
> > On Wednesday 27 February 2008, Will Stephenson wrote:
> > > especially pulldown menus.
> >
> > and pulldown menus have headers, search edits, tabs and disk usage bars?
> > kickoff is as much a menu as krunner is.
>
> Apples and oranges, I'm comparing the menu component of kickoff to menus
> elsewhere.  And as above, consistency != identity.

that's what i'm getting at: kickoff is not a menu. it's a set of complex 
widgets that appear in a window that appears/disappears when an icon is 
clicked.

the reason people consider it a "menu" is because it has replaced a menu. but 
it's not a menu. it violates typical menu behaviour all over the place.

> > > * conversely, only highlighting the text could give the impression that
> > > the text is something separate to the icon.
> >
> > did you think that? have you found someone who has?
>
> Yeah, I thought that.  My list starts "I believe".

that wasn't my question. my question was if you or anyone you know actually 
did not get the connection between the icon and the text. e.g. do people 
actually, in real life while using kickoff say, "huh, i wonder what that icon 
belongs to?"

i haven't actually heard that yet. indeed, i'm skeptical that it actually 
happens. and if it's not a problem in the real world, then it's not a problem 
we need to care about.

> > > * other menus also display icons and other elements without colour
> > > clashing.
> >
> > again, you're using kmail. start a mail, open the edit menu, mouse over
> > Undo and, if you're using the default oxy colour scheme, tell me that
> > there isn't a wonderful clash of blue on blue.
>
> I believe that's an instance of "proof by example", but usefully
> illustrates that the oxy guys need to define a highlight colour and test
> icons on that as a background.

but that's the point: icons vary in colour, *especially* since:

a) we are showing application icons which are often logo-like in complexity 
and lack of consistency

b) we let people change the icon theme

point (b) is mitigated by the fact that we mostly have to care about defaults, 
though that doesn't help much with (a).

no matter what highlight colour is chosen, it's not going to work with the 
rather broad set of icons that appear. moreover, highlight is meant to work 
with text. using it with icons is actually a bit of a colour abuse. our 
limited palettes are just insane from an aesthetics perspective, though 
KColorScheme helps a bit there.

> > and that's not something that you are going to sit there and read through
> > and which isn't 32px+ in size.
> >
> > when the highlight was behind the icon, i often found it just fugly:
> > konqi's icon is esp bad there.
>
> Maybe draw the icon on a base() background and then draw the highlight.
> Didn't agateau try this?

perhaps; i don't remember seeing it. it is an option.

> > > Fuel gauges in items are a solvable problem
>
> Disk usage bars.

ah.. disk usage bars. yes, it is solvable by changing the colours used. then 
we're back to "which colours". maybe we can cherry pick something from 
KColorScheme.

> > so the current system is indeed effective in the real world, whic mean
> > this is basically a discussion about usability for something that that
> > works making it really a discussion mostly about aesthetics. =)
>
> Ah, now we are on the same page!  All my arguments except the
> not-selecting-the-selected-icon one are aesthetic ones.  I should have
> pointed that out at the beginning, but I'll do that now: "I believe full
> width selections are more aesthetically pleassing because..."

i'd like to see the more aesthetically pleasing full width implementation 
then. i've noted several issues that have not been successfully addressed. 
and yes, for the record, i find that the selections in openSUSE's kde3 
kickoff look pretty lame.

> > and if we really want to improve the look 'n feel, doing something about
> > the fugly frame would be a decent idea.
>
> You didn't HAVE to respond to this thread either, I'm just taking a break
> from the washing up here.

heh.. yeah, i'm never quite sure when not replying is going to result in:

a) people thinking "he's an asshole who doesn't care" (because i get that from 
time to time when i ignore things ;)

b) when my ignoring it gets taken as implicit agreement that encourage 
innapropriate code changes (that too has happened)

oh well =)

> > > * a full width highlight doesn't cramp the item it highlights, a bit of
> > > empty space between the borders of the highlight and its contents makes
> > > the whole thing easier on the eye
> >
> > strawman, as that was never an issue.
>
> It can't be a strawman, it's presented as my opinion, not yours.

given that nobody (that i know of?) is purporting that it cramps the item ...

> > > * a full width highlight doesn't create the impression of a jumble of
> > > differently sized rectangles whilst mousing over a list of items
> >
> > given that it maps directly to the size of the thing being highlighted
> > ...
>
> I meant the group of rectangles formed by highlighting a number of items. 
> If I mouse down a list, I get an impression of all the highlights.  Since
> they are differently sized, it's not harmonious.

yes, i understood what you meant.

> > and again, highlighting semantically useless space in a way that
> > emphasizes it seems rather fun.
>
> I beg to differ, IMO the highlighted negative space is actively
> semantically useful in drawing attention to the highlighted item and a
> minimal highlight actively distracts from it by creating discord.  (to
> restate a couple of earlier points)

so you don't know which item is highlighted? no, sure you do. that's not the 
issue ... again, let's leave the usability discussion aside because this part 
of the discussion isn't about usability. (though i still stand by my 
statement that using highlight() the way we do right now waaay over 
emphasizes the negative space)

aesthetically the small highlight box is something some people don't like, but 
i've yet to see a full width highlight for kickoff that looks nice. i've seen 
them for other interfaces, just not kickoff. having them for other interfaces 
does not make them magically appear for kickoff, and i'm not going to simply 
say, "yeah, i'm ok with these full width patches even though they look 
horrible on the basis that it's *possible* to do a full width select that 
looks nice."

iow, what we have now is not the best it could be, but it's better than the 
patches that have been submitted thus far, for all the reasons i've outlined 
in this thread (and the last thread on this topic, and the one before that =)

i think we largely agree on the idea that it should be aesthetically pleasing. 
i'm trying to outline some ground rules for what that means.

> > i half suspect that eventually one of the people standing behind the
> > "full width!" idea will actually produce a patch with a full width
> > highlighting that is acceptable in terms of not being eye catching in the
> > extreme, having very low colour saturation, looking pretty and not
> > interfering with either the text or drawing one to the "vast ocean of
> > emptyness" between the text and the edge of the menu.
> >
> > until that point this is really a useless conversation.
>
> I think Aurelien did that already, so the conversation is useful in forming
> a consensus. 

does someone have a link to Aurelien's code?

> Unless it just trails on to a point of last man standing... 

i really hope not. i'd *like* to see some sexy work on the selections. but i'm 
not going to be cool with something that looks *worse* than what we have, and 
personally i have way more pressing things to do with my time. and yes, 
simply extending the existing selection looks *worse*; as for why, i've 
already noted that.

-- 
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/20080227/aa1e296a/attachment.pgp