Friday, November 7, 2008

Runner Services

I felt the urge to see what I could do with libkonq so I played around a bit with the Nepomuk search runner last week and came out with this:

Open with actions and service menu support work with my copy of the nepomuk search runner. :) The open with dialog correctly appears, the amarok queue track action also works (but append & play doesn't because the dbus call is wrong.)

I'm still looking for more runners to add multiple actions to so if you have any ideas, tell me :D

Thursday, October 23, 2008


My apologies to everyone, I have been busy working on my thesis of late. I knew that neglecting it for too long would backfire on me sometime and for the past month I've holed myself up at home until I finished it.

Unfortunately, aside from completely wreaking havoc on my social life, which all geeks should have, it also had the nasty side effect of robbing me of time to work on anything related to KDE.

Anyway, I found a couple of free hours and I decided to fix up the 4.1 branch of QuickSand which is now in I make no guarantees about application stability for the 4.1 version as I have been unable to test it much given my limited development time. For those of you who wanted to try it out though, feel free to do so. :)

Friday, September 26, 2008

A few clarifications

I realize that my last post didn't make things clear enough for everyone to understand so let me address some questions about QuickSand.

What exactly is QuickSand?
It is simply an alternative to the spinning squares in the default KRunner interface. At its core, it is still powered by the infrastructure of KRunner.

Where can I get it?
If you read the latest commit digest, you'll see I committed it to playground. It's in trunk/playground/base/plasma/quicksand. But before you checkout the sources, let me address a related question.

Can I run QuickSand in KDE 4.1 and lower?
No. Actually, you can't even compile it using the code in trunk. Multiple action support requires two things: 1) a patched libplasma that supports multiple actions, and 2) runners that actually use multiple actions. To fix #1, there's a patch included in the directory. The patch is against trunk/KDE/kdebase/workspace. #2 is not really an issue but runners that have multiple actions can be found in playground (mediaplayer and windows directories).

Won't you release a KDE 4.1 version?
The interface itself can be run in KDE 4.1.x. Initial development occured on my stable 4.1.1 installation. I still have a KDE 4.1 branch locally. However, multiple action support requires the use of a patch which is against trunk. If enough people clamor for a 4.1.x version I could release a QuickSand version without multiple action support. (Please do not send me e-mail asking for one, a comment here would suffice.)

Are we aping GNOME Do?
No. Similarities between GNOME Do and QuickSand are due to the fact that they are both inspired by Quicksilver. If anything, QuickSand is more related to Katapult than the relatively new GNOME Do. GNOME Do and Katapult mimicked the Bezel interface. QuickSand emulates the default interface (Primer) but I think most of you will agree it looks way better.

The primary inspiration for making KRunner multithreaded was my experience getting multithreading to work properly with Katapult. Anyone remember Katapult-Fast Track? One of the comments for Katapult-Fast Track encouraged me to work on KRunner. Well, guess what... I did. :)

Recall the feature list of improvements in Katapult-Fast Track: real transparency, multiple matches per search, multiple actions per match, and multiple threads. These have all been implemented (or at the very least are in the process of being implemented) in KRunner (and thus QuickSand). All that's really left is adaptive search. Oh yeah, would have loved to do all of this for GSoC. :)

Can't you just get rid of the popup box?
The design isn't _all_ about eyecandy. Sure only having scrolling icons may look nice, but in practice it may be difficult to work with. Take the following picture as an example.

Can anyone tell me which is the match for result.h without scrolling through all items? Thought so.

I don't want to _have_ to scroll through all the items to find one particular match. Having the popup completion box makes it easy to distinguish between items with similar icons and select the desired match immediately. The popup completion box also enables interaction with the mouse. Scrolling through the items and selecting matches when the popup box is not shown can currently only be done using the keyboard.

Don't want to see the popup box? Just press escape or click elsewhere. Never want to see it? I'll add an option to hide it in the config dialog sometime soon.

Miscellaneous stuff:

A picture of text mode which I forgot to include.

And just a minor plug, I like where the Raptor menu is going. :)

Monday, September 22, 2008


Didn't get the following to Danny on time. Anyway here it is :)

Introducing QuickSand

QuickSand is an alternative interface heavily inspired by the Primer interface of Quicksilver in Mac OS X.

QuickSand differs from the current KRunner interface in several ways. QuickSand has 3 different display modes: Icon Parade, Selected Item, and Text mode. The default display mode is "Icon Parade". Instead of displaying a line-edit, QuickSand presents the user with a match pane asking the user to type something to be searched. Upon typing, the search string is displayed on the upper left corner of the match pane. If matches are found, the number of matches is displayed on the upper right corner of the match pane. The icons are of the matches are lined up horizontally in the match pane and a popup completion box is shown to guide the user in selecting the appropriate match. The user can scroll through the available matches by pressing the up and down keys (when the popup box is shown) or the left and right keys.

Hitting enter will select the match and display only the selected item. Clicking on the arrow on the upper right corner of the match pane will toggle between Icon Parade and Selected Item modes.

If the user would rather see a line edit, pressing the period (.) key will change the display to text mode. A line edit will replace the scrolling icons in the match pane.

One of the primary reasons for writing QuickSand was to provide support for multiple actions. For example a match for an open application window can have several actions associated with it. The window can be minimized, set on all desktops, etc. QuickSand supports multiple actions in the same manner as matches for a search. If a particular match has several actions associated with it, an action pane appears below the match pane with the first action selected. Pressing tab will switch to the action pane and the user can select from the various available actions in the same manner as matches.

Hopefully, QuickSand will be provided as an option in KRunner allowing users to select between the default interface and QuickSand.

Another future development would be support for actions that require objects/targets. For example given a match for a file "sshot.jpg" and an action of "e-mail to...", a possible object would be "". Support for objects would be as simple as placing an object pane below the action pane and displaying it whenever the currently selected action requires an object.

Wednesday, September 10, 2008

Some people fall in love and touch the sky

Some people fall in love and find QuickSand

(Coming soon. :) )

Monday, August 18, 2008

Configuring the Plasma Panel

I had several papers to write last night and found myself looking for excuses not to write them. I eventually ended up reflecting on how I felt about writing documentation and to be honest, it isn't something I enjoy. In fact, the two things I hate the most about writing applications are: 1) writing documentation, and 2) writing configuration dialogs, but the second issue is out of the scope of this entry. ;) I suppose my objections to writing documentation stem from my opinion that they waste my time. I could be better off doing something more productive like writing new code (or perhaps playing sudoku :D). A program should be self-explanatory to the point that a user can understand what to do without having to read documentation. Nevertheless, I never really exerted effort in writing documentation so I decided I'd give it a try. (Please spare me the flames in case I do poorly. You have been warned.)

One area that could use improvements in documentation is configuring panels in Plasma. Sebas did a good job but he only dedicated one paragraph to it in the documentation and it didn't have any pretty pictures. Most people react to visuals more so I decided to supplement the documentation.


Configuring the Panel

Figure 1 The Default Panel

Similar to the panel layout in previous KDE versions, the default panel configuration consists of: 1) an application launcher button, 2) a device notifier button, 3) a pager, 4) the task manager, 5) the system tray, and 6) the system clock. By default, the panel takes up the entire width of your screen.

The application launcher defaults to the Kickoff menu style. If you prefer a traditional hierarchical menu, right click on the application launcher and select "Switch to Classic Menu Style". (Figure 2)

Figure 2 Switch to traditional launch menu

The panel may be configured by clicking on the plasma logo, (commonly referred to as the "cashew") at the right-most end of the panel. If the cashew is not visible, right click anywhere on the panel or desktop and select "Unlock Widgets". Alternatively, you can unlock the widgets by pressing Ctrl-L when there are no active windows.

Figure 3 Unlocking Widgets

Clicking on the plasma logo opens up the panel settings window just above the panel. (Figure 4)

Figure 4 Panel Settings Window

This window allows users to configure the position, alignment and size of the panels. The window also allows repositioning of plasmoids within the panel.

Changing Panel Alignment, Position and Size

The panel may be configured to be anchored to the left side of the screen, the center of the screen, or the right side of the screen depending on your preferences. Simply select the desired alignment by clicking on the appropriate button in the panel settings window. (Figure 5)

Figure 5 Panel Alignment Buttons

At the bottom of the panel settings window there are slider handles of three different colors. The gray slider handle dictates the offset from the current panel anchor point. For left-aligned panels, moving the gray slider will move the beginning of the panel a fixed distance to the right of the left edge of the screen. For right-aligned panels, the panel will be moved a fixed distance from the right edge of the screen. For center-aligned panels, the position of the gray slider handle will be treated as the center of the panel.

Plasma supports dynamically adjusting panels that grow based on the contents of the panels. The green slider handles specify the minimum panel width. The panel is guaranteed to be at least as wide as specified by these slider handles even as the contents of the panel decrease. On the other hand, the blue slider handles control the maximum width of the panel. The panel size will not grow beyond the points specified by the blue slider handles. Panel growth is dependent on alignment of the panel. Left-aligned panels will only grow towards the right edge of the screen. Similarly, right-aligned panels only grow towards the left edge of the screen. Center-aligned panels grow towards both edges of the screen. Figures 6 and 7 illustrate the growth of the panel after the addition of a widget.

Figure 6 Panel Size is at Minimum

Figure 7 Panel Growth after adding Widget

The panel height can also be changed by dragging the topmost portion of the panel settings window until the desired panel height is reached. Widgets will automatically resize themselves based on this new height. (Figure 8)

Figure 8 New Panel height

Adding Widgets

Additional widgets can be added to the panel to provide more functionality. New widgets can be added by clicking on the Add Widgets button in the panel settings window. Alternatively, right clicking anywhere on the panel and selecting "Add Widgets..." will also open the Add Widgets dialog box. (Figure 9)

Figure 9 Add Widgets dialog box

Widgets can be added to the panel by double-clicking on the desired widget or selecting the widget and clicking on "Add Widget". By default, the widget is placed at the right-most end of the panel. (Figure 10)
Figure 10 Position of Newly Added Widget

If a specific position is desired, a new widget can instead be positioned by dragging it to its desired location from the Add Widget dialog box.

Changing Widget Positions

In some cases, you may want to change the position of a widget. To do this, open the panel settings window and hover the mouse over the widget you wish to move. A move emblem will be placed over the center of this widget. (Figure 11)

Figure 11 Move Emblem over Widget

Select the widget by clicking on it. This will highlight the background of the widget. (Figure 12)

Figure 12 Selection of Widget to Move

Move the mouse over the desired position. Plasma will highlight the new position of the widget. (Figure 13)

Figure 13 Selection of New position

Left click on the widget to finalize its new position.

Monday, August 11, 2008

Powered by Lithium

Sometime last month I found myself looking for a KDE4 power manager. To be more specific, I was looking for a KDE4 port of KPowersave, but didn't find any. So I took it upon myself to port KPowersave to KDE4 and Solid only to conclude that it would be much easier to write a Solid based power manager from scratch. When looking for Solid documentation, I stumbled upon solidshell which I previously had no clue existed. Later that day I had written a simple power management application that could change brightness. When I had free time a few weeks ago I decided I'd upload my little app to playground, only to discover that 1) there was already a kde4powersave plasmoid and 2) there was a kded daemon based on the plasmoid. :-/

Anyway, it seems like a waste to stop working on it completely so I'll share my progress with you. First, I cloned the tooltip from guidance power manager.

Then I created something similar to the detailed dialog from KPowersave.

As well as the context menu structure of KPowersave.

But almost everything is powered by Solid and thus works similarly to solid-shell. However, I fixed the brightness controls to work on my system. KPowersave only set the brightness of the first laptop panel it received, solid-shell sets the brightness of every brightness control. On some systems such as my system that will result in conflicting brightness settings.

One thing I didn't like about previous power managers was that they polled to check system activity. The power manager is supposed to be an application that helps _conserve_ battery power but instead previous implementations may have served to further _drain_ battery power by unnecessary polling. In designing the system activity checking system for Lithium, I looked for solutions that would limit the need for polling. Lithium checks for system activity based on the smallest period that needs the system idle time.

For example, autodim is enabled and the timeout period set for autodim is 3 mins. A timer will start once Lithium is started and if after 3 minutes, the system is still active (i.e. idle time is 0), the timer will restart for another 3 minutes. This means that at worst polling will occur every 3 minutes for a system that is under continuous use. If after 3 minutes, the system has only been idle for 1.5 minutes, the timer will restart for 1.5 minutes.

To perform the opposite task of checking if the system is resuming from an idle state, previous power managers again polled the system. Lithium uses an ingenious solution adopted from the kde4powersave plasmoid which in turn borrowed it from ksnapshot. An offscreen widget grabs mouse and keyboard support and if it detects activity, it releases control and the system performs the necessary actions (restore brightness, etc.).

Working on a power manager brought to my attention that HAL doesn't necessarily correctly set the maximum speed of the processor. I also could not find a means to get the current CPU frequency from HAL. I ended up reading the information from /sys/devices/system/cpu which isn't ideal.

There are several more features I need to add such as an OSD and KMilo like functionality, better scheme support and config dialogs. I'll get to them sooner or later. It'll also be great to integrate my work with the kded daemon and the plasmoid but one reason I wrote an application that lived in the systray was to be able to use Lithium in other desktop environments.

So for my next little project, I will address another minor annoyance. I'm quite sick of people complaining about the lack of a KDE4 knetworkmanager so if no one else does so by Friday next week I'll begin work on a system tray icon port of knetworkmanager to KDE4. Or I could help out with the plasmoid... If someone's already working on it, please tell me so we don't duplicate any efforts. I've got a lot of other interesting projects that are begging for my attention. :)

Wednesday, June 11, 2008

Tiberian Dream

I suppose it's quite awkward for me to write my first post in this blog on a topic that doesn't really concern KDE. Moreover, most of you have no clue whatsoever who I am. Let me begin by introducing myself. My name is Ryan Bitanga. I am a 21 year old KDE developer and user who began by using Mandrake Linux in 2000 and am currently using Kubuntu. You may have seen my name 2 or 3 times on aseigo's blog concerning KRunner. Well, most of the work I've done is for KRunner. :)

Unfortunately I haven't been able to spend as much time as I wanted on KDE lately. More pressing matters took center stage in my life and as of the past week or two something more interesting came up.

If the words "peace through power" ring a bell for some of you, you most probably got it from Command & Conquer. There was a project that tried to implement the original game, FreeCNC. 5 years ago, I wrote a patch for FreeCNC to support bindable hotkeys compatible with the bindable hot keys used in Tiberian Sun as well as mouse-over health check ups a la TA and RA2, (and most if not all modern RTS's). Unfortunately, the developers didn't respond to my e-mails, the codebase diverged significantly, and for a while, I lost interest. Two years ago there were efforts to revive the project before the two active developers claimed that no one was volunteering to work on it. Well, I did attempt to contact them and I know several other people did as well to no avail. So sometime this month I decided to make things happen.

The screenshot above doesn't show much. But if you look a little closer you'll see an infantry death animation. Majority of the work I've put into the program has been on infantry animations. You'll find that unit movement, attack, and death animations work properly. Infantry now also dive for cover when under attack and stand up a few seconds after they are safe. The idle animations are also correctly rendered. You'll see grenadiers doing push-ups and riflemen cleaning their rifles.

But these improvements only signal the start of better things to come. If you loved the original game and you're interested in helping, start by checking out the source code from

I am in the midst of rewriting significant portions of the code but would welcome your help, support, and ideas :)