« Fixing "unexpected RCODE (SERV... | Home | Tsukurimashou close to release... »

New KDE, still broken

Fri 28 Jan 2011 by mskala Tags used: ,

I see that KDE put out a new release on Wednesday. I'm disappointed that they still haven't fixed bugs 158556 and 180051.

Bug 158556 is "Manual hiding of panel." In KDE 3, you could manually hide the panel at the bottom of the screen. In KDE 4, you can't. KDE 4 offers an "auto-hide" feature, where the panel will randomly pop up and down in an attention-stealing way based on mouse position. There is no longer any way to hide the panel manually.

The official position is that you should use auto-hide instead of manual hiding, and the relevant maintainers have been consistently insulting to users who complain about it. The bug (which is a regression - it worked before and then was changed so that it doesn't work anymore) is misclassified as a "wish list" item. First reported in February 2008: almost three years ago. It is currently the fourth highest-voted item for its module ("plasma") on the "Most wanted features" list; it has also received more votes than any item for its module on the "Most hated bugs" list, and so would top that list if it were properly classified.

Bug 180051 is "Need a way to have default printer settings." When you attempt to print a document, the print dialogue offers two buttons for configuration, either of which can be expanded to show selectable options. One of these controls the CUPS options, set by the system-wide print server. The other controls the Qt options, which are local to Qt (in practice, local to KDE). The Qt options override the CUPS options; and every time the dialogue pops up they are reset to Qt's hardcoded defaults. The usual way this manifests in practice is that users who want duplex printing will set it up in CUPS's system-wide defaults, and then be surprised that KDE applications consistently print in simplex. More sophisticated users will dig into the "Advanced" options in the print dialogue, see that their desired settings are correctly reflected there, and be even more confused. A few users figure out that they can set duplex printing in the other options section, but are frustrated by the fact that they must do this on every single print job. On some systems, there's a similar issue between A4 and letter-size paper. Affected installations, especially in multi-user environments, typically end up with a number of printer stalls or bad documents printed and thrown out that is 50% or more of the number of usable documents printed.

The official position is that 180051 is a Qt bug, not a KDE bug. Nobody in the KDE project is officially responsible for working around Qt bugs, but various developers have been consistently insulting to users who complain about it. KDE maintains a copy of the Qt tree under revision control for the purposes of working around Qt bugs, but because of a desire to maintain the purity of that copy, and because it wouldn't help the small minority who get their Qt libraries independently of KDE, the existing patch for this bug will not be applied to that tree. First reported in January 2009: two years ago. This is also a regression, because KDE 3 worked. It is currently the highest-voted item on the "most hated bugs" list for the kdeprint module, with more than 14 times as many votes as the second-highest; it is also the eleventh most hated bug for the entire KDE project. In the Qt project's bug-tracking system, it is classified as a "suggestion"; there it was first reported December 2009.


Comment #41 on bug #180051 (https://bugs.kde.org/show_bug.cgi?id=180051) blows my mind.

I mean, this shit isn't black magic, nor should it require full-blown rewrites; it just requires a careful approach. One way to start: store printer settings where it makes sense (people are saying CUPS, but as there's usually only one instance of CUPS running on a system, I think it makes more sense to have the print daemon be stateless wrt printer settings and run one instance of a daemon per KDE session that maintains user preferences), have those daemons implement a standard interface for reading and writing settings (say, a set of D-Bus services), and then have the print dialog just consume those services.

Message passing is hardly a new method of modularizing software. The OpenPrinting Common Print Dialog, at first glance, looks like a start towards that idea. I have no idea why that's so hard to adopt -- inertia? trythil - 2011-01-28 11:54
Note comment #33, same bug, which points out that there are two UIs, one of which allows the user to enter settings that will be silently ignored; and those two UIs each had to be deliberately created. It would have been easier to only create one (preferably the one that works) and not create this problem, so somebody did extra work in order to create a broken system.

KDE says "we won't handle printer settings but will trust the underlying system (Qt)"; Qt says "we will NOT trust the underlying system (CUPS) but will still allow the user acces to it even though that will have no effect." The KDE people are right that Qt is broken; the KDE people are wrong in saying that it's okay not to make a workaround because it's the Qt people's fault. Choosing to delegate authority to someone else makes you partially responsible for their mistakes.

Note also that a patch exists and it has been deliberately decided that the patch will not be used, for reasons that have to do with relations between human beings rather than the quality of the software. Matt - 2011-01-28 12:32
Odd. For graphics card driver bugs, workarounds exist and are maintained by the KDE developers. (One single developer actually, as far as I know.)

From a purely philosophical point of view, workarounds for software bugs in open source software shouldn't be necessary, because the bug could and should be fixed rather than worked around.

From a practical point of view, temporary workarounds are better than enduring bugs. The question then becomes whose responsibility it is to apply and maintain the patch.

In the case of the printing module, KDE seems to think the responsibility lies downstream until upstream fixes the bug, resulting in unnecessary duplication of effort in the best case.

It is unfortunate that prior to 4.5 Qt was not legally able to accept user patches.

Regarding the manual-hide feature: You say it used to work even with plasma, but was discontinued. I can understand how one would think that the computer should automate away every mouse click that it can, thus prefering auto-hiding to manual hiding: If you want to click anything, you will have to move your mouse there anyway, with or without auto-hide. This reasoning becomes untenable when the time for how long the panel should stay visible is not constant or otherwise predictable.

It has been stated several times that fixing bugs is not sexy. Implementing new features and improving performance is far more interesting. On the other hand, developers who absolutely want their code to be correct are often reluctant to accept patches from users, thinking - often correctly - that they can do a better job than a mere user, which results in much wanted features to not be implemented.

Maybe this will become easier to deal with once the transition of the KDE repo to git is completed. def0 - 2011-01-28 16:18
I see it as a basic principle of mouse interaction that movement of the mouse should be a no-op. Others clearly don't. The way I see it is: "move mouse and click it to bring up the bar = one action, correct behaviour; move the mouse and don't click it to bring up the bar = the bar came up without my asking for it." The way someone who considers moving the mouse to be a positive action in itself would see it would be "move the mouse and click it to bring up the bar = two actions, which is one more than necessary; move the mouse and don't click it to bring up the bar = one action, correct behaviour."

One of these views could be called "click to focus" and one "point to focus." Either is internally consistent. It may not be possible to solidly establish one of them as unquestionably better than the other; but it should be possible to acknowledge that different people prefer one or the other, offer a choice between the two, and then *really consistently* follow the one that was selected. A great deal of annoyance seems to come from forcing a mixture of the two on users who want one or the other. And yet, KDE consistently enforces a bizarre mixture of clicking and pointing. And so do many Web pages, and the world is becoming less and less consistent in this respect over time.

On "it used to work even with plasma": I'm not sure that is the case. Is "plasma" specifically the KDE 4 dock/toolbar thing? The time when it used to work was the time of KDE 3, when I think the dock/toolbar thing was called "kicker"; so it may be that manual hiding was gone as soon as "plasma" was introduced. Matt - 2011-01-28 16:43
I see now. I myself prefer point-to-focus, but a manual hide button would make sense either way. I don't hide my panels, so it is not a feature that I would need myself.

(As for the web, I am always surprised how many people double-click links.)

Plasma is what the panels are built upon, one might say made of, as are the "plasmoids" inside it. The backdrop is a plasma container as well. Plasma was originally intended as a better, more efficient and easier to maintain panel to replace kicker, but was seen as too useful not to be used for other things as well.

If it used to work with kicker, but not plasma, it is not really a regression, as the panels have been rewritten completely and have no legacy from kicker except that they provide some of the same functionality. A lot of convenient features are still missing or incomplete. def0 - 2011-01-29 03:44
Whether it's a regression or not depends on whether you think "plasma" is a new version of the same thing as "kicker", or a really new thing; and, more generally, whether you think KDE4 is a new version of the same thing as KDE3, or a really new thing. And that's actually a deep description of the problem: I would like to see KDE4 as a new version of the same thing as KDE3, and "plasma" as a new version of "kicker". I don't think that a new version number and a rewrite, even of every single line of code, absolves the development team of responsibility for breaking what worked in previous versions. But the KDE developers obviously think KDE4 is a completely new thing, not a new version despite the name, with no expectation that it should necessarily be useful to the same people for whom KDE3 was useful. That's awfully disappointing; it is an attitude I associate with a major commercial operating system vendor. Matt - 2011-01-29 06:17
Parts are new, parts are ported.
Porting was necessary because of the switch from Qt3 to Qt4, and it was an opportunity to clean up the underlying code and frameworks.

KDE4 isn't even one thing now. It contains frameworks that are virtually independent from KDE and really should be part of Qt.

Some things that are new are still missing features of the things they replaced.
Especially the plasma panel. def0 - 2011-01-29 10:17
Oh, and yes, it is a bit reminiscent of the SunOS/Solaris situation. def0 - 2011-01-29 10:36
I actually had Microsoft in mind, and their versions of "Windows" and "Office" that aren't compatible with each other, but it's kind of depressing that there's more than one shoe that would fit.

I think there's a big difference between "we haven't finished porting over all necessary features to the new framework" and "we think it's okay to just not have those features anymore." KDE's position on manual hiding of the taskbar is the latter. Matt - 2011-01-29 13:19
There are some features of kicker that I won't miss.
I think it is understandable that some things won't be reimplemented, especially if those were not useful, didn't work, and weren't used in the wild anyway.
The position that manual hiding is not necessary at all, however, is not tenable. def0 - 2011-01-29 14:22
[CODE]On some systems, there's a similar issue between A4 and letter-size paper.[/CODE]
I have been wondering (and *complaining*) for *YEARS* about print jobs printing past the end of a sheet of letter sized paper. I finally have a comprehensible explanation. People have been saying it was my fault, even though I've looked at every config file under /etc, /var and $HOME that contained "A4" or "a4" even. Bruce - 2011-03-25 11:38

(optional field)
(optional field)
Answer "bonobo" here to fight spam. ここに「bonobo」を答えてください。SPAMを退治しましょう!
I reserve the right to delete or edit comments in any way and for any reason.