Desktop

I installed KDE 4.0 on a spare partition earlier this year and lasted about two days. It was interesting in the same sense that taking apart a toaster is interesting: there were clever pieces everywhere, but I still could not make breakfast.

KDE 4.1 is different. I have been using it for ordinary work since the release and, for the first time, I am spending more time in applications than arranging the desktop around them. That sounds like faint praise. For a desktop, however, becoming boring enough to disappear is a real achievement.

The panel is finally manageable. I can resize it, move it, add launchers and arrange the system tray without feeling that I am negotiating with a prototype. Plasma still exposes some rough edges, especially when widgets make optimistic assumptions about available space, but the basic shell now holds together.

KWin’s compositing also behaves much better on my Intel machine. Effects are not the important part; being able to leave compositing enabled without wondering whether the next window resize will turn into a slide show is. The new cover switch is amusing for several minutes, while smoother painting remains useful all day.

Dolphin has improved enough that I no longer immediately start Konqueror for every file operation. The tree view, tabs and saner selection behavior remove many small annoyances. There are still missing conveniences from KDE 3.5, and anyone depending on a particular panel applet should check before moving. “Newer” is not a substitute for “contains the thing I need.”

What changed my mind is not one large feature. It is the accumulation of small repairs: configuration modules that work, widgets that remember where they belong, fewer painting glitches and applications that look like parts of the same system. KDE 4’s new architecture was always ambitious; 4.1 is where some of that ambition starts paying rent.

I would now choose 4.1 for a machine I use myself, with a KDE 3.5 session nearby for emergencies. I would not yet migrate a room full of people who regard a moved icon as a personal attack. Progress is real, but so are users.

KDE 3.5 has been released, and I upgraded the main workstation after using development builds on another machine. The practical question was not whether the version number justified celebration. It was whether I could move my working session without spending the evening negotiating with it.

My naive plan was to keep every cached file and preference because testing had gone well elsewhere. Experience intervened. I backed up the configuration, upgraded the packages, and started with the existing account, but kept a clean account ready as a control. That made it possible to distinguish release problems from my personal museum of settings.

The existing account worked with only a small amount of cleanup. More importantly, the desktop preserved habits established across the 3.x series. Konsole, Konqueror, the panel, and common dialogs did not demand a new operating philosophy. Applications still felt related through shared shortcuts, appearance, and services.

This is the benefit of finishing a line of software rather than constantly replacing its foundation. KDE 3.5 contains visible improvements, but its strongest feature is accumulated correction. Years of reports have covered odd displays, unusual input setups, stale sessions, broken files, and people who click buttons in an order no designer predicted.

Maturity does not mean absence of bugs. It means the common paths are dependable, failure is more localized, and the model has become familiar enough that diagnosis starts from evidence rather than folklore. When an application misbehaves, I can usually decide whether to inspect its configuration, KDE output, X.Org, or the kernel instead of rebooting the entire stack ceremonially.

For C++ desktop development, the platform also feels coherent. Qt 3.3 and KDE libraries offer established patterns for ownership, events, actions, and user interface conventions. Consistency reduces application code and user surprise at the same time, which is a rare two-for-one bargain.

There is still excess. Some menus and control panels would benefit from deciding which choices matter most. Flexibility is admirable, but every checkbox is also a tiny maintenance promise.

My verdict is that KDE 3.5 demonstrates the value of patient integration. It does not need to astonish me each morning. It needs to restore my terminals, open my files, and stay predictable while I break something much more interesting in kernel code. On that measure, this release is in very good shape.

I’ve been testing KDE 3.5’s KHTML changes ahead of the final release. Passing a standards test is good news, but I wanted to know whether the same engine still handled the untidy pages I use for work.

I started with a small directory of local pages: nested floats, a wide preformatted block, a form inside a table, transparent PNGs, and one page with deliberately broken markup. Each isolates a behavior well enough that a rendering change isn’t just “this site looks odd.”

Then I used Konqueror on documentation and project sites with style sheets enabled, disabled, and replaced by a tiny user sheet. Keyboard focus still had to move through links and form controls in a sensible order. Better CSS support isn’t much help if a search field becomes unreachable without a mouse.

One layout did regress. Instead of filing the full page, I removed blocks until only a float, a cleared heading, and six lines of CSS remained. That reduction changed the report from a screenshot of somebody else’s site into a local file that showed the bug every time.

I kept the exact revision and compared the reduced page with the previous build. “Konqueror acted funny” is emotionally accurate and technically ornamental; a twelve-line attachment with a before-and-after result is useful.

KHTML’s shared role raises the stakes. A rendering fix reaches Konqueror and any application embedding the part, while a regression travels just as efficiently. Small local pages make that shared behavior testable without depending on a live site changing underneath the report.

The standards progress in 3.5 is visible, especially on layouts that used to need browser-specific nudges. The useful release behavior isn’t the badge, though; it’s rendering those pages more correctly without breaking forms, focus, and rough old HTML.

My little page collection now lives beside the build scripts. It’s less glamorous than a browser shootout, but much better at explaining the next crooked heading.

KDE 3.4 brought Akregator into the standard release, so I moved one concrete morning routine into it: read a few dozen project feeds, stop halfway, and continue later through Kontact.

The first useful behavior is dull but essential: read state survives. I marked a few entries read in Akregator, closed Kontact, fetched another batch, and reopened it. Old articles stayed read and new ones remained easy to spot. A feed reader that forgets this turns every restart into archaeology.

Kontact integration matters because it doesn’t create a second, slightly different copy of the feeds. Opening the Akregator component in Kontact and the standalone application showed the same subscriptions and article state. Links still opened through KDE’s normal browser handling, so reading a project post didn’t require a new set of application preferences.

I also disconnected the network before opening cached entries. Text already fetched remained available, while a refresh failed visibly instead of silently marking feeds current. That’s the sort of release behavior I care about: the application is honest about which state is local and which depends on the network.

Duplicate handling needed a closer look. Several feeds republish an item with corrected text, and some are careless with identifiers. Akregator mostly kept the list stable rather than presenting every refresh as breaking news. Where a feed changed identity as well as content, the duplicate was at least explainable from the source.

There are rough edges. Feed folders and filters invite more organization than I want before coffee, and malformed feeds remain somebody’s debugging exercise. I resisted building a taxonomy and kept three folders.

This is a small addition to a large desktop release, but it shows the advantage of KDE’s shared parts. Akregator can live inside Kontact, hand links to the usual browser, and use familiar shortcuts without pretending feed reading is a separate universe.

After a week, the best result is that I can stop reading and trust the list when I return. That’s enough; the feeds don’t need to become a lifestyle.

I spent this week using KDE 3.3 on a machine that is deliberately uninteresting: modest graphics, an ordinary IDE disk, and no patience for experiments during working hours. The trigger was a recurring claim that a Linux desktop is only comfortable after endless adjustment. I wanted to count the adjustments.

My first approach spoiled the test. I copied my entire home directory from another machine, including years of stale application settings. Konqueror opened with an absurd toolbar, file associations contradicted one another, and the panel had ideas of its own. This proved only that old configuration can travel.

With a clean account, I changed the keyboard layout, terminal font, and focus behavior. That was nearly all. KDE remembered sessions, mounted removable media predictably, and kept common actions in familiar places. More importantly, applications failed in ordinary application-sized ways. A text editor problem did not rearrange the whole desktop.

For development, the useful measure is interruption. Can I keep a terminal, editor, API documentation, and a debugger arranged for several days? Do copied selections behave consistently? Does the session return after a kernel reboot? KDE 3.3 did these things without becoming the day’s project.

I added one less visible test: I watched memory use across repeated opening and closing of the applications I rely on. A desktop can feel quick for ten minutes while quietly accumulating baggage. Nothing in this informal check grew without bound, and leaving the session running overnight did not turn the next morning into an archaeological dig through swap.

The common Qt foundation deserves some credit. Shared dialogs, font handling, and event conventions reduce the small disagreements that make a collection of programs feel improvised. Integration is not only visual consistency; it is predictable behavior under the same input.

There are still annoyances. Some control modules expose every possible knob, and a few dialogs feel designed by committees that never met. Yet the foundation is settled enough that these are complaints about furniture, not the building.

My conclusion is unfashionably positive: boring is a technical feature. A mature desktop preserves context and lets me concentrate on C and C++. If I cannot remember what the desktop did all afternoon, it probably did it correctly.