cat /dev/maxilys

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

2006-02-24

KDE: Persistance of frustration

Just two words to say that I retrieved the 3rd app using QToolBox, it's KPDF. But it didn't help me to do what I want with these widgets. The more I work on them, the more frustrated I grow.

Meanwhile, I did something that I found more satisfying: Code cleansing! When you work with Qt geometry, it's like entering a jungle of parentheses. The worst are those empty parentheses everywhere that bloat your code. Serenity really deserves a version increase after what I did.

Whenever possible, I inserted a block of code resembling the following:

int left, top, width, height;
that.rect(&left, &top, &width, &height);
int right, bottom;
that.coords(&left, &top, &right, &bottom);

So, instead of the bloating that.left(), I can just use left. And the same apply to left, top, width, etc. That removes thousands of parentheses --I didn't count.-- and the code become more legible to an human eye.

After that, I could keep on stumbling around the toolboxes. I wasn't really satisfied. I wanted to get closer from the regular tabs design, with separators in between the tabs. For that, I need at least to know if the toolbox tab I'm drawing is the first or the last. In both cases I must not draw a separator in between the toolbox and the "outside".

Here came the frustration. It seems totally impossible to know which toolbox tab you're working on. This is driving me nuts. There is a way to get the widget corresponding to a position. It works only once when a toolbox tab is selected, then the tabs seems to move out of the toolbox because that's what Qt tells me. I tried another way: Get the list of the children of the toolbox and retrieve which one corresponds to the rectangle I'm allowed to draw in --that's the widget I'm interested to know. Oh, it works... except that Qt tells me that the children of the
toolbox I just got don't exist. That can't be, but who cares? So it fails too.

I don't know, maybe there's something I'm too stupid to understand and I'll crawl back here on my knees to beg for forgiveness. In the mean time, I suffer the sweet pain of frustration... and I cry to everyone who wants to listen: Why, oh why? ;-)

2006-02-19

KDE: Keeping on digging

It's sunday, incredibly early in the morning. I have to wait at least 2 hours before to take my first coffee injection at a decent hour... And what am I doing? I'm blogging. That's my nephew fault. He interrupted me yesterday when I was just starting. Well, here we go again! ;-)

It appears it's possible to blog on Blogger with Konqueror. I changed some settings in Blogger's --misbehaving-- interface and here is the miracle. There's a little bug in the page display but at least I can type in the form. I can even use Konqueror dictionary. There will be no orthographical errors any more, only grammatical ones. The other improvement is the font in the form which is now a monospaced one. Definitively more legible that what Blogger or Firefox imposed me.

Back to digging. My style handles a new widget: the toolbox tabs. I don't know much apps which use toolboxes. KDevelopDesigner and Krita are the examples that come to my mind. I know that I also a toolbox with only one tab somewhere yesterday but I can't remember where. For those who don't know what a toolbox is, it a frame with tabs the ones above the others acting like drawers. When you select a tab, its content appears just below and the previously opened drawer is automatically closed.

I definitively didn't like the look of these widgets which reminded me so much of those QShadeThingies with bright and dark lines. Now the toolbox tabs look like the other tabs. I made just a few cosmetic adjustments and the result isn't that bad considering the very few freedom Qt gives us with these widgets.

Oh yeah! That's it. I stumbled on some ants of the Qt species. I was saying that Qt's anthill is a very quiet one but when Qt ants close their mandibles around something, there's no way to make them change their mind AFAIK. They're more than stubborn.

In this case, that's because too many things are hardcoded and not sent to the style to deal with. First, there is a QToolBoxTab widget (somewhere deep in Qt) but no QToolBoxTabLabel. The label is aligned on the left --even though it should be aligned on the right for a RightToLeft script. Don't even think of centering the label. The only way is through a patch to Qt... and I don't want (yet) everybody to have to re-compile Qt and KDE to install my style. ;-) That QToolBoxTab widget is also so deep in Qt's anthill that there's no (reasonable) way to let it react to mouseover. So it has the look but only half of the behaviors of a regular tab. That's all I could do and I don't see much improvement for the time being since somebody cut and pasted this widget into Qt4 --including the left alignment. I should probably say I'm satisfied I was able to change the look and remove the bold effect on the label? Well, I'm not. I'm only frustrated.

Maybe should I have my first caffeine injection right now... to stand the 203rd rerun of Alf. ;-) Let's go...

2006-02-16

KDE: First time

In a previous post, I talked about straightening up some tunnels in KDE's anthill. (Once again, an ant is an insect, not a bug. I don't mean KDE is a mountain of bugs but a complex structure like an anthill.)

So, for the first time, I patched KDE. Yes! That's possible and really easy. There's a kind of visual glitch in the taskbar applets: The tasklist labels are drawn with the button text color on the general background. You can't see the problem when the button text color is (usually) the same than the general foreground but imagine just this: A bright background and dark buttons with bright text. Here comes the glitch: the bright button text on the bright background. (This is what can happen when the buttons are set to react like toolbuttons, i.e. with a "real" button only on mouseover.)

I already looked in KDE sources and knew where to patch. I did ./configure at the base of the sources tree and make in Kicker's folder. The make failed because some other parts needed to be built first. I built the missing parts as soon as I got an error and I reached the end of Kicker's make without noticing it.

Well, I just forgot that I use the Taskbar2 applet instead of the Taskbar(1) that I patched. Apart from that, my patch works as planned. The colors used by the Taskbar(1) applet are now correct on my system. I just need to do the same thing for Taskbar2... but that won't be so easy since I feel there are some missing parts... Well, I don't really understand what's going on. There must be some invisible ants. ;-) I need to dig a little more to find the queen ant... err... to reach the bottom of this affair.

In the mean time, I'm gonna try to do the same thing with the toolbuttons: correct the colors. This problem is closer from a real bug. KDE hardcodes the colors used by the toolbutton labels and they suffer from the same problem than the taskbar: button text color on general background. I know a toolbutton has the button color as default background... but in fact it never happens! You can't use KDE without a style --some widgets are even undefined-- and (almost*) all the styles do the same thing: A toolbutton uses the general background by default and displays a real button only on mouseover. So KDE hardcoded colors are (usually*) totally wrong, especially the color that is used by the labels on mouseover. It's called toolBarHighlightColor() in the sources but it doesn't prevent it from coming right out of the blue. It doesn't even works right with the old-timer CDE style! It's just plain ugly.

*almost and usually: The really ooooooold styles like CDE, B3 and KDE classic are the only styles that work right with these KDE hardcoded colors. Well, --at least-- I'm sure for CDE that I just tested and which made me wonder why this horror is still maintained in our 21st century.

Now, I'm putting my helmet back on. I still have some deep mining to do.

Ho! And by the way, if somebody wonders why this blog is called "Kritiks", that because English isn't my L1. I though the french word critiques should be written "critics" in English while in fact it's "criticisms". I left it this way because I was too lazy to search in Blogger's poor crippled interface if there's a way to change it.

2006-02-14

KDE 3.5.1: Back to normal

That's it. I did my (second) upgrade to KDE 3.5.1. Everything is working fine except that very obvious "feature": The icons on the desktop. I think that some patch was applied. The icons aren't exactly on the same place than with KDE 3.5.0... but alas my auto-hide panels keep on pushing the icons toward the center of the screen. That's... errr... irritating but not so important.

After a week with KDE 3.5.1, I can say that I haven't seen any obvious bug. Stability is the same than with KDE 3.5.0: No problemo. I'm however a little disappointed since there isn't any visible improvement and Konqueror still doesn't allow me to blog on Blogger. That's what annoys me the most. Firefox 1.5.1 doesn't get any faster to start and its style breaks the consistency of KDE. Well, it doesn't matter much since that broken entry form of Blogger prevents me from using Firefox spellchecker. Konqueror wouldn't do much more apart from starting waaaaaay faster than Firefox.

In the mean time, I took a big decision: The last tab design is the one. I kinda made a loop on this subject. One of my very first designs had vertical separators in between the tabs. The vertical separators are back! Tabs may look indistinguishable with spaces in their label and the separators add some sort of visual aid to aim a tab. The mouseover effect isn't enough.

(Well, Blogger's image handling is pathetic. There's no way to add an image without an uglyly resized thumbnail. So...)

The new tabs are visible here and the mouseover effect is visible here and here. (The selectable mouseover color is green #00D000 and the colorscheme is "Lost Island".)

I also managed to create a nineth colorscheme for my style. Once again, I gave them --How would I say?-- suggesting names that should tell you which colors are used without telling their names. (The links will show you the KStyle dialog using the corresponding colorscheme. Each image is around 50-55 KB.)
As you can see (again), my style (really) has no problem with white text on dark background. All widgets remain visible whatever the colors. I spent a lot of time playing with "inverted" colorschemes to be sure of that.

One thing that I learned in the process is that a style should not play with .light() and .dark() but rather melt contrasting colors to obtain the same effect. For example, the background and foreground colors always contrast. When you melt them, that gives you a whole range of colors that can be more or less visible depending on the percentages used in the mix. That's what Serenity does. All used colors are always a mix of some background with a foreground so that it doesn't matter if you invert the color. The level of contrast will still remain the same. And when something needs to be highlighted, Serenity adds a percentage of the highlighted text background, and eventually uses the highlighted text color when required to keep the contrast. The most used "sub-routine" in my style is the one to blend two colors.

I don't want to give lessons to style developers but when I see the number of styles that can't cope with a dark background, maybe I should. ;-) (I'm not that serious...)

Well, to finish my post of today, a little bug that just happened. I launched Kopete from my Kicker docker-like panel. KWallet showed its dialog to ask me its password... but forgot to take the focus! So I typed my password in clear in the middle of my blog. Luckily, nothing happened when I pressed Return.

(Control Center... Search... focus...)

My focus stealing prevention level is "Normal". So... (Grumble, grumble.) ;-)

2006-02-08

KDE 3.5.1: Errare Maxilys Est

All right! The error was mine. There is nothing wrong with KDE 3.5.1. It was late or rather early in the morning, my brain was already sleeping, etc, etc.

Despite my sleepy state, I managed to downgrade back to KDE 3.5.0... just to realize that aMule still doesn't work anymore. I made some tests, playing with the styles just to realize that my style was responsible. If I wasn't so already asleep I would have actually read aMule error messages in the first place and understood the reason why.

In short, there was two nested 'if' tests and GTK-based apps never reached the nested one because of the way GTK UI works. Alas, during my "enlightened period", I pulled the nested 'if' out of its "nest" and all GTK-based apps would stumble on it. I couldn't realize since I haven't used any gnomish apps since the last modification of my style and KDE's update... so I blamed KDE.

aMule error messages were quite verbose but when I succeeded in focusing a little more, I saw some references to something-serenity-something.so and even the name of part of the style plugin that was leading to the crash. I opened Serenity source, went to the "crashing site" and realized that it contained my last modification. I commented it out and... Miracle! aMule was working again.

I made a few more tests and I found exactly which statement causes the crash and I fixed the problem. (I won't tell what silly ideas crossed my sleepy mind before I reached the very simple solution.) Now everything is back to normal.

While I was at it, I made some more changes to separate the drawing of the tab arrow buttons from the drawing of the add/remove tab buttons. The kind of freedom I gained from this separation also freed my imagination and I got some more ideas about how to draw the tab bars. --I'm not really satisfied with what I did yesterday.

Well, despite what Blogger says, it's diner time for me. I'll re-install KDE 3.5.1 after eating then I'll take some time to break my style (again). ;-)

KDE 3.5.1: Smelly fish

First, I need to withdraw a part of what I said yesterday. There is no missing packet amongst the RPMs. Kdebase3-khotkeys just doesn't exist anymore, it has been integrated into kdebase3. I'm out of the dependency hell. ;-)

So KDE 3.5.1 is installed. I don't know exactly what bugs have been fixed, apparently none that I encountered. Especially, the problem that occurs when you want to add a color to the customs colors hasn't disappeared. The problem with the icons and the auto-hide panels isn't gone either. But, on the other hand, I think I noticed a sensible increase in the boot speed. At least, that's a good thing.

The new problem in this version is that aMule doesn't work anymore. At least, it doesn't support the GTK-Qt engine anymore; it explodes when the Qt style is activated. Once the Qt style deactivated, no problem... except when I launch it from my docker-like panel. On the other hand, just because I live in the Twilight Computer Zone, the GiMP always adopts the Qt style whether it's activate or not.

I reserve my judgement until I restart my computer, just to be sure that there isn't some smelly fish left in the bottom of the barrel despite the fact that I've restarted the X-Server three times already. (To be totally honest, I must write that the idea of downgrading back to 3.5.0 crossed my mind. There weren't very obvious bugs that needed to be absolutely fixed and the ones that actually bothered me aren't fixed. So...)

2006-02-06

KDE 3.5.1: The end of the tunnel

Finally the SuSE packages for KDE 3.5.1 have arrived but that's not the end of the tunnel... yet.

On the RSS feed from KDE-developers.org, there was a warning against false dependencies that would be fixed later. I didn't encounter them. I got no strange unresolved dependencies with the packages from my trusty source (Free Ad: RPMFind rulez!) ;-) and RPM only complains about actually missing packages. So far, so good.

The only problem is that somebody totally forgot to build the kdebase3-khotkeys-3.5.1 package. It isn't even available at ftp.kde.org and --of course-- the old version 3.5.0 absolutely wants kdebase3 with the same version number. (What was this expression?... Oh, yeah... Dependency hell.)

Just for the fun of it, I tried to build KHotkeys from sources. I usually don't do such things since I prefer to always have somebody to blame for the bugs. ;-) Well, in fact, I prefer to obtain critical components of my system from trusty sources and I don't count myself amongst them. (This sentence isn't much better than the previous one.) :-D

Any way... Things went rather smoother than I thought. I just made './configure' in the kdebase directory and 'make' in the khotkeys directory. I could even do 'make install' if I wanted but I didn't. KDE and RPM are two giant gas factory and I don't feel like drilling holes in their pipes. In other words, if there were a spec file, I'd build the missing RPM in order not to have gaps in RPM dependencies but that's not the case. So, all I can do is sit and wait for the rain. Definitively not the end of the tunnel...

On the other hand, I saw the light at the end of the tunnel of my style. In my previous post, I said I was waiting for the enlightenment. It wasn't a big flash of light that sent me down to the ground, smiling in extasy but at least I saw the light. What my style does is to paint all the buttons on the tab bar with the same color than the inactive tabs and almost square. This includes the buttons to open/close a tab and the seldom seen tab arrow buttons. I went a step closer from that wonderful mockup...

(Gosh! Aaron Seigo made me loose my track with the sad news about his cat Toes. I didn't want to think about my late cat Charlie any more... Damn!) :'-(

Well, the mockup is here and what I love so much about it is the tab bar with a colored background as wide as the tab panel. Qt doesn't allow us to do such things but we can get closer.

And for the first time, a picture from my style in action... with a glimpse into the RPM dependency hell. (Well, if Blogger wants.) (...) (Third attempt.) (...) (Fourth attempt.)



(For some reason it works better if I don't ask Blogger to host the picture. Grumble, grumble.)

Do you like my tabs? Not your everyday tabs.

What you can't see is the mouseover effects everywhere. The buttons undergo a slight change of color when the mouse reach them. The one I like the most is the button that appears behind the arrow of the combobox (the URL bar). It's colored under the mouse but regular with only the text cursor (focused) and absent in any other case. What you can't see either is how the disabled widgets melt with the background.

Even white text on a black background --really-- isn't a problem. Look at this picture with some more widgets and --while I'm at it-- the style configuration dialog with another colorscheme. By the way, note the name of my style: Serenity.

Look closely at the buttons "Appliquer" (Apply) to see what I mean about "melting". Look also at the buttons "OK"; to have a different color for the default buttons is an idea I cut and pasted from this mockup I liked so much.

When I think that all I wanted to do was to remove some lines from Lisptik style. Finally, I'm maybe closer from the end of the tunnel that I think. Well, there some glitches with the GTK-Qt-engine but nothing is really unfixable --in the computer world at least.

Now, excuse me but I have to go and check KBlogger (if that the right name) because the interface of Blogger is a real P.I.T.A.