KDE: Resistance... again!

I couldn't resist to the urge to stick my nose back into Serenity. I said I wouldn't touch it so often after version 1.0. I almost kept my promess...

There was that tiny detail I couldn't get out of my mind. Somebody released a style where the arrows of the spinwidgets are disabled when the spinwidget has reached its minimal or maximal value. I didn't remember who or what style but last time I updated QtCurve, I saw its spinwidgets.

I never use QtCurve but it's part of the few styles I update whenever a new version is released. So I can keep on digging into recent sources. Although I don't do it much any more. Serenity is like me, it has its oddities that can't be found anywhere else... and digging into Qt and KDE is much more what I need now. Whatever...

Well, QtCurve's spinwidgets. I looked into the sources, found what I wanted, make a little detour into Qt documentation and that was it. No special trick is required. Serenity just asks to Qt if the arrows are enabled and it draws them accordingly. So easy... ;-) ...when you know what you're looking for.

I did this last week. Yesterday I launched the GIMP and lovingly draw a new icon theme for Serenity's window decoration... pixel by pixel, just the way I like to do it. :-D I didn't add it to the sources yet. All I can say is that it was one of those ideas I've kept on the back of my head for a long time: Letters as symbols.

Serenity already has mathematical symbol as icons --in its eponym icontheme. So I drew letters in a Times style. Some letters were easy to choose. "X", "?" and "S" for, respectively, the close, help and sticky buttons. I chose a little caps "A" and a little caps "B" for the "Keep above" and "Keep below" buttons. I put "A" to the top and "B" to the bottom so that the design of the icons also give indications of their use. The --not so-- hard part was to choose the letters for the menu, minimize and maximize buttons. I chose "K" for the menu because that's the way almost all Serenity's iconthemes are. So I could use what came first to my mind when I thought about a letters-like icontheme: "m" for minimize and "M" for maximize. Here's the result:

I made a little fake with the GIMP. Simply implementing this new icontheme in the windec would have been waaaaay much faster. Some people apparently enjoy doing things the hard way. ;-) (Temporary icontheme name: Alpha... because of a lack of imagination.)

Tomorrow, I'll deal with the Fitts' law. One of its rules says that the bigger the target is, the easier it is for the user to point and click. (Totally approximatively.) All this idea came from what Florian Grässle proposes in his blog about KDE's interface.

Use toolbar icons with text: The only thing I can do here is to hurry to send my patch to KDE-devel in order to correct this weird grey-bluish color used by the hovered labels. I already said so somewhere else but, before to make it KDE's default behavior, some deep thoughts will have to be given to shorten the labels. When I see that the label of the smallest icon in Konqueror's toolbar is "Delete the content of this bar"... I burst into laughter. Sure, it will increase the size of the target... but isn't it just a little exaggerated? :-D Whatever, I will always revert to small icons without label!

Take advantage of unused space between menu entries: Nothing can be done right now. Well, in fact, you can reduce the space in between the menu entries to nothing but there's no way to enlarge the menu entries themselves, neither within KDE nor Qt. Maybe KMenuBar could do something like adding white spaces around every menu label or arbitrarily enlarge the widgets on the fly. I don't know if it's possible without seeing the menu entries getting indefinitely wider and wider. Well, at least, that would be funny. ;-)

Make the whole width of checkboxes clickable: I totally disagree. I would be strange to be able to click --apparently-- on an empty space and to trigger an action. The other way around: No hover reaction unless the mouse is over the label or the checkbox is just right. This is the way Serenity works and I had such a hard time achieving this behavior. Besides, some checkbox widgets are so oversized that it would look ridiculous.

Introduce a dedicated resize handle: No thank you! To be able to pull any border of a window is waaaaay much better than having to move the window around in order to release some space around the resize handle before to finally be able to resize the window. The problem is with the users thinking that any space given to the window decoration is a wasted space. Look at all the highest rated windec on KDE-Look. They all have a thin border... expect Powder. (Boy, oh boy! How did my windec reach 78%? Maybe should I update it too?) Any way, resizing windows isn't my major activity. Every application was resized once in the past to suit my liking and unless I don't like this size any more, I don't resize. Sometimes I maximize a window to full width or full height but that's all.

Populate taskbar from left to right instead of from top to bottom: I don't feel much concerned. My taskbar is on an autohide panel. I don't see or use it often enough to bother how the taskbuttons are ordered. My usual use of the taskbar is to restore a minimized window once in a while so I always have to look for what I want.

In maximized windows make scrollbars edge aware: Good luck with this one. Serenity is able to remove the border from a maximized window but it can't remove the frames in it so that the scrollbar gets to the border of the screen. There will always be one pixel --at least. Any way, who cares? Who still uses the scrollbars with our mouse wheels? If I was able to remove the arrowbuttons and never had to bother they weren't here any more, that's because the scrollbars have become more a visual indication than a widget thanks to the mousewheel.

Make systray "edge aware": Here is another frame problem. Even if the frame is invisible, there is at least one pixel around the systray and the icon can't be at the border of the screen. To have a mouseover effect like with the toolbuttons may help a little. When you move the mouse cursor, if something happens (a mouseover highlight), it triggers a reflex to slow down. It should prevent you from actually reaching the border of the screen.

Connect labels with their respective [...] widget: This proposal is interesting. There is often a label with a keyboard shortcut in front of the editlines, comboboxes, spinwidgets, etc. When you use the shortcut, it activates the focus on the related widget so you can directly use it with the keyboard. But what happens when you click on such a label? Nothing. On an HTML page, it looks like you click directly on the widget instead of the label. That's an interesting behavior.

Some gears started spinning in my head. Can this behavior be reproduced with the regular widgets? The answer is yes --theoretically. What I have to do is catch the mouse click in the event filter, check if there is a "buddy" (Official Qt terminology) attached to the label and, in that case, construct a QMouseEvent for this "buddy". I haven't thought yet about how to trigger the event, I need to dig into Qt's docs. Theoretically, it will work.

I'm already gone...