KDE Plasma — 4
Testing KDE has been going well, but real-world reality checks are due. As was expected, breaking away from GTK to KDE is trading one set of paper cuts for another. The list of paper cut issues is larger than anticipated.
Some good news is KDE is configured with text-based files. No silly Windows wanna-be dconf registry. The bad news is the KDE developers have been sloppy. Linux desktop users have complained for years how “dot files” are almost impossible to organize or control. KDE config file storage contributes to the complaint.
The $KDEHOME environment variable no longer is supported to orderly store KDE config files. Long gone are organized days when almost all KDE config files were stored in $HOME/.kde. Most config files now are stored in $HOME/.config ($XDG_CONFIG_HOME). Related data files are stored in $HOME/.local/share ($XDG_DATA_HOME). Compared to the $HOME/.kde method these locations are XDG compliant. Dumping them haphazardly is sloppy when storing config files in $HOME/.config/kde would satisfy the standard and be more organized. There are many config files and outside a few exceptions are not organized to help users. The Trinity Desktop Environment (TDE) and LXQt do not have this problem. The sloppy storage of config files does not directly affect daily usability but is messy. The manner in which KDE config files are stored is disappointing.
Related to dumping config files, the GNOME/GTK Settings Synchronization Service seems hard-coded to create $HOME/.gtkrc-2.0, $HOME/.config/gtkrc and $HOME/.config/gtkrc-2.0 despite the files already existing in locations defined by the GTK_RC_FILES and GTK2_RC_FILES environment variables. This is presumptive programming although not directly affecting daily usability. That service should be written to look for the environment variables rather than create files in a hard-coded location. Possibly this paper cut is being resolved upstream.
Something repeatedly created $HOME/.kde/share/config/kdeglobals. All config files are supposed to be stored in $XDG_CONFIG_HOME and $XDG_DATA_HOME locations. On a hunch, exporting KDEHOME=$XDG_CONFIG_HOME seemed to resolve the problem. Why this config file was being created is a mystery. Perhaps some remnant KDE 4 code remains.
Despite searching diligently around the web, finding proposed solutions that did not help, noticing other people seeking the same answer, and verifying the service is disabled in the System Tray Entries, the only solution to stop kdeconnectd from launching is removing the package. Finding information about this service is frustrating. This is a security issue because that daemon opens port 1716, something that many users probably are unaware. Because of the security issues the upstream advice is to remove the package. Why is there no configuration or panel applet to toggle the service as needed? Removing the package is a low level paper cut because there is no need here to keep data synced to other devices.
CPU frequency increases when using KDE. There is no such problem with other desktop environments (DEs). This problem might have been partly resolved after removing the kdeconnect package, but further testing is needed.
KDE remains mired in the days of using a progress splash when launching KDE. A splash is not required, but then the user is left wondering if the desktop is launching because there is a long wait to see the desktop. The splash is visual feedback that something is happening. Users are not informed why the desktop is taking so long to launch. The original KDE 3 splash images provided information about which background services were being launched. Why does KDE take so long to launch? Most background services are disabled. Akonadi and Baloo are not running. The KDE Connect daemon package was removed. Other desktop environments launch without a splash. The splash is nominally annoying but not a hill worth dying on.
On some systems everything launched slow once the desktop was running. Launch times are about 3 to 4 seconds whereas on the 4-core office desktop launch times are less frustrating. There is a latency when using the panel menu. Searching the web indicates many people experience this and some people accept the behavior as normal. Cached files are not deleted and sessions are disabled. Most background services and all desktop effects are disabled. Slow launch times like this on capable hardware is discouraging. By happenstance, this significant show stopper seems to be related to CPU frequency governing. Why the KDE window manager is affected is somewhat head scratching.
A common complaint when using laptops is some configuration dialogs are larger than the screen size. These dialogs do not have a scroll bar. This also is a problem with certain dialogs in KDE 3 and TDE. Seems these dialogs were designed with monitors as big as TVs. Not obvious is how to access the dialog buttons. In other DEs, including TDE, the trick is pressing the Alt key while using the mouse to move a window. That does not succeed in KDE. In KDE this is done by placing the mouse cursor on the dialog edge. The cursor changes shape. Press the secondary mouse button and select More Actions-->Move. Possibly this is a conceptual error here but a minor paper cut.
Thankfully a majority of KDE tooltips and mouseover popups can be disabled, but there remain places where these features cannot be disabled. Examples include mouseover hovering in Dolphin, Konsole, Falkon, Krusader, System Settings, and configuration dialogs. Some discussion threads indicate the problem might be the underlying Qt rather than KDE. The mouseover popups in System Settings is resolved but requires a newer version of KDE.
A similar nuisance includes mouse wheel cycling. Cycling can be disabled in the panel taskbar buttons and desktop mouse actions, but not with Dolphin tabs, Konsole tabs, Kate tabs, or the panel KPager virtual desktop widget in the panel.
Dolphin is an above average file manager yet lacks a few features available in the original Konqueror. The current Konqueror remains usable as a file manager but lost the “profile” configuration options to distinguish between web browsing and file management. The design now seems primarily as a web browser. Unlike the original or current Konqueror, Dolphin cannot be configured to preload.
Stability might be questionable. Several times during testing the panel never appeared after logon. Browsing the web indicates this is somewhat a commonly reported event.
Akonadi is a problem. The love affair with this “pillar” needs to end. The technical debt with Akonadi probably is high, but affected developers should follow the example of the KAlarm developers and configure Akonadi as an optional plugin. That lets users decide and everybody wins.
A desktop never should be annoying or distracting. In many ways KDE is pleasing to use, but irritants such as mouse wheel cycling, tooltips, mouseover popups, and disappearing panels are difficult to ignore. Many of these tooltips and mouseover popups provide no value because they repeat what the user can already see or read from the GUI element. Some people might roll eyes with such issues. KDE is polished in many ways and seems to have great promise for future DEs, but at times seems designed by geeks for geeks.
Some of this is being addressed upstream with patches, some can be ignored by removing packages, and some can be tolerated with some Pavlovian training to avoid certain irritants.
One long-standing paper cut hasn’t changed in more than a decade: the annoying bouncing mouse cursor remains the default.
Posted: Category: Usability Tagged: General
Next: Exploring Desktop Environments — 4
Previous: KDE Plasma — 3