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