Round corners for Danimo

It doesn't look like to be possible to post a comment on Danimo's blog for some reason. Whatever... Here is my great achievement! ;-)

If somebody could confirm that it works with Infamous Explorer that would be great. I could only test my CSS skills on Konqueror, Firefox, Opera and Epiphany... and Lynx.

It works!

Update: Thanks to Pipitas, I know that my CSS works in IE 6 and beyond.

I added the caption bar. It looks better. And I looked at Danino's code so I can also say that to limit the width, this must be done on the div "ToKeepThisInOnePiece"... but all the code text must be formated to be sure that it never exceeds the width of its container. With my <pre>-formated text, it doesn't work. Only the <p>aragraphs behave correctly.

KDE: Set the Widgets free!

I just saw Erioll's blog. As a style/windec developer, I couldn't resist to the urge to answer but my comment was way too long. So here I come...

I agree with Erioll: Something should be done to fill the gap in between styles and windecs. They are two totally unrelated things and that's a problem since they both take part in the global look of your KDE. They should be one single thing one way or another. But, even if you write a theme that includes both, at the time of execution, the windec can't rely on the presence of the style --and vice-versa.

Along my daydreams, I already had thought about having a serene library shared by my style and my windec so that they don't both need to contain the same code to draw the same kind of gradients and buttons.

That was only a daydream. If the user wants to use only the style or only the windec, the principle of a shared library loses a lot of its interest. The only thing I kept from my daydreams is that life would be easier for me if the style and the windec were one.

Actually, the style and the windec never talk to eachother. They happen to share the same palette and that's all. That's something that has always puzzled me: One single window but one style plus one windec.

I had thought about writing a centralized config dialog for Serenity but that would have led me to include pretty much the whole windec underlying mechanism into the style to be able to apply changes to the windec. That's a bit silly. Besides, I have seen so many screenshots with my style and another windec that I dropped the idea. It wouldn't interest much people besides me.

If --and that's a big "if"-- KDE ever gets a centralized theme configuration as Erioll suggests, I don't think it would change much anything apart from adding another level of complexity because you can't make disappear the fact that some options apply only to the style and some only to the windec... and because some themes will just disregard everything but their own options.

I consider theming like a kind of art. So when I feel that round corners look better for my windec, I don't think that the big gun of any KDE's central configuration pointed to my head will make me draw them square. To comply doesn't belong to the artists' vocabulary. ;-)

Besides, I think that centralization has some bad side-effects. I was very interested in looking at every new theme for Beryl that Erioll cites as example. It was so... at the beginning --even if I can't use them. But now, they all look so much the same that I don't care any more. Centralization often means uniformization.

IMHO, trying to artificially bring together the windec and the style in a config dialog won't work. The only real solution would be that the style and the windec become one and stop ignoring eachother. That's the only way it would be natural to have only one config dialog. (I would even add the colorscheme handling into it in order to have just one big theme config dialog.) The inconsistency which worries so much Erioll would remain only in between themes but that's unavoidable. Either the themes are all the same with the same options or they are different... with different options.

Any way, I think that we would lose quite a few developers along the way. A style isn't as easy to write as a windec. And some users used to a very classical style with an eccentric windec --or no windec at all-- wouldn't see the point of such a gathering.

I can only foresee that the current status quo will last until an unforeseeable but necessary revolution. I have hope. Didn't the wall of Berlin fall? The wall in between Style and Windec will fall one day too and the widgetizens of the two countries will unite in a bigger country called Theme. ;-)

KDE: Password, please!

Yesterday, I saw this blog and I kinda agreed with Danimo that the asterisks you can see when you enter a password are a bit old-fashioned.

Danimo wrote that some improvement can be brought into KDE 4 but not KDE 3. Since I don't like to be told that something is impossible, I opened the QT3 docs.

Contrarily to what Danimo said, QStyle::SH_LineEdit_PasswordCharacter exists in QT3. So, I ripped his little example... et voilà!

I don't care where it comes from, it's just so much nicer than the asterisks that it will be in Serenity 1.7.

Oh boy! The hibernation is already over! I also have some panels to make visible again in Kontact and maybe something to do for Amarok. (Serenity doesn't like the way Amarok changes its colors... and I never care because I use XMMS.)

Next year seems to be earlier this year! :-D

KDE: Dot Zero

Okay, this is a very bad habit but I released another "dot zero" version of Serenity: 1.6.0

There's no bug but I got vexed by the criticism of the "Modern" treeviews. ;-) I worked on the graphics yesterday. I already had 2 possible replacements yesterday... but in fact I've released a 3rd solution.

And the expanders really look like to turn around the dot. That's nice.

Besides, for this "dot zero" version, I edited the INSTALL file to add a very important option for the 'configure' script: --disable-debug.

That's strange but I think I was able to gain even more speed. I should rename Serenity into "Rocket". :-D

Now, I can hibernate until next year...

KDE: Loose weight!

The spammers used to want a part of me to get bigger, now they all want me to get thinner. I absolutely don't need it but I'd would have liked having one of their drugs to make Serenity lighter!

My free webhost is nice although a bit slow when I upload but I totally forgot that there was a 500 KB limit for the files. It made me laugh to see how much weight Serenity has recently gained... but I couldn't upload the source archive anymore.

What could I do? To remove code wasn't an option so I removed a part of the rest: Some colorschemes that weren't directly installed and I trimmed every text files. That wasn't still enough. So I also trimmed the comments in the sources files. Ouch! I never thought that would be so painful!

Any way, at least, I didn't remove any feature from Serenity. I even added one since last post: The rubberband can now use the highlight color to become more visible. So far, there isn't much I have been to do with this boring rubberband. The result was always ugly one way or another. This little touch of color isn't the killer feature but it's nice... Well, with the colorschemes I provide that don't use a dark highlight color, otherwise the rubberband will only look thicker.

By the way, that reminds me that I included in the (now external) colorscheme archive a serene version of the "Classic KDE" that I called "Modern KDE". I just tuned it a little but it's still a lot like its "former self".

That's pretty much all I did for the style apart from increasing the separation of the vertical tabs to 2 pixels. (I have their name on the tip of the tongue but it's stuck and won't fall onto the keyboard...) That's the widgets you get with Konqueror side bar. Oh! And I fixed the QToolButton's so that they look less often like the tab arrow buttons. The QToolButton's are overused and it's a mess to guess what does what and where. Usually the styles draw a button for everything that behaves like a button. That's very simple to code but that's not Serenity's way. Things are a little more complicated to get the result we know. Whatever... It's done and it works.

Most of my work was dedicated to the window decoration. I removed the B2/BeOS frame shape. It was just a passade. I realized I just didn't use it anymore. Besides, all the calculations it required was an obstacle on my way towards the mythical city of Always-More-Speed. ;-)

Thanks to the few CPU cycles I gained, I restored the zen border on the inactive windows. I felt that the borders were blinking when the window changed of state. Now, with the zen border always using the window background color, it has always the same colors and doesn't blink.

While I'm talking about borders... I made a last minute change: Now the windows are always square when fully maximized. And if you don't disable the borders, there are drawn flat without outline. Drawing gradients all across the screen take time nowadays. But I first did this to simplify the mess I coded previously.

I wrote what's above yesterday and I got interrupted.

Since yesterday's release, I've already made a little change. Not in the code but in the graphics. Somebody criticized my "modern trees". They're not so bad --or maybe am I just used to them-- but I tried to find something else. The "critic" put in words an idea I had only in image: To always keep the dot and to add an arrow to indicate the state collapsed or expanded. IMHO, the best result would be achieved if the dot could remain in the center so the arrow shape looks like to turn around. Alas, that's not possible. There just isn't enough room around the dot to make a big enough arrow. Besides, with all the empty space on left or on top, the expanders aren't (visually) a large target any more.

That's why I ended up with the current arrows that do not match all other Serenity's ones. Any way, I already have two replacement choices. I'm going to play with them until I find the right one... or a third!

I have plenty of time until next year. A monthly release is a good schedule, it gives time to think about everything... And next month is next year. So... Happy new year, Serenity! ;-)