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.