KDE: A new resident

Somebody moved in: Kassie's little sister. She's almost a twin although younger and smaller. It was a very quick move. There was nothing then I saw some light at dusk in the upper levels of the KMenu tower. She was in. Like the average photomaniac, I took a picture.

In clear, I selected some organs from Kassie the Applet and cloned them. I implanted them appropriately on a skeleton of KPanelAppMenu around which I wrapped a nice looking and also cloned skin. I injected some electricity stolen from the clouds into the dead body and all the neighbors were able to hear my devilish laughter... several times in a row. ;-)

It just took some time to make the menu update itself at the right moment. It even takes more time when you try something, build it, restart Kicker... but forget in between to install what you just built so that you don't see that you already achieved your goal. Whatever. It took no more than one hour to go from an empty shell of KPanelAppMenu and the sources of Kassie the Applet to a perfectly working Kassie the (K)Menu Extension --and that includes the tuning of the makefiles to handle the new branch in the build tree.

Kassie being Kassie, you get exactly the same menu when you click on the icon of the applet or on the entry of the menu extension (of which I must change the label by the way). The only difference is that the menu extension is totally devoid of anything related to drag and drop.

The extensive testings have already been done. I guess all I've left is to do the packaging...

KDE: A kind of success

That's it, I've finally succeeded in hiding this annoying applet handle. I tried what I was told in the comments of my previous post. It didn't work. Period. As I said, the handles of the applets on my Kicker's panels are hidden unless hovered. I can try as hard as I want to hide() them, "somebody" will sooner or later come and show() them.

Same player, shoot again!

Besides, it wasn't so easy to find that F'ing AppletHandle. It's not a brother of Kassie, it's an uncle. In other words, in the tree of widgets where Kassie is a child, the AppletHandle is at the same level than Kassie's parent. That's wasn't hard to guess once I hadn't found it in asking the list of wigdets of Kassie's parent.

Once I had found the AppletHandle, I tried handle->hide(), handle->setHidden(true), even grandParent->removeChild(handle). By the way, this last idea was wrong: Kicker exploded.

There comes the other way to hide things: To make them so small that you can't see them any more. handle->setMaximumSize(0, 0) and the same thing for the minimum size. It worked! Success!

Success? Really?

Now, how can I move Kassie around? No handle any more, no sub-menu to do it. When you install Kassie in your Kicker's panel, you just have to make the wish that it will appear right where you want. --It seldom happens this way.

So... As I already said: Wait for Plasma/KDE 4.

Case closed. Dismissed! ;-)

KDE: Yes and No

Or "The Difference in between Theory and Practice". I had great plans about Kassie just before I went to bed. In theory, it should have been possible to change it into a simple PanelButton (without K!). I went all through Kafka's Metamorphosis process from KPanelApplet to PanelButton --These AutoTools are a real nightmare!-- and I hit a wall. Hard!

Maybe should I say a big sign. It was labelled "Members only". So... I was totally right last time when I wrote about Kicker's Very Private Club that doesn't accept outsiders --anything coming from outside of its build tree-- despite the appearances.

Just for the fun, here's what I got: Kassie normally appeared in the applets to install, I selected it and clicked "Add to panel". I got the little animation with the big tip saying "Kassie is in da house". (Something like that...) ;-) Kassie's icon appeared in Kicker's panel... 1/4 of second of pure glory... And it was immediately replaced with the icon for the unknown documents. Kassie just got kicked out by the Kicker. (Lousy pun intended.) The icon reacted as if there was "somebody" behind it but that was all. Kassie even had no name any more so I uninstalled « » and forgot about the whole idea.

I had copied everything from the other Kicker's PanelButtons... Except one thing: Kassie couldn't climb back into Kicker's womb where the other PanelButtons are. That's the problem as a quick search proved to me, they aren't independant objects. In other words: "Members only!"

So, with the few choices Kicker gives us, Kassie is a KPanelApplet... again! It's going to live with its extraneous handle until KDE 4 and Plasma which --I definitely hope-- will be more open.

Lucky me, I won't have all these problems to enter the KMenu. The KPanelAppMenus are independent objects. And I already know where I'm going to search for "inspiration". (Rip! Rip! Rip!) ;-) Let's get started! Well, first, I'm going to that french bakery are the corner of the street and find something sweet to give some energy to my brain.

In between parentheses, I'm happy to be able --again!-- to use Konqueror to type in my blog, with my KDE fonts, with the right sizes. I hate Firefox which is so slow to start and has a major problem with fonts sizes.

For those interested and who haven't yet gone to bugs.kde.org, --It took me time, too!-- the solution is to set Konqueror's identification to Firefox for www2.blogger.com (and eventually www.blogger.com). Still, it's better not to use the preview. Blogger is... hmm... what it is. End of parenthesis.

KDE: Reincarnation

No news means good news. Since I got no answer (yet) from the author of Kate Session Menu, I suppose our little (informal) competition goes on. ;-) My last move was to prepare Kassie for its appearance in the KMenu.

For this purpose, I merged the two menus "Available Sessions" and "Running Session" into a single one with two sections. It's not possible to do Control + Click in the KMenu, so the applet doesn't use this feature any more. The "Available Sessions" section lists only the non-running sessions. If there are running sessions, then the second section --appropriately labelled "Running Sessions"-- will show up.

The behavior remains unchanged. You can open an available session or activate a running one. That's the sub-menu that will be attached to the KMenu.

Dropping on the KMenu is however still an issue. Maybe I will add a drop target like KGet. I think that's the best idea. The drop target will react just like the applet. A drop... Then a popup menu to select the (real) target. That will be for Kassie 0.4. I already have a major re-writting to do in Kassie 0.3, apart from writing the KMenu extension.

The applet will disappear... so that only the (not K-)PanelButton remains. I don't know why I inserted the (not K-)PanelButton into a KPanelApplet. It's stupid since a (not K-)PanelButton can appear alone in the Kicker. So... Reincarnation! This will remove the useless handle that steals space in the Kicker.

But, right now, I have something very important to take care of: Find my bed! ;-)

KDE: On my TODO list

Just before packaging Kassie for its release, I added a TODO file in its build tree, with only 2 lines: "Add the possibility to create a new session with the dropped files" and "Add the possibility to drop files on a non-running session". These were just two ideas that suddenly popped in my head. And I postponed the release...

The second idea is rather complicate. The only solution I've found is impractical, I prefer to let the idea being chewed by a background process of my mind. There may be an indirect way to obtain the desired result but some more "chewing" is required. I removed the idea from the TODO list, it's not mandatory but a path to explore for a future version... Without mentioning that I'd have to build a dialog with 4 buttons (KDE doesn't provide any in its standard dialogs) and that there'd be no reason left to treat so differently the running sessions from the non-running ones. In other words: a major re-writing!

The first idea was an easier one. All the pieces were already in Kassie. I knew how to ask for a new session name, how to start one, and how to build a list of files for Kate. All I had to do was to put the puzzle together once I had discovered that Kate was capable of creating a new named session from a list of files.

From my point of view, this is due to a bug in Kate. When you ask on its command line to open a session and add a list of files behind this option, what makes sense is that it opens the files of the session and add the new ones to it. No?

Apparently not. In this case, Kate replaces the files of the session with the ones on the command line. Not what I expected but that was what I needed to create a new named but non-empty session. Any way, now, it's done. Kassie allows you to create a session from a list of dropped files. This is a shortcut so that you don't have to explicitly save the session to give it a name.

Oh yeah! Since I added this new feature, it made sense to be able to use it even if no Kate is actually running so, now, the popup menu of the "Drop Manager" always appears when you drop files on Kassie's icon. Hey, you can't be an advanced session selector if you don't put the sessions without name at least one click away from the user. ;-)

While I was as it, I filled the little holes in which the user could fall when he types in a session name.

Tell me, what's the difference in between "This" and " This "? If you can't see it, I assure you that a program will know it. So I let Kassie remove any superfluous white space so that it doesn't accept a white space as session name --the way Kate does-- and so that you won't find yourself wondering why two sessions have the same name but one is misaligned or misplaced.

Finally, there's nothing left on my TODO list. It's time to do some packaging and "snapshooting" before I get new ideas! ;-)

KDE: K.I.S.S.

Keep It Simple Stupid! That's the fundamental principle I'm applying to Kassie. I removed all unnecessary dialogs asking "Do you want to do that?" I found only two cases where such a dialog is useful: When you enter the name of a new session to create it, if it's already running or if it already exists. Since you have to go over the entire menu --which lists all your available sessions-- that can only mean that you didn't pay attention, so to give you a chance to correct your error isn't superfluous.

The session "Blah Blah" already exists. Do you want to open it? Yes, No, Cancel.

The session "Blah Blah" is already running. Do you want to bring it to foreground? Yes, No, Cancel.

If you cancel, nothing happens. You say "No", you go back to enter a name. Something happens only if you say "Yes". The session gets opened or brought to the foreground.

Update...

Thanks to punit and mkIV, I removed the laughable "Do you want to..." (Too "windish"!) ;-) and put meaningful labels on the buttons. So the two dialogs now say:

The session "Blah Blah" already exists. [Open it] [New Name...] [Cancel]

The session "Blah Blah" is already running. [Bring to foreground] [New Name...] [Cancel]

I will probably change "Bring to foreground" (split on two lines to keep a reasonable width) into something shorter but, any way, that's already better! Thanks, guys.

...Update

That's the brand new thing in Kassie: Handling the virtual desktops and the windows. I thought it would be difficult because I had a quick look at the sources of Taskbar v2 a long time ago and I remembered that it was rather obscure. That's because a task manager does much more than Kassie needs. It turned out it's extremely easy. Since Kassie is already dealing with the running instances of Kate, it knows their PID (sort of...) and all it has to do is get their winID (window identifier) then ask KWin to activate the corresponding window. And KWin does everything: to switch eventually to the right desktop and to raise the window. It amazed me when I first saw this.

Once I had overcome this little obstacle, I could do much more. So now, Kassie puts a little icon in front of a running session in the list of the available ones and when you click on it, it doesn't stupidly open a second instance of this session but brings it to the foreground. No question, no nothing. The icon tells everything... Go! Swift switch! ;-)

Now, one thing was missing: The anonymous sessions. I couldn't add them to the list of available sessions. They would have looked out of place. I then added another menu to Kassie. When you click on the icon with a keyboard modifier (Shift, Control, Alt, Meta, you choose), the popup menu shows you the list of the running sessions (a.k.a. instances) and a click brings the one you want to the foreground... or, if you prefer, it brings you to it. Swift switch again! ;-)

When I work, I'm used to separate what I work on from what I use to do my researches (API, docs, sample code, etc) on several desktops and when I've found what I wanted... Where is my Kate? The previews in the desktop manager are useless and nothing looks more like the reduced image of a source code than another reduced image of a source code. Taskbar v2's previews are nice but won't help you to make the difference in this case.

Kassie knows. Control + click and you can choose which window you want to see... right now! Whatever the desktop or the number of windows hiding Kate, a click and you'll be able to type right away. Neat! ;-)

And I added a title to the menus to make things clearer. Sorry, no snapshot today. Kassie must have reached the version 1.9999999... The next snapshots will be on KDE-apps.

The ones used to my work should notice something: No overcrowded configuration dialog with two dozens of checkboxes and another dozen of comboboxes. Nothing! All you need to learn about Kassie is that you can use a keyboard modifier to click, the rest is obvious: simple click or drop.

K.I.S.S.! ;-)

KDE: Everything and more...

Kassie is reaching its version 0.1.99 i.e. it's that close from release. I made a significant improvement in the auto-reverse menu routine. In fact, it's so easy to do that I wonder how I couldn't "see" it earlier. But what should interest you more is what you can see.

Last time when I did my snapshots, I didn't realize that I forgot just one little thing. I shortened the entries in the popup menu for the drop destination but they then had a puzzling meaning without the popup title that forgot to add. That's one thing. The second thing will be the first one you'll see when you'll install Kassie: No ugly toolbutton any more. Well, it wasn't really ugly but strange. Kicker "prefers" simple icons. And I didn't loose any feature in the process. In particular, not the auto-close feature.

	On the left, the popup menu to open a new session in selecting its name (as saved on disc by Kate). It pops up when you click on the nice icon with the arrow as popup indicator. What you can't see is that the icon glows like all icons on a Kicker's panel. On the right (above and below), the popup "dialog" that appears when you drop files on Kassie's icon and when one or several instances of Kate are already running. Notice the popup title that I forgot last time. Note also that it isn't disabled because I patched my Kicker so that it uses standard KPopupTitle's and my KDE is patched too in order that it doesn't disable them unnecessarily. (In other words, it won't be so nice on your screen... Especially if you don't use Serenity style.) ;-)

I also added one of these automatic "About" dialogs KDE provides... but who cares? I did it because I could and despite the fact that I think it's too much for an applet.

Now, for those interested in coding auto-reverse popup menus, here's the trick:

int index = (position == bottom) ? 0 : -1;

Of course, you must change position and bottom into something applying to the situation. For example, for a kicker's applet, it will be:

int index = (position() == pBottom) ? 0 : -1;

Then you always give the index when you use KPopupMenu::insertTitle(), KPopupMenu::insertItem() or KPopupMenu::insertSeparator(). For example:

theMenu->insertItem(SmallIconSet("icon"), i18n("Entry label"),
                    this, SLOT(someSlot()), 0, -1, index);

And you build your menu from top to bottom without worrying about the direction.

That's all. No conditional code, no complex calculation, no calculation at all. No nothing. (Here, the 0 means "no accelerator key" and the -1 asks Qt to generate by itself a unique id for this item.)

The magic happens because you always insert an item at the given index. If the index is -1, Qt interprets is as "add to the end" so the menu builds itself from top to bottom. Perfectly normal. With an index of zero, each item is inserted at the topmost position and pushes the content toward the bottom. Thus the menu builds itself from bottom to top. Auto-reverse activated! That can't be any easier.

That will be all for today. Implementing the nice looking button was rather complex. Having to import files from Kicker's build tree into your own isn't what I would call easy. I left me no time to tame the virtual desktops as I wanted. I'm just back where I was yesterday... but a little differently.

KDE: Hello Kassie!

Good bye K.S.A. Welcome Kassie, the Kate Advanced Session Selector... plus "ie" to make the name sound more feminine, to match with Kate. And Kassie is also a feminine first name, so...

It was hard and fun. I crashed and froze Kicker more than once, and I enjoyed its auto-restart feature in between the hundreds of times I restarted it manually through DCOP. The crashes and freezes were due to the fact I was trying try to do something way out of my league: To hijack a drop action to Cuba... No! From where it began to a dialog that I inserted in the middle of the drop action.

It failed but I learned a lot of interesting things about KDE/Qt while browsing their docs. Definitively not a waste of time. It could have work if were already in 2008, not because of KDE 4 that will be released for a long time at this moment but because I will probably be able to do what I wanted. I say this because of this thought that haunts my mind when I see my code: I could never have done this last year. Last year, at the end of February, I was working on Serenity 0.2 to release it in March. Amazing... :-)

Well, "Kassie" was I saying. Instead of the programmatic torture I was trying to inflict to KDE, I made something very simple: I just let the drop action go to its completion (the release of the button) then I show my little menu. And what's on the menu? See for yourself!

Another auto-reverse menu! ;-) And, yes, the icons are so big intentionally. I tried with regular little icons but the big ones are better, they bring you comfort or, in other words, usability. Any way, the menu shouldn't grow very much and big icons won't be a problem, even if your have 45 available sessions --as somebody told to me-- because what it shows to you are only the running instances of Kate. (Of course, if Kate isn't running at all, no menu will appear.)

So, when you drop files on Kassie's icon, she... it proposes you to choose where you want to drop them, either into one of the running instances or in a new one. And the last entry "Cancel" is here because you never know where to click to close a menu. A clearly defined area is very convenient. And thanks to the auto-reverse menu, it's always "at the other end" of the menu, never in your way to click by error.

To sum up, here are all the ways you can open files with Kassie's popup menu:

• You open an available session and you drop files on the window.
• You create a new session with a name and you drop files onto it.
• You simply launch Kate and drop files onto its window.

And when you drop files on Kassie's icon:

• The files can be added into a running session/instance.
• The files can be used to create a new instance or session (if you don't forget to save it to give it a name).

The hidden features: Kassie always keeps accurate lists of the available sessions (You can manage them by hand without worring.) and of the running instances so that you never need to tell to Kassie to update anything. It's automagic. ;-) Kassie will warn you if you try to create a session that already exists and it proposes you to open it instead. If you try to re-open a session, you will get a little warning too. Right now that's all Kassie does but --if there are no problem-- I will add to it the possibility to propose you to bring the already opened session to the current desktop.

All this for the version 0.2! There are other ideas that crossed my mind but I dropped all of them because I didn't want to make your panel fall below your screen because of a too heavy Kassie. ;-)

And now, a little warning...

Warning...

To anyone who uses my script to open a URL in a new tab of Konqueror, I noticed a little flaw. It may look like sometimes that nothing happens anymore, whatever the number of times you click. In that case, STOP clicking! Then restore that minimized Konqueror that now shows a dozen of copies of the page you wanted to see... or worst --if it gets on your nevers. :-)

As I said, it was a little warning. Nothing serious. :-D

...Warning

Then comes the improved script:

#! /bin/bash
ALLKONQ=`dcop "konqueror*"`
for THIS in $ALLKONQ
do
    HIDDEN=`dcop $THIS konqueror-mainwindow#1 hidden`
    MINIMIZED=`dcop $THIS konqueror-mainwindow#1 minimized`
    PROFILE=`dcop $THIS konqueror-mainwindow#1 currentProfile`
    if [ "$HIDDEN"=="false" -a "$MINIMIZED"=="false" \
    -a "$PROFILE"=="webbrowsing" ]
    then
        KONQ=$THIS
    fi
done
if [ -z $KONQ ]
then
    konqueror $1 &
else
    dcop $KONQ konqueror-mainwindow#1 newTab $1
fi

I guess that shaded windows should also lead to a problem of... well... visibility but there's nothing to do this time. Konqueror doesn't provide any DCOP access to this information. Wait for KDE 4 and D-Bus. Maybe.

Hmm... I wonder what D-Bus management looks like in KDE 4. (Cough) I have to go I think I let the water running in my tub... ;-)

KDE: Late midday news

The Kate Session Applet is on its way toward completion. I added the auto-close feature and enabled the use of the keyboard modifiers during drop to launch a new instance of Kate.

The auto-close feature was really fun to implement. I knew I had to set a flag to signal a menu opening and then... what? I didn't investigate how Qt does to close a menu but there are --at least-- no public method. So, what I did is set a flag when Qt sends the signal aboutToShow() and unset it when I receive aboutToHide(). And finally, in my slot that is called after a click, I just refused to open the menu when the flag is set and unset it for the next time.

It didn't work. Period. When the second click occurs, Qt closes the menu before (re-)opening it. It's stupid but logic.

So I did something also stupid. I didn't unset the flag in the slot connected to the signal aboutToHide(). I thought that this way the menu would open only once and all I'll have to do would be to find another place to unset the flag.

It worked... sort of. The menu opened only every two clicks. It's stupid but logic too. :-)

The solution came from one of these mysterious background process that I initiated in my mind while I was typing this blog... and realizing that what I was typing meant that the menu would open only every two clicks. (I really have a twisted mind...)

To open the menu I do:

x = theMenu->exec( theButton->mapToGlobal(QPoint(x, y)) );

So...

if ((x == -1) && (theButton->hasMouse()))
{
    // It was a click on "my" button that closed the menu.
    // I will just refuse the next opening.
    // Since Qt already closed the menu, it will look like
    // that it was the click that did it... and it did!
    menuIsOpened = true;
}
else
{
   // The click occured on an entry of the menu
   // or elsewhere that lead to the closure.
   // I'm free to open on next click.
   menuIsOpened = false;
}

(And no, I'm not that verbose in my comments.)

$ make
    (blah blah blah...)
$ su
# password:
# make install ; exit
    (blah blah blah...)
$ dcop kicker kicker restart

And it just works... Right now while I'm typing.

As for the keyboard modifiers, I decided to use them when I realized that dropping files on Kate's icon in the panel used to launch a new instance and that I implemented just the opposite: Drops re-use the first instance of Kate that KDE will find. (Again this problem of the virtual desktops and the invisible openings...) Any way, I allowed you to hold whatever keyboard modifier you want (Shift, Control, Alt, Meta) when you drop files and in that case a new instance will be launched.

This behavior is even better than before because you need to use a keyboard modifier only once. If you have some after-thoughts, you just have to drop the new files directly on Kate.

I just got an idea. What if you could choose on which Kate you want to drop your files when several instances are opened? I mean, instead of letting KDE decide for you. That's easy through DCOP and Kate is nice enough to let us know what session she uses, how many files it contains. And there's probably more. I barely scratched the surface while I was looking if it was possible to have the title of the windows. It isn't but the name of the sessions will do the trick. I will investigate further. If it's not too much for a poor little applet...

Maybe.

KDE: Itch by itch

I found an itch to scratch. I wanted to be able to let Akregator open the links I click in tabs instead of scattering windows all over the desktop. That proved to be an itch very difficult to scratch. "Brain Yoga for the Dummies" didn't help. Your brain has to be more flexible than a contortionist.

The stick I used to scratch the itch is DCOP. This is the only way to open a tab in Konqueror programmatically. I could remember that it was possible but I didn't retrieve what should have been stored in my "database" on my harddisk.

So, I launched kdcop and started digging. Here is what I got:

#! /bin/bash
ALLKONQ=`dcop "konqueror*"`
for THIS in $ALLKONQ
do
    HIDDEN=`dcop $THIS konqueror-mainwindow#1 hidden`
    PROFILE=`dcop $THIS konqueror-mainwindow#1 currentProfile`
    if [ "$HIDDEN"=="false" -a "$PROFILE"=="webbrowsing" ]
    then
        KONQ=$THIS
    fi
done
if [ -z $KONQ ]
then
    konqueror $1 &
else
    dcop $KONQ konqueror-mainwindow#1 newTab $1
fi

What this little script does is to ask through DCOP the list of all actually running Konquerors. It picks the first one that uses the webbrowser profile and isn't hidden some way. Then it asks this Konqueror to open a new tab with the URL from the command line or, eventually, it launches a new Konqueror if it hasn't found any suitable one.

This way, the script doesn't re-use a Konqueror with which you opened views to directories. The size of my Konqueror window when I browse through files isn't suitable to view HTML pages and I didn't want the script to force me to resize windows. Besides, when I'm done and close --instinctively-- the window, I won't loose all the tabs --intentionally-- opened onto directories.

Well, I put this script under the name newTab in my path and I asked Akregator to use the command newTab %u when I middle-click a link.

Now, in Akregator, I gather all the articles I may find interesting in a row of tabs for me to review later. And since the script doesn't ask Konqueror to raise its window, the tabs are opened in the background, i.e. Akregator remains on top until I feel I'm done with it.

The only problem is... the virtual desktops. They are very handy but, so far, I haven't found the DCOP way to distinguish what's on the current desktop from what's on the other ones --if it exists-- so the tabs may be opened in an invisible Konqueror, depending on in which way DCOP sorts all the available ones.

This is a KDE problem. Of course, the KApplications don't need to know on which desktop they are but IMHO there should still be an easy way to know where they are. Ask to the developer of Taskbar v2...

Any way, it's still a handy script. I haven't tested it yet but it should be possible to use this script as "default browser" so that all KApplications use tabs instead of launching multiple instances of Konqueror. Well, if there wasn't this problem of invisible openings.

After that, I found another itch to scratch: This --excellent-- Kate Sessions Menu applet. It's no longer on my Kicker but I loved it. When I didn't use Kate as a simple viewer, I always used K.S.M. I can't even remember how I worked without Kate's sessions.

What I didn't like was that I had to keep another Kate icon in my Kicker just to be able to drop files on it. And I lost too many drops because I dropped on K.S.M. I asked the author if he intended to implement the possibility of dropping. It's been such a long time that I don't remember what he answered.

I tried to implement the feature into K.S.M. and I understood why the author hasn't done anything yet. It's simply impossible.

Kicker's world is a kind of very private club. You can enter in its garden, talk a walk, sit on a bench and pretend you belong but, sooner or later, you will encounter a sign saying "Members only". In other words, Kicker isn't opened enough. If your applet doesn't belong to Kicker's build tree, you have a very limited access to its lib. You can choose either a container to do what you want in it or an icon with a menu.

If you go the icon way, like K.S.M. does, you're a KPanelMenu and, as the name says, you're a menu. The icon is, well, elsewhere, out of your reach to enable drops on it.

So, I went the other way: the KPanelApplet. That's not much better. Kicker provides some facilities so that your applet shows the same menu than the other applets when you click on the --ridiculously-- small menu button but that's all. You have a container but you're on your own.

I will spare you how I got the --stupid-- idea of using the KPanelApplet from developer.kde.org tutorials section and what I had to do to build it on KDE 3 while it is still designed for KDE 2.

By the way... Come on! KDE 4 is on its way, how is that possible to find anything related to KDE 2 on the big KDE central website. Ever heard of spring cleansing?

Whatever. After a night spent in coding and learning new tricks, I have rebuilt K.S.M. under the name "Kate Sessions Applet". For the developers who understand this kind of things, this is QToolButton and QPopupMenu that I open manually when the button is clicked. I didn't use the intergated popup menu because the menu arrow always points to the bottom whereever K.S.A. is and the menu always tries to open itself under the applet while there are well-established positions for an applet to open it.

Talking about menus. I made something that I always wanted to see in KDE: an auto-reverse menu. If K.S.A. is in the bottom panel, the Kate sessions are ordered from bottom to top and the other entries are on top of the menu. I've always found stupid that the least used entries are the first ones your mouse encounters when a menu opens itself above something.

That's why I put the KMenu on a panel on top of the screen so that its menu looks "normal". With the KMenu in a bottom panel, the first entry your mouse hovers is "Shutdown". I don't think that's the most logical way it should be.

Interlude...

I had to go away to take care of my 5 year-old niece, Alice. We played with Dora the Explorer on the family computer. It's funny to hear her trying to speak English.

She's quite amazing with a computer. She already knows how to switch it on, select her account (on Windows) and double-click to launch a game. I taught her everything because, when she comes to my house, I let her play with SuperTux, TuxPaint, Mr Tuberling or even LBreakout in kids mode.

We also played with Legos then I re-learned how to plait Scoubidous. (According to Google, it's also the english name, instead of "Scooby-Doo" as I supposed it was.)

During these few hours, she says something that stunned me: She's eager to have her own baby and she already knows that she wants a baby girl. She complained that it takes too much time even if she summed up the whole process as going to the hospital, taking a meal and putting the baby in bed. I think she mixes things up --a lot!

Whatever. I love to hear her talking about the fantasy world she lives in. I better do because she never stop talking... :-)

...Interlude

Back into my own fantasy world. I was saying "auto-reverse menu". Here is what I'm talking about:

As you can see, K.S.A. is already working, including the drop feature. I will think about adding a menu arrow if it doesn't pose other problems. What I really need to do is adding the possibility to close the menu with a second click on the icon. And the extra feature I want to add is the possibility to launch Kate with a middle-click. A left-click opens the menu, a right-click opens Kicker's menu. Only the middle-click does nothing yet. And I also have to tune the build tree because K.S.A. still uses the name "helloworldapplet". :-D

Well, I hope Blogger won't flood the Planet with all my old blogs. It forced me to change to the new version... against my will. I didn't want to gave my email address to Google but, apparently, I had no choice. Now, let's hope I won't receive more spam that I already do. Wait and see...

KDE: Octember, the 3rd

A lot of people --including me-- don't care about any thing if there isn't a least a snapshot. So, here are my snapshots of the Desktop Text Configuration module, version 0.3.

Note that I simplified a lot of things. Especially, no more decimal values and much less tickmarks. That's question of a usability. Over-precise decimal values are useless when you can't see the difference with a naked eye. And when you provide a slider to enter a vague value (less/more or min/max), there's no need to have a hundred of tickmarks. I applied my "rule of the quarters": Zero, 1/4, 1/2, 3/4, maximum. The rest are details.

Now, let's go with the images! First, the improved dialog.

Click for the full size: (710x405) 50,4 KB

Next, the presets in action. I did nothing but select an (oversized) font and the colors. The presets did the rest.

And if you wonder what "Octember" is, that's the name of a font I found on my harddisk while browsing for fonts to do my snapshots. I used respectively "Sandoval", "Almonte Woodgrain", "BoyzRGross" and "OctemberScript" which is now on my desktop with a customized fuzzy halo.

Don't ask where I found the fonts, I don't know. All I remember is that I googled for free fonts and that the site was white and red. That doesn't help much...

Now, run to KDE-Apps, I haven't packaged the new version of the module yet but it should appear very soon.

KDE: Horror movie

After some deep thinking, I removed some more organic guts from my Desktop Text Configuration module. Totally useless, like those spare parts you always have after you build a computer from scratch.

And I added one little thing: Presets. Very simple: Solid shadow, Fuzzy shadow, Solid halo, Fuzzy halo. That's all. When you choose one of the presets, the module set all necessary values for you: offset, size, decay and opacity. You can change the settings before to apply or not. It's up to you. I find it very nice.

Well, that will be all for today. I'm leaving in 10 minutes. No snapshot. Maybe tonight.

KDE: One step into the light

Monday morning... already. I'm done. My desktop text configuration module is working.

Update: The Desktop Text Configuration module is already available from KDE-Apps.

As you can see herebelow, it has few left in common with what the old module was. (I oversized the desktop font for a better snapshot.)

Click for full size: (720x413) 53,2 KB

I don't want to criticize the code of the previous author but let's say in my flourish way that I ripped off some organic guts and replace them with straight copper pipes. ;-) Especially, the old module sometimes cut a part of the shadow. Mine copes with any size of text, even if it is wider than the preview area. That's useless because the text has to be really huge but, at least, I'm sure to have a valid preview for the "normal" cases.

Now, the last thing to do before the release is to rename pretty much everything --the files and the classes-- to make this module really mine... or, rather, because "textshadowedit" isn't an appropriate name any more.

KDE: Beyond the shadows

For some reason, I put my nose into the sources of that old "Desktop Textshadows" module and I sneezed because of the dust. Two years old already and not a single update so, as vacations away from Serenity, I decided to do some spring cleansing.

First, I broke apart the dialog that was strangely designed with a lot of useless spacers. Then I made the module actually use the colors of the desktop configuration for its preview. That was the really tricky part because I had to find a way to set a color for the preview background that doesn't make disappear either the text or the shadow.

At this very moment, I wrote a mail to the author to ask for the permission to publish my patched version of his module on KDE-Apps, or else to offer him my work. And I got frustrated because I didn't get an immediate answer.

I may look calm but, inside, I'm a volcano or maybe a super-nova. Instead of wasting my burst of energy against the author who has probably something more important to do, I attacked this poor defenseless module again and again.

I added the possibility to choose the colors of the text and the shadow and I greatly simplify my method to choose the preview background and I went to bed.

Today, I'm wondering why I wouldn't make the next step: To gather all the options relating to the desktop texts. Right now, things are scattered in every corners of the control center. You choose the font at one place. The options to change the colors are well hidden at some place where you can activate the shadow but not configure it. That's why this "Desktop Textshadows" was written. Another place to go. And if you want to activate the hidden feature --Tooltips over the desktop icons-- all you can do is launch a text editor.

So I will extend the module to become the missing page of the desktop configuration: "Desktop text configuration" or something like that.

Whatever the author of the module might say, it's mine now! ;-)

I thought that managing the font would be difficult but it isn't. KDE provides the KFontRequester. Qt provides QFont and that's all I need to change the font of the desktop... for the most part. I already took care of the hardest part: Setting the colors. The other options are too easy to handle to be worth a mention. So...

I'm going to bed because it's already sunday but the result of my boredom should appear soon on KDE-Apps.

KDE: Codename "Destiny"

Serenity must be cursed --- or maybe it's me --- because it looks like I can't make any major release without having to make another one a few days later because of a big bug that escapes my vigilance.

And this time, it wasn't even fun to debug. Nothing exploded under my nose. Somebody (Hello Luis!) reported that Serenity crashes KDM at login time. So I tried.

I got not much to see. A black screen and only the activity light of the screen blinking from green to orange. All I could do was a reset, restart in runlevel 3 and edit kdmrc to use another style, to finally be able to switch back to runlevel 5, login and try to find what I did wrong.

So far, I haven't found any log reporting the reason of the crash. Of course, I found what caused the problem but I had to adopt the painfully slow trial-and-error approach. I had to guess what could crash KDM, remove it from Serenity's sources one way or another, make install and test.

Unfortunately I was able to look at KDM sources to see what widgets it uses. That gave me the wrong idea the KDM didn't like the way Serenity intercepts all QFrame drawings. I went two times through the build-test-crash-reboot process to realize that the SereneFrames pose no problem to KDM.

So here I found myself at the very beginning of serenity.cpp, checking every line. I saw nothing until I got around the 1100th line.

There! Something really strange.

I put a temporary patch, build, log out... and back in! The login dialog was using Serenity style. Victory!

I changed my patch into definitive code and made some extensive --totally useless-- tests to check that I didn't provoke any undesired side-effects. There were --of course-- none so I could leave Serenity alone until today.

Today, I took care of some cosmetic things. I didn't like the default settings Serenity used. I changed two of them: now, by default, the global style is Zen and the textbox focus highlight is activated. I did this because although KDM is launched by root, the style doesn't use his settings during login.

I will investigate on this matter because I don't like the idea of imposing my preferences to everybody. And I also need to find where root stores his serenityrc because it's not in $HOME/.qt/ as expected.

Oh yeah, why was I mocking myself and my code? That's because when I looked in Serenity's sources around which line the bug was, I just realized that all I did was for nothing! Apparently I was distracted or interrupted while I was implementing my "super-killing optimization" because it does nothing or close to nothing. It just wastes 8 bytes (I think) for two QColors that aren't used... anywhere! I'm like this squirrel that stores nuts for the winter and forgets where it put them once it turns its back.

(I feel so ashamed that I'm going to hide for a while...) ;-)

KDE: Boolean release

To release or not release... ;-) Well, that's not the question any more. Serenity 1.7 is out in the wild. Go and get it! (Somebody complained that it was hard to retrieve anything when you are here on the blog. So...)

Believe or not but what I find the hardest in a release is making the snapshots. One can put only three snapshots on a KDE-Look page while there are so many features I'd like to show. Besides, I prefer to show Serenity in action in the "real world" than making patchworks like I did in my previous post... Especially when making "patchworks" takes so much time... for a maniac like me that can't stand to see things misaligned even by a single pixel. (I feel it's so careless.)

Whatever. I also had many things to keep in mind, like the fact that my previous free webhost doesn't allow you to store files bigger than 500 KB. I've found another one without size limitation but I had so many problems of unresponsiveness during my FTP session that I abandoned it for a third one. That's the first one I found when I decided to change of webhost but my account was cancelled because I didn't use it immediately or soon enough. Its only problem is that the server isn't properly configured to deliver RPM. The packages are sent as text files. Well, we ain't living in a perfect world apparently. ;-)

Back to my snapshots. I had in mind the idea to show symbol-less buttons. (The third snapshot.)

News flash: RPM packages of Serenity for all the versions of SUSE from 9.3 to 10.2 are now available on OpenSUSE.org. (Thanks Donnie.) Close the parentheses. Amazing world... :-D

"Symbol-less buttons" was I saying. Here came the troubles. I could apply the change so it worked but for some reason the configuration dialog couldn't remember this setting. I was already starting to feel tired... My archives were already stored on my distant website with an HTML page stating their sizes. A bug at this moment meant: Re-build everything. Grumble, grumble. (That's all I write because I'm polite.)

That was it. A long lasting hidden bug. During the update from 1.5 to 1.6 I changed the symbol visibility option from boolean to integer, i.e. from a yes/no checkbox to a combobox with multiple choices... except in one place: when the dialog reads the configuration. That explained everything... and the title of my post.

A stroke of virtual hammer and I was done.

$ make
$ su
# make install ; exit

ALT+F2: kwin --replace

If you want to have "fun", type "kwin --replace" in a Konsole. By the way, the shortcut to restart the X-Server is CTRL+ALT+BACKSPACE. ;-)

I went through that painful archives building process... and I got my reward this morning: Serenity on OpenSUSE.org. Next step is to be on SUSE 10.3 CD's. :-D

KDE: Special delivery!

Special delivery of gingerbread for the eyes! For once, I'll keep my hands away from the keyboard and let the pictures speak for me. According to the time it took me to make them, they're worth a million words! Any way, if you have questions, you know where to find me. ;-)

Tabs and focus highlight
(Colorscheme: Mare Serenitatis)

Click for full size: (682x492) 37,8 KB

Click for full size: (682x492) 36,6 KB

A glance at the windec configuration dialog
(Colorscheme: Caloris Planitia)

Click for full size: (624x279) 38,0 KB

The 16 possible titlebars
(Colorscheme: Neptune)

Click for full size: (1156x493) 55,0 KB

My favorite setup
Solid top and flat buttons in various colors

Click for full size: (698x448) 50,5 KB

Need I to say this is the future Serenity 1.7? ;-)

No gingerbread...

Finally, I'm back to where... I was yesterday... again! During the night, Serenity window decoration hit an invisible barrier at high speed and --of course-- disintegrated itself.

As usual, I was driving my coding vehicle way beyond the speed limit on a highway toward the wonderful city of New-Release. Probably because of the lack of lights on the french highways, I saw nothing. All of sudden, I found myself sliding on my rear end with nothing left but the wheel in my hands. My brand new Windec 1.7 was far away behind me under the form of a pile of spare parts.

My insurance company agreed to bring me back home with my ton of spare parts. Then, all I had to do was to start again from my old Windec 1.6. No problem. But this time, I drove more carefully and brought my wannabe-new Windec to the garage after each part I added to check everything.

Now, I'm back to this moment where I'm about to change this big part of the body. The very moment that led me to the catastrophic disintegration. Wish me luck! ;-)

And the gingerbread?

Yesterday, I bought the best gingerbread I've ever eaten. So, for the unfortunate ones that can't find a french bakery at every corner of the streets, I wanted to give some gingerbread to their eyes: snapshots!

I partially re-designed the configuration dialog to give you a better control over the colors of the windec buttons. As I already previously wrote, it was a total mess with a lot of (hidden) inter-dependencies that clouded your choice. I was trying to be too smart and to always obtain an "optimal" result whatever choices you could make. Now, it's your responsability if you choose wrong colors that render the buttons invisible. There are rare cases where it's possible but that's not important since that's a result you can also obtain when you select "Toolbuttons" as button type. And an old friend from the early days is back: the standard highlight color. You can use it for the hovered or pressed buttons.

Well, there are so many things I could say but it would be better to show them, one way or another.

Any way, yesterday, I was also decided to show the new body of my Windec 1.7 --some visible changes around the titlebar-- but I had to made that body change first. And here came the unlightened highway during my test drive... and the mysterious silent crash.

No gingerbread, today. ;-)

Divide and konquer!

No, my last post isn't over a month old. The problem is that the last time I blogged, Blogger was "off duty". It crashed just when I published so my post got lost. I have what I wrote --because I trust so much Blogger that I copy every post in the clipboard before publishing-- but these are old news. So, let's start again.

Back to business! The monthly release of Serenity is on its way. I touched something that has annoyed me for a long time: the scrollbars don't sink under the pressure any more. I had found this behavior ugly but I never did anything because I was so used to see the scrollbars react like buttons. Somebody asked me if it was possible. I looked, patched and kept the answer for me. ;-) Whatever, that's better now since I've already done my best for these scrollbars not to look like buttons.

Another itch I had to scratch was the way the colors of the gradients were calculated. There were several problems: You can't have a color brighter that white, black can't be brightened nor darkened.

For a color brighter than white, I took as solution the one used by the washing powder makers: to add a little touch of blue. That wasn't perfect but it worked good enough to have a "milk look", i.e. white buttons on a white background. That wasn't perfect because the little touch of blue didn't fit with every colorscheme. A better solution was to add a touch of the global tint. I found a way to calculate it when it's not defined by the user. That's still not perfect but I'm getter closer.

I found why the black can't be brightened in the sources of QT. The code just doesn't work with RGB values equal to zero. It does it's calculations but it will always return the same black: #000000. Totally useless. So I wrote my little routine that recognizes all the greys (from black to white) and returns better results, including the brighter white with a touch of color. Wait... and see. ;-) I wrote my little routine because darker than black is the same problem that brighter than white but the other way around.

Since I found a little stupid to handle only the special cases, I ripped QColor::light() and QColor::dark(), simplified them and put the result directly into Serenity. I gained some more few ms on each gradient so Serenity is faster... again! Well, that's not as obvious as with some of the accelerations I previously did but I'm sure the CPU notices. ;-)

While I was dealing with the colors, I changed those of the gradients of the tabs and of the menubar. I made them more obvious in a very discreet way. (That's an oxymoron...) ;-) And, in both cases, Serenity now offers more choices to make them look brighter, darker or both and vice versa.

I also simplify all the tabs: No more button-alike shape on mouseover, the tabs only change of color and if they're concave, they become convex to look more like something to be clicked. And I did the same for the menubar but I kept the button-alike shape for the cases where the menubar groove is flat --i.e. either solid or empty.

The penultimate thing I did was to use an underlying unused mechanism in Serenity: the possibility to redraw textboxes when they acquire the focus. I thought it was useless and that the blinking cursor was enough but, in fact, I like the subtle way the textboxes can be highlighted. In this respect, Serenity was well designed. I acknowledged the focus in changing the color of the frame when needed and it immediately worked everywhere: the textboxes, the edit lines, the spin widgets and the editable comboboxes all at once. Neat! ;-)

The last thing was to enable you to set the popup sub-menu delay up to 1 second instead of 1/2 second. You will probably need some time to get accustomed --I did.-- because 1 second is a really long delay. The sub-menus look like not to be reacting and you need to learn a new behavior: to click to make them appear... instead of letting them pop up your nose. ;-) Now, what would be nice is that the sub-menus close themselves with a second click so that you have a total control. Unfortunately, KDE only closes the sub-menu to re-open it immediately. Maybe should I ask to the Trolls if they can do something for me? The future will tell.

That should be enough to justify a new release but I have to take care of something else first: The mess I made in the color selection of the buttons of the window decoration. That's more than a problem of label. That's a real usability issue. The various options produce, well, various results but in an unpredictable way. I was trying to change these buttons I see everyday and I ended up with the same buttons. I got lost in this jungle of too subtle options.

When I designed this mess, I was obviously working le nez dans le guidon as we say in French ("the nose on the handlebars"), in other words: too focused on what I was doing without thinking of where I was going.

What I needed to do was to clearly indicate, on one side, what base color is used to draw the buttons and the symbols and, on the other side, what color will be mixed with them, if any. That makes more sense this way... even if what I say doesn't make much sense. You'll understand when you'll see. I already re-designed the UI and it was a hard job. I failed at squeezing all the options I wanted into the "Colors" tab page and keeping a reasonable size for the whole dialog. So I kept the things the way they are, with the buttons and symbols color selection on the "Buttons" tab page.

That's what the title means: Divide the options in manageable (meaningful) units to conquer, tame, master, whatever them.

Well, now, it's time to turn my ideas into code.

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