[Panel-devel] Kickoff menu items

[Aaron J. Seigo]

On Friday 30 November 2007, Aurélien Gâteau wrote:
> Aaron J. Seigo wrote:
> > hi...
> >
> > On Thursday 29 November 2007, Aurélien Gâteau wrote:
> >> - Changed the selection to fill the full width of the view. It looks
> >> more like a menu this way and it visually connects the item with its
> >> expand arrow on the right if there is any.
> >
> > this is problematic for other reasons. we've been through that on this
> > list now a few times. short story: clashes with icon colours (tight
> > spaces make this suck even more), it doesn't direct the eyes to the
> > meaningful content, it really clashes with the status bars on the
> > computer tab.
>
> I don't understand this clash thing. It doesn't seem to cause troubles in
> applications to have selected menu items painted the full menu width, even
> with icons. But I don't want to restart a discussion if there already has
> been one. Can you just point me to the discussion topic?

first off, we have more than just icons in the menu. we also have usage bars 
in the Places tab. those usage bars look possitively hideous with a 
non-neutral background.

we're also dealing with application icons in kickoff which tend to be full of 
colour, including the ones used in the selection (regardless of what colour 
that is). menu icons used on toolbars and menus tend to be kept simple and 
not quite so colourful to help avoid this issue. they also tend not to be 
32px high. all of the these contribute to a look that just isn't as 
sophisticated in the menu when there's a big square block of colour applied. 
it looks horrible.

i'd also like to have something that looks a bit more modern and not so ... 
1998. honestly, i don't think there is a *real world* issue with telling what 
is selected with just the text being selected. is there seriously someone out 
there who doesn't get what is the selected item?

finally, only painting the selection on the text draws the eye directly to the 
most meaningful part of the entry: the textual information. with a full width 
bar the eye tends to be drawn in the large "blank" area at worst and nowhere 
in particular at best; by highlighting the text, the eye is given a very 
vivid and instant cue where to focus.

i know that not doing the full width is different, but different is not bad in 
and of itself, and i think there are good reasons for doing it this way.

> > except that this isn't konq or dolphin.
> >
> > so, can we solve these issues in a different way?
>
> Sure it's not. Maybe a comparison with application menus would have been
> more relevant. In application menus, icons aren't painted washed out this
> way. To me it looks like there's a gamma problem in the bottom left corner
> of my monitor :-)

that's fine; we can paint the icons with 100% opacity.

> I think the gradient effect I suggested could be improved so that the white
> layer is applied over the icon instead of behind it. This could look nice,

this would result in the same effect, actually =)

> >> - I thought the title looked strange when it was vertically aligned on
> >> top of the item rect, so I centered it instead, and moved the subtitle
> >> on its right (in a crude way, since they use the same font).
> >
> > this won't work for long subtexts, which is when they are the most
> > important.
>
> I agree. But I still think the current layout look odds, with the big icon
> and the text smashed on top.

it's better than so much information in the view that scanning items is made 
difficult.

> I guess you don't want to have all subtitles 
> painted all the times to avoid visual clutter.

yes, the information density just gets way too high.

> Maybe it could just be paint in a lighter color than the title?

that was already tried. perhaps it could be made *very* light so that there is 
some visual cue its there but not so much that it floats into the foreground 
when visually panning across the page.

-- 
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: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20071201/b017b388/attachment.pgp