Plasma on Roberto Selbach

Plasma Is Not Just a Panel

Sat, 23 Aug 2008 16:40:00 +0000

I wanted a tiny display for a script: one number, updated every few seconds, sitting in the panel. My first thought was to write another panel applet, which is exactly the sort of thought one has after years of assuming the panel is a special little kingdom.

Plasma makes that model obsolete. The desktop and panels are containments, and the things placed in them are applets. An applet does not have to know whether it lives beside the clock or floats on the desktop. The containment supplies geometry and constraints; the applet supplies its representation and behavior.

That distinction explained several things I had mistaken for needless abstraction. An applet receives constraint changes when its size or location changes. A wide desktop representation can become a compact panel representation without maintaining two unrelated implementations. It can also publish actions to the shell instead of building its own private collection of buttons.

Data comes through another layer. A Plasma data engine gathers and names information, while applets subscribe to sources. This keeps the code that reads a device, queries a service or runs a command away from the code that paints it. Several applets can consume one engine, and the engine controls update intervals rather than allowing every widget to wake the machine whenever inspiration strikes.

For my number display, this meant writing less code than expected. The engine owned the script result and timer. The applet listened for updates and painted the value. Moving it from desktop to panel changed layout constraints, not the source of the data. I had originally put the timer in the applet, because apparently I enjoy rediscovering coupling by hand.

The package structure is useful too. Metadata describes the applet, resources travel with it, and the shell can discover it without a hard-coded list. Scripted applets lower the cost of small experiments, while C++ remains available when the job needs libraries or tighter control.

There is a price. Debugging a small widget now involves understanding the applet, its containment and perhaps a data engine. Plasma’s vocabulary can sound grandiose when all I want is a number beside the clock. For one fixed panel, the old model was simpler.

I still prefer Plasma’s separation for anything that may grow or be reused. It treats the desktop as a collection of cooperating components rather than a panel plus decorative exceptions. The implementation is young and occasionally reminds me of that fact, but the mechanism is much more interesting than the collection of wobbly widgets suggests.

Plasma Needs Boring Jobs

Sat, 08 Mar 2008 17:20:00 +0000

I tried to make a very ordinary Plasma panel today: application launcher on the left, task list in the middle, clock and tray on the right, two rows high. The exciting new desktop framework objected chiefly to the phrase “two rows high.”

My naive attempt was to unlock widgets and drag everything until the intended geometry emerged. Instead, spacers collapsed, the task list consumed surprising amounts of space, and a widget escaped onto the desktop. Locking widgets prevented accidents but also concealed the controls I needed. The panel toolbox and I are no longer exchanging holiday cards.

The underlying Plasma idea remains compelling. Applets are not written solely for one fixed panel. A containment provides an environment, and a widget can adapt its presentation to a desktop or panel form factor. Data engines separate obtaining information from drawing it, which should stop every clock, weather display and device monitor from inventing its own polling machinery.

The current limitation is that abstraction has advanced farther than ordinary control. Layout negotiation needs better constraints and better feedback. A widget may technically adapt to a narrow panel while becoming practically useless. Removing a panel or moving an applet should be easy to undo. Multi-screen behavior also needs to preserve placement reliably; a temporary display change should not redecorate the entire desktop by surprise.

I had better results after creating a fresh panel, adding the expanding task list first, and placing fixed-size widgets around it. That is a workaround, not a discoverable interaction. The framework knows which item expands, but the user receives little explanation of why dragging another item does nothing.

Plasma’s spectacular jobs, such as transformed widgets and alternative containments, demonstrate the architecture. Its success will depend on boring jobs: stable panel sizing, predictable alignment, keyboard access, recovery from mistakes and sensible behavior when a screen disappears.

My practical conclusion is to keep the panel simple and lock it once arranged. I am optimistic about Plasma, but novelty does not excuse friction in actions performed every day. A desktop earns trust by remembering where the clock was. Rotating the clock is strictly optional.

KDE 4.0 on My Desk

Fri, 11 Jan 2008 21:30:00 +0000

KDE 4.0 is out, so I installed the release packages and tried to conduct an ordinary day with them. I read mail, edited code, moved files and used a browser. By mid-afternoon I had also restarted Plasma and learned several new ways not to configure a panel.

My naive expectation was that the version number marked a direct successor to my mature KDE 3 desktop. I copied over habits even when settings could not be copied: right-click here, drag this there, expect every old control in approximately the old location. That turns 4.0 into a scavenger hunt it cannot win.

The candid result is mixed. Dolphin is quick and pleasantly focused for local file work. Okular opens the documents I need and gives them a consistent interface. KWin without ambitious effects is stable on this machine. Oxygen makes the applications look related, though a few small icons still require concentration.

Memory use is not alarmingly different in this limited test, although comparing young and mature sessions by one number would prove very little.

Plasma is the weak centre. Basic panel and desktop behavior works, but arranging widgets is awkward, configuration is thin, and occasional crashes make the entire workspace feel less reliable than the applications deserve. Some conveniences from KDE 3 simply are not present. Hardware integration and notifications also have visible seams.

This happens because 4.0 is not only a set of ported programs. Qt 4, new libraries, a new desktop shell, new hardware plumbing and revised applications all meet at once. The architecture creates room for future improvement, but users interact with current code, not future room.

I can use KDE 4.0 for testing and for a limited second session. I cannot recommend replacing a carefully tuned KDE 3 work environment yet. That is not a condemnation of the project; it is a description of my desk today.

The practical conclusion is to install with a clean user, keep important work elsewhere, and report narrow failures. KDE 4.0 shows enough of the intended system to be exciting, but the release number should not be mistaken for accumulated polish. Zero is a wonderfully round number. It is not a maturity metric.

KDE 4 Beta Is a Construction Site

Thu, 11 Oct 2007 23:10:00 +0000

I tried to use the KDE 4 beta for a complete workday. This was not an especially fair test, but fairness rarely survives curiosity. By lunch I had restarted Plasma twice and learned that my preferred panel arrangement could not yet be reproduced.

I began by importing settings from my normal KDE 3 account. The desktop behaved strangely: duplicated services appeared in menus, an application opened with the wrong font, and one configuration tool crashed. A clean user account fixed all three. Carrying years of configuration into a beta is not migration testing; it is inviting every old assumption to the same small party.

With clean settings, the underlying session is more stable than the desktop shell suggests. Applications launch, KWin manages windows reliably without effects, and Dolphin handles ordinary file work. Plasma remains the obvious construction site. Widgets can be added but are awkward to position precisely. Panel sizing is limited, and occasionally a widget stops responding until the shell is restarted.

That distinction matters because Plasma replaces several previously separate pieces: desktop icons, panels, applets and their containment. A failure in that young shell makes the whole environment appear dead even when applications and window management continue normally. It is a large architectural bet concentrated in the most visible square centimetres of the screen.

Restarting only Plasma from a terminal usually restored the workspace, which is useful for testing even if it is not a reasonable daily ritual.

I also encountered unfinished integration. Notifications differ between applications, removable devices do not always produce a useful action, and some settings change only after restarting a component. These are not dramatic crashes, but they interrupt the sense that one system is in charge.

After the experiment I returned to KDE 3 for work and kept the beta under a separate account for testing. KDE 4 is close enough that ordinary use finds valuable bugs, but not close enough that an ordinary user should be expected to diagnose them. My conclusion is candid: the beta contains a promising desktop framework and several usable applications, but it is not yet a dependable desktop. Calling it ready would be marketing; calling it hopeless would require ignoring everything beneath the panel.

The Desktop Is Still a Workbench

Fri, 23 Mar 2007 18:58:00 +0000

I ran today’s KDE 4 session long enough to open a ported application, play a sound through Phonon, and watch a Plasma applet redraw. Then the panel vanished after a configuration change.

That sequence is a useful status report. The architecture is becoming tangible, but this is still a workbench, not a finished desktop. Ported applications exercise Qt 4 and the new libraries. Plasma prototypes test containment and data ideas. Solid and Phonon test boundaries around hardware and multimedia. Integration exposes where those boundaries disagree.

My current smoke test is intentionally small:

cmake ..
make
ctest
startkde

The last command belongs on a test account and display. Configuration formats and services are moving, and preserving my everyday session is more valuable than proving bravery.

I prefer testing one complete path, such as device arrival through Solid to an applet update, over collecting screenshots of disconnected pieces. The caveat is that integration failures can obscure which component broke, so each layer still needs its own focused test.

Today’s vanished panel turned out to be a containment lifecycle mistake, not a rendering failure. That distinction is the work now: finding ownership, sequencing, and API problems while change is still affordable.

It is exciting work. It is also unfinished work. Both statements fit comfortably in the same build, though not always in the same process.

Plasma Data Before Decoration

Fri, 13 Oct 2006 22:18:00 +0000

I changed the weather prototype’s frame today and accidentally made it fetch the forecast again. The border and the network request had become neighbours in one class, then naturally began borrowing each other’s tools.

The experiment now separates a data source from the visualisation. The source produces named values and announces updates. The applet chooses how to present them. Fake data is enough to exercise the boundary:

QVariantMap WeatherSource::snapshot() const
{
 QVariantMap data;
 data.insert("condition", "cloudy");
 data.insert("temperature", 12);
 data.insert("location", "Porto Alegre");
 return data;
}

The applet receives a complete snapshot instead of reading half-updated fields one by one. This matters if the source later performs work asynchronously: a temperature from the new report paired with yesterday’s condition is internally consistent only in avant-garde meteorology.

The visual item invalidates its content when data changes. Theme or frame changes invalidate geometry and decoration, but do not restart the source. Keeping those paths separate avoids needless work and gives the containment freedom to alter presentation.

For this little applet, pullable snapshots plus one update notification beat a long series of property-specific signals. A new field can appear without adding another connection, and a newly created applet can request current state immediately. Copying a large map for frequent updates would be wasteful, though, and weakly typed keys invite spelling mistakes. This fits small desktop data, not every stream.

Error data travels in the same snapshot rather than through a modal dialog. The applet can then show stale values with a warning, hide them, or offer a retry according to the space and purpose of that visualisation.

There are unresolved questions. Sources need lifetimes, update intervals, error states, and perhaps sharing between several applets. A clock should not require sixty private timer objects merely because sixty visualisations exist. On the other hand, premature sharing can couple applets through one source’s policy.

This remains a Plasma prototype, not evidence of a completed KDE 4 shell. The useful result is that I can replace the rectangle with text, or the text with a graph, without changing how forecast data arrives.

The forecast itself still says cloudy. At least this time it did not download new clouds when I changed the border colour.

A Panel Made of Rectangles

Wed, 03 May 2006 23:11:00 +0000

I spent the evening moving three coloured rectangles around a blank window. This sounds less impressive than “working on the KDE 4 desktop,” which is precisely why it is a more accurate description.

The prototype is testing a Plasma idea: applets live in a containment, and the containment decides how available space is assigned. The applet should express useful size hints rather than assume that the panel is horizontal, 32 pixels high, and forever attached to the bottom edge.

My first attempt stored absolute geometry. Rotating the panel exposed the mistake immediately. The second stores constraints and lets the containment lay things out:

QSize Applet::minimumSize() const
{
 return QSize(24, 24);
}

QSize Applet::preferredSize() const
{
 return QSize(96, 32);
}

The prototype then reruns layout when its own size or form changes. Nothing here proves the final API. It proves that geometry policy has to live somewhere other than each applet’s collection of special cases.

Painting is the second experiment. Keeping content separate from the surrounding frame means a theme can alter margins and background without every applet learning the new decoration. That also means the layout must account for frame insets before assigning content space. I forgot this and produced a clock whose final digit lived just outside civilisation.

I prefer small visual prototypes with deliberately fake data at this stage. They make resizing, invalidation, and composition bugs obvious before a real calendar or device monitor introduces its own failures. The caveat is that rectangles do not exercise accessibility, input, localisation, or expensive content. A prototype can validate one mechanism while quietly avoiding four others.

I am saving each experiment as a tiny runnable case. When the graphics or layout API changes, these cases answer whether the concept still works without requiring a complete desktop session to survive long enough for the test.

There is no finished Plasma desktop hiding behind these rectangles. There are unresolved questions about applet lifecycle, configuration, persistence, and rendering. The useful result tonight is narrower: containment-driven layout survives changing orientation better than hard-coded applet geometry.

Tomorrow I may replace one rectangle with a clock. This will increase the prototype’s accuracy by one time zone and its bug count by an unknown but probably larger number.