Some people fall in love and touch the sky

Some people fall in love and find QuickSand


(Coming soon. :) )

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.

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

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 https://tiberiandream.svn.sourceforge.net/svnroot/tiberiandream

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