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!

KDE: In the pipes

That's it, the new version 1.1 of Serenity is in the pipes. I already packed the window decoration sources. I need to do a few changes in the new colorschemes I added to the style and I will be able to pack these sources too.

There's nothing new in the style, except some corrections of two visual bugs that I totally missed last time. I never use the sidebar of Konqueror so I didn't see what happened to the whatever-its-name button with the popup menu. On the other hand, I tested extensively the QToolButtons but I didn't test the tab focus. So when I introduced QToolButtons in Serenity's windec configuration dialog, I got an unpleasant surprise. The focus rectangle was drawn twice. That's strange because I don't remember seeing in Qt's sources that it draws the focus rectangle by itself. Whatever. Two bugs fixed.

And why did I need to add new widgets in the the windec configuration? Once again, it's because of the Fitts' law: Bigger target, easier target. So now, there's a toolbutton for every windec button supported by Serenity. If you activate it, the corresponding button will be enlarged by a factor of 3/2. It means that it doesn't apply to the closer button only, you can choose which one(s) you want to enlarge... upto enlarging all of them. I chose to enlarge the two buttons I use the most: the closer and the minimizer. It looks like that:

And before that, I found what the new Alpha icontheme should look like. I removed the letter-like icons that I found too weird and I drew new icons in the alpha channel. They are totally transparent... well, invisible. ;-) You know where your buttons are, so the symbols are useless. However, in order not to be too confusing, Serenity uses the mouseover color to draw the buttons.

The symbols appear on mouseover and they stay visible on the toggle buttons (maximizer, sticky and keep above/below) which are activated. I don't know if this will be my future favorite button style but I'm using it right now and I find it nice and very usable.

On the KDE front, my cosmetic patches for KDE 3.5.5 are also somewhere in the pipes. I'm waiting for my SVN account to be able to apply them directly to KDE sources. Aaron Seigo got convinced that I could do it myself. I'm gonna have to learn some new tricks; SVN is rather abstruse to me yet. I don't want to bring down the whole thing because of my inexperience. :-D

Patching KDE is a rather addictive occupation. I can't help it...

I'll come back when I'll get my SVN account to tell how easy or hard it is to work with SVN.

KDE 3.5.4: Some reasons to get excited

KDE once again escaped to its developers and a new release just appeared yesterday. This is only a maintenance release but I got however excited. The patch I attached to one of my bug reports is in this KDE. ;-) (As if that was the only thing that matters.)

However, I still had to jump through some hoops during the upgrade. First, the icons that I don't like. I definitively prefer the previous Crystal SVG incarnation, especially the action icons. That's a detail but the icons are included in KDE-base and there's no way not to install them. Second, Konqueror's toolbar got another of these un-erasable icons that I had to remove by hand. (Grumble... SuSE... Grumble...)

To retrieve that excitement, I apply my seven cosmetic patches to KDE. See my blog of 4th June about previous update for details. The ones that aren't described there include some patches to remove some hardcoded colors or to make some KDE widgets respect the reverse layout a little more (for right-to-left scripts) --There is still work to do in this area.-- or else to prevent an also hardcoded content shift here or then under mouse click.

And this time I send all my patches to the KDE-devel list. For some reason, I was waiting. I waited so long that KDE 3.5.4 caught me by surprise. Alas! I wanted to send my patches before its release. I'm not sure every of them will be accepted but I hope some of them will. That will make me less work for KDE 3.5.5. ;-)

So I updated KDE, it was time to update Serenity too. I'm not really satisfied with the new Alpha icontheme for the window decoration. It's not ugly but it's strange... or at least very unusual. I don't know what to do with it yet. If I remove this icontheme, I'll have to replace it... but with what? No idea. And that will leave nothing new for the window decoration but code improvement. Not very visible. I'll figure out something.

In the mean time, I made the modification to the style that I wanted to do for a long time: Give the possibility to tune the popup sub-menu delay. I use a lot of quick browsers and I always found that the sub-menu open themselves too quickly. Qt, nice Qt allows us to change that. The usual delay within KDE is around 1/10 sec. Serenity allows you to have values in between 1/50 sec and (around) 1/3 sec. I don't know if there is any interest in accelerating the sub-menus but, personally, I already slowed down mine to the maximum. I have to stop moving the mouse so that a sub-menu gets opened. That incredible! The mouse cursor looks like to fly, slide, whatever over the menus. For the quick browsers, that's nice that mammoth directories like /bin or /etc don't slow you down when you don't actually want to open them. For the regular menus, that delay is irrelevant but in the K-Menu that's different. There are so many sub-menus that is nice they don't get opened just because the mouse hovers them.

In fact, I think that I should even increase the delay up to 1/2 second. I noticed that I always slow down when I'm about the reach my target. Some parasite sub-menus still appear. A longer delay should also prevent this.

And I'm leaving right now. I got an idea for a new Alpha icontheme. Something that will justify its name. (A background process just terminated.) ;-)