KDE: Learn to say no!

Arrrgh! (Shouting my frustration.)

Blogger Problem

This server is currently experiencing a problem. An engineer has been notified and will investigate.

That's what I got when I clicked to post... and all I wrote was lost. Arrghhh!

I think I'm never gonna trust Blogger any more and type everything with Kate, then paste everything later. This is the only way to be sure I won't suddenly lose everything. Arrrghhh!

(Closing the parenthesis.)

I must admit I'm one of these people who have difficulties to say no... but I'm learning. It's been a week since the first release of Serenity in the wild and I already posted an update.

I received some criticisms and I took some time to consider them. First, somebody didn't like Serenity's titlebar and wanted me to change it into a more regular one. I just said no and that I won't change a single pixel. That's what I did but that didn't prevent me from changing its color. There were no reasonable reason why a titlebar would use the defined titlebar color. Now Serenity offers the choice in between the regular titlebar color and the buttons color. That forced me to modified all the colorschemes which only had a neutral grey for the titlebar but that also made me realize that I didn't provide the colorschemes I intended to with the window decoration.

While I was playing with the colorscheme configuration dialog, I also realized that a checkbox didn't react although I was clicking on the highlighted area of its label. Well, that because a checkbox or radiobutton isn't supposed to react unless you actually click on the text of its label. I took some time to fix this but I'm gonna have to do some more. The highlight shouldn't appear unless the mouse cursur is over the area that would make the widget react.

Back to the window decoration. While I was changing the colors, I also added a theming engine for the button icons. Right now it only allows you to choose in between Serenity, Powder or Porcelain but all that matters is that it works. It will be easy to add a new theme when I'll finally have the enlightenment about what it must look. It's however very strange for me to see Powder or Porcelain icons over Serenity's button. That's the recycling effect. ;-)

Back to the style. The highlight over the checkbox and radiobutton labels had become much better but right while I was typing the new code, I could see that there was going to be a problem with a reverse layout (Arabic or Hebrew). I did some tests with KUIViewer and some forms I built to stop searching for the widgets I was working on. There was a problem. The highlight was on the left instead of on the right. I fixed this and some more problems that escaped my hawkeye with the comboboxes and the spinwidgets. From what I experimented, I learn that the drawing of these widgets must acknowledge the reverse layout but the special routines that are supposed to tell where their different elements are must --illogically-- not do it. My drawing routines made some calculations to determine the place of the various elements of these widgets before to draw them. I just copied these calculations in the part of the code that tells where the different elements are. In fact, it didn't worked as expected. Somewhere in its anthill, Qt automatically switched these elements and by always --logically-- acknowledging the reverse layout, they were reversed again in a strange way. I guess that's what this abstruse comment was supposed to warn against: "Is the handler width in pixelmetrics?" It went down the drain during a code cleansing. Now, there is my own comment: "It shouldn't work this way but it does. So..." As much abstruse as before except that I left the part of code --commented out-- that acknowledges the reverse layout, so nobody will have the idea to put it back in the source --especially, not me.

I also got a criticism about the color of the column headers that looked too much like buttons. I agreed but it turned out to be tricky. It took me four attempts to reach a very simple solution. I check the parent of the header widget. If it's a sort of QListView, we're dealing with a real column header, otherwise not. Because, these QHeader's aren't only used as column headers but also as menu titles and buttons in the taskbar and, in these cases, they must keep their button look. I wished I cured KMenu diseased that forces it to have disabled labels, but alas not. We're gonna have to wait till KDE 3.6 or 4.0 maybe.

That was pretty much all that I said and that Blogger trashed. Only the spontaneity is missing. --I'm amazed by my almost eidetic memory.-- ;-)

Now, I can finally go and dig into QtCurve sources. I know they contain special routines to handle a correct highlighting over the checkbox and radiobutton labels. I have a meeting with my friends Cut and Paste. ;-)