zoomers and menubars: answering the questions

(Stage notes: aseigo slips into his Ann Landers outfit.)

> What's this about removing the Desktop Menu option? Sounds very confusing... can't
> be good for usability. Why should one know about Kicker internals (panel this,
> panel that) just to enable the Desktop Menu?

it'll work much like it does now: click a checkbox and you get a desktop menu at the top. but now you'll be able to optionally add applets and other kicker stuff to it. we'll also be able manage the strut geometry properly by having it all in once place (kicker). this will make the menubar just as easy to set up, while killing some bugs along the way! in fact, it will make setting up a more featureful menubar easier by promoting the more flexible kicker approach. this is a win-win situation.

> Could you make the icon zooming thing a choice, instead of just throwing it away?

i could. but here's why i'd prefer not to... our zoom icons are little more than a (poor) rip-off of a MacOS X interface, the dock. it's pretty well known that for all its sex-appeal, the OS X dock sucks usability-wise. ask Raskin or Tog, even.

but our panel in KDE isn't anything like the OS X dock. kicker does a lot more than provide icon buttons and a confused taskbar. zooming buttons make very little sense for menus (right now we unzoom them to make way for the menu), and we get bug reports that zooming doesn't work on the quicklauncher, various applets and the systray. our lack of consistency, which is a rather intractable problem, is sad. just making the zooming smooth isn't enough to make this feature work nicely.

to make matters worse, the code that supports zooming functionality is not exactly pretty. here's a comment from that code that says a lot:

/* This event filter is very tricky and relies on Qt
internals. It's written this way to make all panel buttons work
without modification and to keep advanced functionality like tool
tips for the buttons alive.

Don't hack around in this filter unless you REALLY know what you
are doing. In case of doubt, ask ettrich@kde.org.
*/

now, i'm all for cool hacks and respect Matthias' abilities as an uberhacker. but kicker has a frightful number of options and the all interact with each other in many splendorous ways. we really don't need more hacks in kicker to make things even less fun to work with.

i'd also note that doing zooming buttons properly (e.g. smoothly in and out) in the panel results in a lot more resource usage. one of my personal goals is to shrink kicker's system requirements.

i'm also sensitive to the eye candy lovers out there. but let's get creative for a moment: wouldn't it be cool if we could come up with something that makes kicker buttons look beautiful that isn't a rip-off of some other interface, that is done Right(tm), that is consistent and remain light on the resources? heck, maybe something that is even useful, too!

and yes, i'm looking for ideas and people willing to implement them =)

> Kde is about choice, don't think the gnome way

KDE is about making software that is better. sometimes that means providing all sorts of choices, but not always. kicker has an ungodly number of features, several of which aren't even in the GUI config dialogs! many of these features interact with each other, resulting in a HUGE testing matrix. this makes development extraordinarily and needlessly difficult. it makes supporting kicker difficult. it makes kicker take more resources than necessary. now, i'm all for choice, but let's try and make them GOOD choices, the burden of which are worth bearing.

> I always thought that the rationale behind growing icons was Fitt's law? IE,
> make the icons bigger when needed to make picking one easier/faster, without
> eating up desktop real estate the rest of the time

you still have to move your mouse those tiny increments in the places this makes a real difference (tiny panels). not to mention that the difference between the zoomed and unzoomed icons on a tiny panel aren't exactly huge.

i do agree that picking a button faster is a good thing though. descriptive text that doesn't obscure the button like our tooltips currently do will go a lot further towards that end, however.

> I believe people use this without kicker in combination with things like *karamba
> or smoothdock(?)

and they will continue to be able to do so. with the removal of Panel::the(), people will be able to optionally remove the "main" panel (since there no longer will be such a thing, really). and if the specter of running kicker is abhorrent to them, then those other apps can provide their own implementation of the desktop menu.