cat /dev/maxilys

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

2006-10-27

KDE: Intentionally left blank

In order to give more room for the window decoration preview, I totally re-built Serenity windec configuration dialog from scratch. I also gained a lot of space for the options in the process. Now, there's so much space that I had to put two warnings "Intentionally left blank" because of two large empty spaces. It looked too much as if some options refused to show up!

I don't know where it comes from but I have vague memories that this kind of warning was a subject of laughter once in the past. I'm almost sure that it's related to the "dark side of the Force". It's so easy to mock them. ;-) Whatever...

I arrived at this solution because I removed the 9th button style "Solid bar" and turned it into a switch labelled "Draw a solid background" so that all button styles now can have the "solid bar" look. I felt that the titlebar was a little... bare.

As a side effect, my favorite button style is now "Menubar" with a solid background and an extra-space in between the buttons. This option that I didn't want to add proves to be useful. Il ne faut jamais dire "Jamais". (Never say "Never".) ;-)

The last option I added was a subject of an argument with a french user. --I speak so rarely in French about Serenity that it's worth mentioning.-- (Salut, BenoĆ®t !) Poor Benoit who received a rant as answer to his request for some changes that I didn't like!

To sum up, I argued that a window decoration was more art than code and I let the artist in me rant about how two pixels could affect the entire windec. :-D I wasn't that serious but he probably took me very seriously since he didn't answer. Whatever... I comfort myself with a second post I received about the (proposed) inclusion of Serenity into a distro. ;-)

Any way, thanks to Benoit, I added the "Extra-space" switch which didn't force me to undo things that I did but made me write more clever code. And the last option that he wanted was to be able to reduce the border of the window.

This one, I fought hard against it. I just didn't want. For me, six pixels were good and my only answer to any proposal was "Why do people think that any empty space is always wasted space?". What I was really concerned about is the fact that this so-called wasted space is in fact very useful when you want to resize a window. The only question I didn't ask to myself was "How many times a day do you resize a window?". My own answer would be "Never". The windows of all the applications I regularly use have been resized once and that smart KDE remembers what I did. I just don't resize windows. Period. So, I surrendered to the reason.

I added a combobox to select the border size from "Minimal" (2 pixels) to "Double" (12 pixels). And once again, I surprized myself. I made a few changes in the handling of the options to accept a real numeric option instead of a fixed value in pixels for the border size and that was all. My code was already ready to accept a variable border size. Amazing, isn't it?

I hoped these KonqFileTip's were as easy to tame but they aren't. The color of the displayed text is hardcoded somewhere and I haven't found where yet. I know for sure because I removed absolutely all black from the colorscheme I use, I also changed the black color used by Konqueror to display the files names... and that fraking text was still black!

I tried changing the palette of the text widget, changing its foreground color --changing the background works at least--, changing the whole palette of all the QToolTip's. Nothing works! Absolutely nothing! And I'm sure I reach the good widgets since I'm able to change their background color. The rest just fails on me. I'm gonna break them... But not today.

What I did today, is to solve a little problem. I was over-enthusiastic last time when I talked about my alledged optimization of the menubar drawing. This "optimization" bit off a bit of my nose today. That's not entirely my fault, I must say. This is Opera's fault. I don't use Opera very often but today I wanted to check the look of an HTML page, especially regarding the sizes of the fonts. And there it was: the hollow space around the menubar! The reason: Opera simply ditches the menubar frame and never draws it.

A long time ago, I was talking about the 1001 ways some people use and abuse widgets. This just the 1002nd of my collection. (Grumble, grumble!)

By the way, I hate the fact that the tab closer buttons are on the tabs. Firefox 2.0 copied this idea but I definitively don't like it. I don't know what usability experts would say but I think it's better to have one single button always at the same place than several tiny moving buttons lost in the middle of the jungle of widgets. I know that Konqueror is also moving in that direction but I still say that's a bad idea. Future will tell.

In the mean time, I keep on going with Serenity. What I already did is to insert an intermediate style of the tree branches in between "solid line" and "no line at all". That's what I'll do with the panel resizers: Add an intermediate style in between the current zipper and the total invisibility. But I'm gonna have to totally re-organize the style configuration dialog too because I know that inserting another option will make it higher than its calling parent. Three columns instead of two but less tall. Any way, I'm not satisfied with the way the current dialog resizes itself, so I'm going to make everything with Qt-Designer and use 'make'.

I've already prepared my gloves and my mask. This will be major surgery for Serenity style: the grafting of a .ui file.

Right now! (Well, after my coffee break.)

Labels: , ,

2006-10-20

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:

(Solid bar in action)


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. ;-)

Labels: , ,

2006-10-07

KDE: Five digits

Serenity reached the amazing 5-digit number of downloads. (I know, I'm easily amazed.) But it also lost 2% of its rating. I'm preparing the version 1.3.0 to get those 2% back. Well, sort of. I'm not that obsessed with Serenity rating.

Sometimes, I forget that Serenity doesn't belong to me any more but to the users. That's why I removed two options that should have remained: The switches for the menubar groove and for the toolbar handles. I liked it this way but I'm not the only one to use Serenity. Any way, there are still other distinctive features left.

Well, next I'll reintroduce the switch for the toolbar handles. As somebody told me, moving the toolbars around isn't so common. I even don't think that many people ever did it. I liked the handles but I've personally never moved a single toolbar. Go figure! --No, don't try. ;-)

As for the menubar, I didn't re-introduced a stich to enable/disable it. This option now uses a combobox to select in between the solid frame I wanted to impose, two very light lines that are even more serene, and nothing at all. I also improved the drawing. During my experimentations to reach the 2-line design, I totally disabled the drawing of the menubar frame and I realized that any kind of fill was "exaggerated" while only a framing was needed. The menubar entries draw their own background and the style also has to take care of the space beyond them. So, a 2-pixel thick frame is all that's actually left to draw... And I can even still improve everything in making Qt filling the menubar for me so that all that remains would be to draw the round corners, or the two lines, or else nothing at all. I will try that.

I shouldn't do this for a "dot zero" version but I added the support for new widgets: The tooltips. I have disabled them for years but there is still one of them that's available: The "What's this" tooltip and it made my eyes bleed. And the "real" tooltips were too tight packed for my liking. I improved them with round corners and a selectable background color --within certain limits as I say in the changelog. In fact, they use the base color (the usually white color of the edit lines) which is tainted with a selectable color. This way, the tooltips also support white text. KDE's default behavior is a hardcoded light yellow background which makes white text totally illegible.

I tried the same thing with Konqueror's file tips. By the way, I had a hard time re-enabling them because the buttons tooltips must be activated first for the file tips to appear. I don't understand the connection but that's the way it is. Any way, I tried to make Konqueror's file tips look like the "real" tooltips... and I failed... partially. It works fine except that the color of the text looks like hardcoded to black somewhere I haven't found yet. I dug deep into KDE's and Qt's sources. I tried very hard to change that nasty palette, I went upto the point of inserting an HTML tag to change the color of the text... and failed. I'll keep on digging later. For the moment, I check the base color and if it's rather dark, I use white instead. I'm not fully satisfied but it works well with a "common" colorscheme: black text on bright background.

I'll keep on digging because I know another kind of tooltip that causes me problems too: KPassivePopup. It's even worst than KonqFileTips because, this time, I even didn't succeed in changing the background color of the text. I guess I didn't reach the widget I had to. --A quick look in KDE's sources told me "yes" for KPassivePopup and "I don't know" for KonqFileTips. The big problem in C++ is that it may be very hard to retrieve what does what in sources you didn't write by yourself.

Whatever, that will be for Serenity 1.4. Right now, I'm just going to optimize the drawing of the menubar for the version 1.3.0... and try to regain my --not so important-- 2%. ;-)

Labels: , ,

2006-10-01

KDE: Nightshift

Just a few lines before to go to bed. It's already tomorrow morning, well, today morning... If you see what I mean. ;-)

I still haven't that new gradient to go with the Milky Way colorscheme but I crushed another tiny bug, or rather a glitch. I was testing Pixel, the new commercial Photoshop clone for Linux (amongst others). I hated it but that's a detail. I also launched Krita to compare and that's how I found the glitch.

For some reason, the toolbar item separators hadn't the normal background. I found a new approach to retrieve what widget it was: I knew it was a PE_DockWindowSeparator in the style jargon. So I searched in Qt sources which widget calls style().drawPrimitive() to draw this primitive element. --I never thought about taking this road... Don't ask why.-- In Qt jargon, it's a QToolBarSeparator. I'm already "polishing" KToolBarSeparator and it used to work this way but, suddenly, it doesn't any more.

That's it, that's the last glitch I'll remove. Tomorrow... Today, I'll make some snapshots and I'll announce the update on KDE-Look. This time, there is something totally new: RPMs! Yeah! There was a spec file since the very beginning but I never found or take the time to build the RPMs. --Don't ask why.--

After this update, I'll be able to work on my new hobby: drawing icons. Well, I don't intend to go any further than the "actions" icons. That's already a huge work!

Surprisingly, there isn't a single gradient on the few icons I already drew. I started this way but I stopped... Restarted... and restarted to reach this stage:

Some serene icons


With a dark background


Absolutely flat, mostly monochromatic, with a thin white framing. What you can't see is that all the icons are partially transparent to melt with the background. This way, the icons are automagically slightly colored to match any colorscheme and the white frame is very discreet except on a very dark background.

I don't know how far I'll go but I'll try to draw the actions icons in 22x22 and 16x16 at least. Some icons are rather complex so I don't know how far I'll be able to apply my "monochromatic" policy but I'll see. For the moment, I like the result and I'll discreetly show them on Serenity's snapshots to see if I raise some eyebrows if not interest. ;-)

Well, good night, good morning, whatever...

Labels: , ,