cat /dev/maxilys

A glance in the mind of a KDE/Linux developer to see how ideas turn into code.

2006-03-28

KDE: Breaking the limits

OK, don't listen to me when I say I can't do something, I can always do more. ;-)

Yesterday, I was looking for a way to improve the titlebar of the floating toolboxes. I found something. I improved the icons of the titlebar buttons but I stumbled on another problem. These icons are XPM images and handled as such by the underlying engine --i.e. as an array of strings. XPM also means that the colors are fixed and they are actually fixed to black in KDE. That's a big problem if I want them to have the color of the button labels --whatever it is. I could have change these XPM into private bitmaps but there would still be one icon --on which I have no control-- with the wrong color. I had to find something.

The first solution that came to my mind was to rebuild the XPM on demand. Well, do you know an easy way to turn a QColor into an hexadecimal string? For a moment, I thought about writing a tiny subroutine for this task. For exactly 0.6 second. ;-) I remembered that this very thing already exists somewhere in Qt which stores the QColor's as hexa strings in its config files. A few more seconds to remember where I already used this stuff...

That was in Senerity window decoration. I once wondered why storing a QColor was so complicate for a windec and I tried to use the same method than for a style. But it didn't work. Nevermind. All that matters is that I retrieved what I wanted: QColor::name().

With this I became able to rebuild the XPM string that contains the color... and the miracle happened! When KDE or my style request one of the XPM, its color get automagically changed on the fly. And that means a lot! It works with all colorschemes including the dark ones which aren't condemned to unusable buttons any more. (These images are minimized floating toolboxes in KDevelop Designer.) As you can see, the mini-titlebars reproduce the behavior of the regular ones: Toggle buttons like the minimizer act like checkboxes, they stay pressed when activated. When I first saw this, my reaction was "Amaaaazing!" :-D I couldn't resist to the urge to brag about it.

Something else: The mouseover effect over the checkbox and radiobutton labels. This story turned into a nightmare. I managed to do a few things but I'm still gonna have to give a deep thought to it. QtCurve engine isn't that similar to Serenity's one. I was able to cut and paste but the result was too weird to be left within Serenity. The mouseover effect worked perfectly on the labels but the buttons of the checkboxes or radiobuttons didn't react as expected. They stayed hovered while the mouse was over the widget and not only the actual area to activate them. I'll re-try to work on this later. There are still plenty of version numbers beyond 0.4. ;-) I should already be satisfied I let the mouseover effect acknowledge multi-line labels and pixmaps as labels. Not all styles can do this.

Any way, Serenity 0.4 is released. There's already been around 20 downloads. I can sit and wait for the bug reports...

2006-03-26

KDE: Reaching the limits

That's it, I reached the limits of what I can do. There are widgets that just can't be styled. For example, the ugly misnamed QDial. You probably haven't ever seen this circular widget with a rotative hand like an analogic cynemometer --the round thing where you can see your speed on a car board. A quick look in Qt sources shows us no call to style().something(with a lot of parameters). No styling. Period. That's one thing. There is also this KKeyButton for which I have no idea if it's just possible to style it.

And finally, I found what was the widget used as window titlebar for a floating toolbar. It's just CC_TitleBar. I've already finished working on it. It now looks like a little more like the titlebar of a regular window --except a little smaller.

But I wasn't able to do all I had I mind. I reproduced the look... but I wanted more! I also wanted to reorder the buttons. And this part led me to troubles. 'ld' reported an error when I tried to use what a window decoration uses to know the order of the buttons. My googling session was unproductive. I was looking for something vague with generic solutions in which I could pick up some inspiration. I could find the exact text of the the error reported by 'ld' but it only applied to specific situations (this app or this lib, in this environment). I watched two dozens of pages before to give up.

Any way, I managed to get the buttons of the titlebar to react to mouseclick but not to mouseover. Qt sources talk about it but it's not clear at first sight when and why it applies. On the other hand, the titlebar changes of color when the pseudo-window is raised. Nice. :-)

The only thing that doesn't satisfy me right now is the icons on the buttons. I let KDE do the drawing and the color isn't right. I haven't done the new package so maybe I'll take the time to draw my own icons --to satisfy my hunger for control. ;-)

After that, I'm gonna do some new snapshots with the improved colorschemes and the new window titlebars. Serenity-decoration-0.4 has been waiting its release for a week at least. It's high time to give a new Serenity to the world. ;-)

2006-03-22

KDE: Beauty within

Well, I'm gonna try to use Blogger web interface directly... but probably I'll paste everything into Kate before to publish. <grin>

Yesterday, I saw the most beautiful dialog I've every seen in KDE. It is part of Qalculate. I've always been attracted by Qalculate, probably because of the nice snapshots but also definitively because I find it more logical to get rid of the calculator style keypad when you have a full keyboard at hand.

So I finally installed it yesterday and I kicked KCalc out of the Kicker. Qalculate is fuller than an eggshell when it comes to available functions. You can calculate in any unit that come to your mind, in any number base, convert in between the units, the bases. The number of functions is so large that you have an auto-completion to help you find the right one. Something that pleases me is to be able to do calculations in base 12, especially to be able to enter numbers directly in duodecimal. This possibility may not be useful for everyone but you can also do the same in any "regular" base: binary, octal, hexadecimal. They are some many things in Qalculate that I'm probably going to read the manual. ;-) And amongst all this, I found a periodic table that demonstrates the potential of Serenity. I tried with other styles and I ran back to Serenity. Oh boy! I don't want to brag about Serenity but it's a real beauty. (This is what I call "self-satisfaction".) ;-)

Back to Serenity. Today, I got a proof of validity of the Open Software model --if I ever needed one. Somebody reported a strange bug. I looked in the source, I got an idea, I tried it, it worked for me. I sent just the file I modified to the bug reporter, he built it and answer me it also worked for him. Problem solved in less than one hour. If there weren't something else I wanted to tune, I could have released a new version one hour after the bug report. Try to do the same with a big company (of which I won't mention the name in order not to soil screens), but don't sit waiting in front of your screen for an answer. :-b

Now, I'm gonna do some tuning... or something else.

2006-03-17

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. ;-)

2006-03-08

KDE: Satisfaction

Blogger is down... Down the stairs. Probably pushed by some malevolant bug. :-D Meanwhile, I'm using Kate and I'll cut and paste later.

Well, I was saying "Satisfaction". Somebody finally gave me some usable infos to solve my QToolbox mouseover problem. (Thank you, Michael.) It appears that no mouseover was reported by the event filter because I didn't polish the right widget in the right way. Now, it works but maybe just a little too well. When I press (i.e. click) a toolbox tab, the mouseover effect reacts like a toothpaste tube, it splatters all around and several tabs are drawn as if they were under the mouse while they are definitively not. It looks like to happen at random but for my developer eye, it doesn't. I've already seen this strange pattern of incorrectly hovered tabs during my attempt with widgetAt(). I'm now almost sure I found a Qt bug.

Me: Who's there?
Qt: Somebody, but I'm not sure who.

That looks like fuzzy logic to me. And I don't even mention the strange path I must follow to recognize a mouseover situation. There's something wrong in this QRegion but I can't QPoint it (yet). (Overdose of Qt.) ;-)

All this doesn't prevent me from being very self-satisfied because I removed a bug of the Twilight Zone kind from Serenity. Along the evolution from Serenity this bug appeared and disappeared for no reason I'm aware of. The grip of a tiny scrollbar slider could disappear sometimes during a redraw. That couldn't happen because the slider is drawn with two instructions the one after the other but it happened anyway. To cure this disease, I buffered the drawing and I now bring the slider on screen in one piece. This a total waste of memory and CPU but if this is the only way, so be it.

The funny thing is that I now remember I already used such a buffering but I removed it as useless during a period when the bug had disappeared. It looks like I enjoy re-inventing the wheels I invented once and tossed in a corner as useless inventions because it snowed and skis became more useful. (If you see what I mean 'cause I don't.) ;-)

While I was working on these sliders, I made a last minute change to all the sliders. First, I set the grip of the scrollbar sliders perpendicular to the groove. It's now a tiny subtle mark in the middle of which the length doesn't grow with the length of the slider. Any way, a perpendicular grip is more logical than a parallel one. Second, I also changed the other kind of slider --the one that can have tickmarks like the volume slider in KMix. They are now parallel to their groove so that they look long instead of wide. The GTK-Qt engine likes them much more! That wasn't a real bug but a visual glitch due to the fact that a slider has a fixed size and the one I chose was too big for GKT that doesn't stretch its layout the way Qt does. A tiny bit of the sliders was always missing in the GiMP. Problem solved!

Now if I could take some time to clean the style configuration dialog, I could make --at last!-- Serenity's first release package.

Now, with the modifications I made to the sliders, I have to redo all my
snapshots. I'm already feeling too tired... ;-)

2006-03-03

KDE: Change of path

That's it! Frustration is over. I cried everywhere but nobody knows anything about styles. The Trolls at Trolltech certainly know more than the average but I'm not ready to pay for it. I don't develop styles for a living. Maybe I'll file a bug report because I've got the persistant impression I stumbled on a bug: Qt has some difficulties to recognize its children in the crowd of a QToolBox. When you point a finger and ask it "Who's there?", it has a tendency to give random answers. :-) (I like the way I phrased my sentence.)

And if Qt can't easily answer to the question "Who's there?", well, it's also difficult to achieve a mouseover effect.

But I said "Frustration is over"! Oh yeah! I was tired to fight against Qt and to get no answer to my questions so I took a different road. There was no reason why the toolbox tabs should resemble "regular" tabs. So I gave them a totally different look. It's hard to explain with words, so see for yourself. (It's the left part of KDevDesigner.) It's a kind of mix in between the "regular" tabs and a listbox like the one in Kontrol Center.

The work I did on these widgets is obvious. I'm satisfied. ;-) Well, a mouseover effect would really satisfy me but in the mean time, I'm as satisfied as I can be.

There are still a few widgets deep in KDE that I must take care of but I'm decided to make an announcement on KDE-Look. (Please somebody, remind me that I have to remove all those unnecessary options from the config dialog.) ;-) Now, I have to decide which colorscheme will be my ambassador. Probably Mare Serenitatis which looks like to be silver and gold... And Outer Space for the dark colorscheme lovers! I'd like to show all of them, as well as all the nice widgets but that's just impossible unless I want to link tons of snapshots to my announcement. (Maybe in a few years, when Internet will be as fast as a harddisk.) ;-)

Time to go and make some snapshots of Konqueror with Serenity style...