Blog

A Qt application of mine began drawing stale text after I scrolled a custom widget. The bug appeared only with desktop compositing enabled, so I immediately blamed the driver. Then I ran it on a different card and saw the same stale text in a slightly different place.

My naive fix was to call update() repeatedly after scrolling. That reduced the frequency without curing it. Repainting more often can hide an invalid region briefly, but it cannot make incorrect geometry correct.

I reduced the widget until it painted only two rectangles and a label. The problem remained when one rectangle moved outside the area returned by the widget’s internal item bounds. My clipping assumptions were wrong: I invalidated the old logical rectangle but painted a pen and text extending beyond it. Compositing changed timing and exposure enough to reveal the mistake more reliably.

After expanding the dirty region to include every painted pixel, both drivers behaved. I then tested without compositing, with XRender compositing and with OpenGL compositing. That matrix is useful because a defect that follows one backend suggests a different layer from a defect that follows the application everywhere.

Adding a plain background behind the moving item made stale areas obvious and gave the reduced test a result anyone could recognize immediately.

Driver debugging still requires exact information. Card family, kernel module, X driver, Mesa version, colour depth and compositor backend can all matter. “Latest driver” is not a version, especially a week later. A minimal program is worth far more than a description of a large application that sometimes looks odd.

The most useful distinction is between wrong commands and wrong execution. If the application issues the wrong clipping, geometry or lifetime operations, changing drivers may only move the symptom. If a tiny correct sequence fails on one driver and succeeds elsewhere, the driver report becomes persuasive.

My practical conclusion is to simplify before assigning blame. Disable layers one at a time, record the exact matrix, and inspect the application’s painted bounds even when hardware acceleration appears implicated. Graphics stacks are complicated enough without accusing the innocent portion first. Unfortunately, every portion has previous convictions.

I wanted a compile job and its helper processes to stop overwhelming everything else on my test machine. Renicing the shell helped until the build launched processes with behavior I had not accounted for, and it did nothing about memory consumption.

Linux 2.6.24 includes the control groups framework, so I enabled the relevant options and mounted a control-group filesystem for testing. My first attempt was to write the compiler’s process ID into a group after the build had started. Some children were already elsewhere, and the result was inconsistent enough to look supernatural.

A control group is a hierarchy used to classify tasks. Controllers attach particular resource policies or accounting to that hierarchy. The framework itself is not one universal “make this process small” knob. CPU scheduling, processor sets and other controllers expose different files and semantics. A task belongs to a group in a hierarchy, and children normally inherit membership, so classification should happen before launching the workload.

I created a group, moved my test shell into it, and then started the build from that shell. Its descendants appeared in the same group. Applying CPU scheduling controls made the machine more responsive under contention without changing every process individually. Memory control is a separate matter and depends on kernel configuration; enabling it also has overhead that should not be waved away.

The hierarchy is powerful but easy to design badly. Groups may represent users, services or workloads, and those choices do not always nest neatly. Multiple hierarchies can attach different controllers, which provides flexibility at the cost of another opportunity to create an administrative puzzle.

For now I regard cgroups as kernel machinery for building resource-management policy, not as a finished desktop feature. The interface is low-level and sharp-edged. Tools will need to create groups, place tasks early, apply limits coherently and clean up afterward.

My practical conclusion is to start with one measured problem and one controller. Verify membership before interpreting results, and do not confuse accounting with enforcement. Cgroups can organize a family of processes in a way nice alone cannot. They can also organize one’s mistakes into a tidy hierarchy, which is progress of a sort.

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.

Nokia’s proposed acquisition of Trolltech has produced the predictable range of reactions, from “Qt has won” to “Qt is doomed” with very little tedious ground in between. I depend on Qt for code and on KDE for my desktop, so I wanted a more useful answer than choosing a banner.

My first attempt was to infer the future from the purchase price and press statements. This yielded several confident theories and no information about what happens to tomorrow’s source release. Corporate language is excellent at sounding precise while promising room to turn a ship around inside every sentence.

The practical questions are narrower. Will Qt continue to be developed as a cross-platform toolkit? Will the free-software editions remain available under their existing terms? Will Trolltech’s engineers keep authority over technical decisions? Will commercial customers still see a supplier interested in desktop systems as well as phones?

Nokia has an obvious reason to value Qt’s embedded work and Qtopia. A large device company can fund engineering, testing and broader deployment that Trolltech could not easily buy alone. That could improve Qt itself, particularly where desktop and embedded needs overlap. It could also pull priorities toward Nokia’s products. Ownership does not abolish incentives; it changes which incentives attend the meetings.

KDE is less exposed than a proprietary customer because the toolkit’s free license and the KDE Free Qt Foundation provide important guarantees. Source availability also means the code cannot simply be made to vanish. But a living toolkit is more than a source archive. Maintainers, release discipline, documentation and sustained cross-platform work matter.

For now, nothing in my build process changes. Qt 4 remains the strongest general application toolkit I have used, and the acquisition is not yet complete. I will judge Nokia by releases, licensing decisions and retained developers rather than by either celebratory or funeral rhetoric.

My conclusion is cautious optimism. More resources could be excellent for Qt, and Nokia appears to understand that a broad developer community is part of what it is buying. If it tries to turn Qt into a narrow internal component, it will have paid handsomely to destroy much of that value. Even very large companies are usually capable of noticing an invoice.

I opened a long PDF in Okular today, searched for a phrase, added a note, and then printed three selected pages. The first three actions worked well. The printer produced pages two through four instead of the pages I thought I had selected.

My naive response was to repeat the job with different numbers. That merely consumed more paper, proving that printers remain the most effective mechanism for converting uncertainty into physical objects.

The confusion came from document page labels not matching the PDF’s internal page sequence. The introduction uses roman numerals, while the print dialog expects physical page positions. Okular displays both pieces of information in different contexts, but the distinction is too easy to miss when acting quickly.

As a viewer, Okular is already a substantial improvement over keeping separate programs for PDF and other document types. Search, text selection and navigation feel consistent because the shell supplies them while backends handle formats. That mechanism also exposes limitations: a backend may render well but lack annotations, forms or reliable printing details.

Annotations are useful, but I would not treat them as safely embedded in every source document without checking how that format stores them. Exporting or sharing a marked document deserves a test copy first.

My practical conclusion is to verify page labels in print preview and keep original documents untouched until annotation behavior is clear. Okular has become my default viewer, but “default” does not mean “incapable of surprising me.” That title remains permanently reserved for printing.