KDE: Plumbing

Last time, I told that Serenity was in the pipe... so I had to do a little plumbing to get it back. ;-)

I got my SVN account for a few days already but I haven't had any time to take care of it. I got "assaulted" with requests, bug reports, etc for Serenity.

While I was looking at the sources, I got an idea about how to implement my own diagonal gradient. I don't know how it happened but I suddenly got a flash in my mind. Probably a background process that just got finished? ;-)

What I didn't like with KDE's gradient was that when I calculated a light and a dark color from a base color to draw the gradients, the base color may not appear on them if the dark and light colors are too far away from the base color. So I implemented my own gradient routine which takes three colors as parameters: the top left, middle (or base) and bottom right colors.

Think about that: The top left and bottom right colors are defined, and the base color defines the bottom left and top right colors. Things are easy to handle. In pseudo-code:

leftDelta = (bottomLeftColor - topLeftColor) / height    # Vertical deltas
rightDelta = (bottomRightColor - topRightColor) / height #
#
leftColor = topLeftColor              # Intermediate step
rightColor = topRightColor            # to make things clearer.
#
for each y in height:
    delta = (rightColor - LeftColor) / width             # Horizontal delta
    accumulator = leftColor
    for each x in width:
        color in (x, y) = accumulator
        add delta to accumulator      # Make color evolve horizontally.
    next x
    add leftDelta to leftColor        # Make colors evolve vertically
    add rightDelta to rightColor      # along the sides.
next y

Of course, in C++, that's not so simple because you have to take care about where to use float variables, where to use integer ones and about the fact that you have to triple all your calculations for each RGB components of a color. But that's pretty much the idea that flashed in my mind.

As a result, Serenity's gradients are subtly different from previously and just a tiny bit faster because I avoid using KDE's routines which are outside of Serenity. Well, the difference in speed isn't that big because I also adapted KDE's routines for the horizontal and vertical gradients into Serenity. I found it a little bit silly to have to write in the changelog that Serenity would use its own gradient routines... most of the time.

Of course, I also implemented the same gradient routines into Serenity windec. That's a bit stupid to have twice the same thing in memory but the only other way would be to build a library that could be called by both the style and the windec. I'll think about that for Serenity 2.0. ;-)

About the windec... Last time, I stopped with invisible icons on the buttons. I liked it much but I thought that maybe I was too extreme --as usual-- so I created a new button style: "Colored buttons". The buttons use their glow color as default color plus the icons in a matching color. That's less extreme. And since I now had colored icons, I added another button style: "Colored toolbuttons". By default only the icons are visible in a color mixing the glow color of their button and the color of the title text.

And while I was at it, I added a switch to deactivate the framing around the title text so that only the buttons look like buttons. Somebody criticized "my" title framing saying that it looked like a horizontal gradient... so I've hidden it. And I like it so much that way that it became my default setting with the colored buttons.

About the style... I was a little bit extreme in my fight against the hardcoded colors within KDE. Somebody complained that he missed the warnings in Konversation which changes the color of a tab label to show the arrival of a new message. I started my war against the hardcoded color because of Konqueror which turns the label of a tab into blue to indicate that something just happened to an item in the directory displayed in this tab. Konversation was a collateral damage. My way of fixing this is by offering alternatives to the hardcoded colors i.e. bold or italic text instead. Of course, because I prefer no such warning at all, it is also possible to totally deactivate them and, for those who don't mind the hardcoded colors, it is also possible to allow the default behavior of the application. That should make everybody happy... Well, except me! Because now I feel I have to track down every such hardcoded warnings and make sure that Serenity displays them all the same. (Good luck to me!) ;-)

Something else that shouldn't raise many complains: the progress bars. I changed the colors they use. I was thinking about it for a long time because they looked too "right in your face" in the GIMP. No more highlight color. They are now almost always white and grey. I say "almost" because it depends on if you change the usual black text on white background used in the edit field. That's the colors the progress bar now use and it's much more "serene" compared to the flashy green I had with my current "Wooden Cabin" colorscheme.

And a failing experiment to finish. Failures teach you as much than successes. What I learned is that those ATI video drivers are pure crap.

My nephew gave me his old ATI 9600 PRO 128MB to replace my really old ATI Radeon VE with only 32MB. To still be able to play Unreal Tournament or ClanBomber, I had to install ATI's drivers... and things turned bad. First, I had to undo my first install because all I got was a black screen at login time. I re-installed my trusty Radeon VE and downloaded ATI installer. That was a little better... except that I was stuck in 2560x1920@60Hz. Lucky my wonderful multisync CRT can cope with that because that's the resolution I have to log in. Insane! After that KDE switches to a more reasonable 1280x960@88Hz (because I ask it). I tried the "aticonfig" to add some reasonable resolutions for the login and I ended up stuck in 800x600 even in KDE. I undid what "aticonfig" did. 2560x1920 isn't such a problem as long as I don't use the mouse since the cursor is sooooo tiny.

ATI should hire a bunch of Open Software developers to do the job. Themselves are apparently not up to the task when you see what's in "xorg.conf". It's a real mess!

Unsatisfaction leads to frustration which leads to bitterness if no cure is expected in a foreseeable future. And that's what happens in the closed source environment. Big companies always seem to have other interests than the satisfaction of their consumers while in the Open Source world --once the egos of the developers set aside-- ;-) all that matters is what you deliver to the users. Sub-standard products for a small market is out of question. And that's what the ATI drivers are: sub-standard products. I had none of the problems these drivers cause with the Open Source driver for my Radeon VE.

I hope that AMD will care more about Linux than ATI... but I don't have high expectations. :-(

Well, time to go elsewhere!