Divide and konquer!

No, my last post isn't over a month old. The problem is that the last time I blogged, Blogger was "off duty". It crashed just when I published so my post got lost. I have what I wrote --because I trust so much Blogger that I copy every post in the clipboard before publishing-- but these are old news. So, let's start again.

Back to business! The monthly release of Serenity is on its way. I touched something that has annoyed me for a long time: the scrollbars don't sink under the pressure any more. I had found this behavior ugly but I never did anything because I was so used to see the scrollbars react like buttons. Somebody asked me if it was possible. I looked, patched and kept the answer for me. ;-) Whatever, that's better now since I've already done my best for these scrollbars not to look like buttons.

Another itch I had to scratch was the way the colors of the gradients were calculated. There were several problems: You can't have a color brighter that white, black can't be brightened nor darkened.

For a color brighter than white, I took as solution the one used by the washing powder makers: to add a little touch of blue. That wasn't perfect but it worked good enough to have a "milk look", i.e. white buttons on a white background. That wasn't perfect because the little touch of blue didn't fit with every colorscheme. A better solution was to add a touch of the global tint. I found a way to calculate it when it's not defined by the user. That's still not perfect but I'm getter closer.

I found why the black can't be brightened in the sources of QT. The code just doesn't work with RGB values equal to zero. It does it's calculations but it will always return the same black: #000000. Totally useless. So I wrote my little routine that recognizes all the greys (from black to white) and returns better results, including the brighter white with a touch of color. Wait... and see. ;-) I wrote my little routine because darker than black is the same problem that brighter than white but the other way around.

Since I found a little stupid to handle only the special cases, I ripped QColor::light() and QColor::dark(), simplified them and put the result directly into Serenity. I gained some more few ms on each gradient so Serenity is faster... again! Well, that's not as obvious as with some of the accelerations I previously did but I'm sure the CPU notices. ;-)

While I was dealing with the colors, I changed those of the gradients of the tabs and of the menubar. I made them more obvious in a very discreet way. (That's an oxymoron...) ;-) And, in both cases, Serenity now offers more choices to make them look brighter, darker or both and vice versa.

I also simplify all the tabs: No more button-alike shape on mouseover, the tabs only change of color and if they're concave, they become convex to look more like something to be clicked. And I did the same for the menubar but I kept the button-alike shape for the cases where the menubar groove is flat --i.e. either solid or empty.

The penultimate thing I did was to use an underlying unused mechanism in Serenity: the possibility to redraw textboxes when they acquire the focus. I thought it was useless and that the blinking cursor was enough but, in fact, I like the subtle way the textboxes can be highlighted. In this respect, Serenity was well designed. I acknowledged the focus in changing the color of the frame when needed and it immediately worked everywhere: the textboxes, the edit lines, the spin widgets and the editable comboboxes all at once. Neat! ;-)

The last thing was to enable you to set the popup sub-menu delay up to 1 second instead of 1/2 second. You will probably need some time to get accustomed --I did.-- because 1 second is a really long delay. The sub-menus look like not to be reacting and you need to learn a new behavior: to click to make them appear... instead of letting them pop up your nose. ;-) Now, what would be nice is that the sub-menus close themselves with a second click so that you have a total control. Unfortunately, KDE only closes the sub-menu to re-open it immediately. Maybe should I ask to the Trolls if they can do something for me? The future will tell.

That should be enough to justify a new release but I have to take care of something else first: The mess I made in the color selection of the buttons of the window decoration. That's more than a problem of label. That's a real usability issue. The various options produce, well, various results but in an unpredictable way. I was trying to change these buttons I see everyday and I ended up with the same buttons. I got lost in this jungle of too subtle options.

When I designed this mess, I was obviously working le nez dans le guidon as we say in French ("the nose on the handlebars"), in other words: too focused on what I was doing without thinking of where I was going.

What I needed to do was to clearly indicate, on one side, what base color is used to draw the buttons and the symbols and, on the other side, what color will be mixed with them, if any. That makes more sense this way... even if what I say doesn't make much sense. You'll understand when you'll see. I already re-designed the UI and it was a hard job. I failed at squeezing all the options I wanted into the "Colors" tab page and keeping a reasonable size for the whole dialog. So I kept the things the way they are, with the buttons and symbols color selection on the "Buttons" tab page.

That's what the title means: Divide the options in manageable (meaningful) units to conquer, tame, master, whatever them.

Well, now, it's time to turn my ideas into code.