KDE: Serenity forever...

This post should have been "1.4 on 14" to announce Serenity 1.4 on 14th october but I didn't find the time. Then, a few days ago, Blogger was utterly slow so I didn't post. I postponed until today. Well, it doesn't matter. Everybody who cares got the news from KDE-Look: Serenity 1.4 is out.

I had to take care of a memory leak. It was a small leak but a very regular one that could fill your entire memory in no time. First, I thought it was a problem with the animated progress bars because the leak was very obvious when an app kept a progress bar spinning on screen. I broke everything into pieces up to the point of being absolutely sure that Serenity doesn't request memory to handle the progress bars... and it didn't stop the leak! Moving the mouse over the menubar or the toolbar was actually all that was needed to see the memory used by an app grow and grow.

I was in trouble. It meant that the source of the problem was the drawing of the gradients. A thought crossed my mind: Serenity without gradients? Impossible!

In fact, the problem was all these temporary QImage's that Serenity used without explicitely deleting them, expecting Qt to do it... while it doesn't. And that was it. No more diaper for Serenity. ;-) I could release.

I applied the same changes to Serenity window decoration --although apparently the QImage's were handled in a different way that didn't generate a memory leak-- and I could carry on with more futile things for the next version. Already!

I didn't do what was planning last time about the menubar. Things didn't turn out as I was imagining. Well, it just didn't work. There was a hole in the windows because nothing was actually drawn. So I just kept my previous optimization. I however did something for the menubar: I changed its drawing in the colors configuration module of the Control Center. For some reason, this module uses a very personal palette and the faked menubar was drawn with the titlebar's color. Now, Serenity just draws a solid rectangle with the window's background color. That's better... and even better when changing the palette has an immediate effect in a colors configuration dialog!

Before taking care of this, I also add a new checkbox in both the style and the window decoration: "Use purer colors". It applies to the mouseover effect and changes the way its color is calculated so that it appears purer. In the style, what it does is to give approximately the same color to all the hovered widgets. The effect is interesting but I don't use it. I wanted this option especially for the window decoration so that the hovered buttons actually show their "glow" color and less of the titlebar color.

It suits well the new titlebar style: Solid bar. I've always wanted to color the titlebar but never found the right way. To fill the titlebar usually also implies filling the borders of the window and I don't like the way the decoration and the window content look like to be two separated things. IMHO, a transition is needed in such a situation. Powder, my previous window decoration, is a perfect illustration of a nice transition but it has a huge border to be able to do so. With the six pixels Serenity uses, there is no room for such a thing.

What I do is to exactly what some people complained about. When I removed the space in between them, several buttons in a row looked like a solid bar, especially with the menubar and colored menubar style. So I just extended this solid bar to the whole titlebar, including (eventually) the zen border. Like this:

And that's all. If I also filled the top above the solid bar, the buttons would like misaligned. That would oblige me to also fill the space below the solid bar... and in that case, the menubar would become too close from the titlebar. That's what happens when you use Serenity's solid frame for the menubar but not Serenity's window decoration. So, nothing of this and this new titlebar style has become my favorite one.

Now, I have to go back in my cave and dig deeper to find why the KonqFileTip's don't obey me. ;-)