Posted on by Martin Flöser

Some thoughts on the quality of Plasma 5

Last week we got quite some criticism about the quality of KDE Plasma 5 on the Internet. This came rather surprising for us and is at least in my opinion highly undeserved. So far what we saw is that Plasma has a high quality – probably better than previous iterations of what was known as the KDE Desktop Environment – and got lots of praise for the state it is in. So how come that there is such a discrepancy between what we see and what our users see?

The chain breaks at the weakest link

Plasma is just one piece of the user experience our users get. It’s the most visible one and it’s also the one which gets all the blame if things break. But in reality there is much more to it. Plasma depends on other libraries – most importantly Qt – and on drivers (OpenGL/Mesa) and on hardware. All of that is put together by distributions. We don’t ship the software to our users, we ship it to the distributions which then integrate it with the rest of the stack. All we can do is give recommendations to our distributions about common issues and how to prevent that they happen. Now I don’t want to move the blame to the distributions, because that would also be undeserved. I just want to explain how complex the process is.

Some numbers

So let’s start with a look at some numbers. I’m looking at a combination of the applications plasmashell, kwin, krunner and systemsettings. These are the most visible to the users. The numbers will be slightly distorted, because there were also bugs going in for the old 4.11 series and only plasmashell is a 5 only product.

Over the last 365 days 1313 crash reports were reported for these products. That’s quite a number, but means it’s only about 3.5 per day. Given our large user bases that’s not that bad. If we had a huge quality problem we would get hundreds of bug reports per day. And yes we do, I had been in such situations in KWin that we got two digits numbers of duplicates per day.

Of those 1313 crash reports 127 are still unconfirmed (we need to improve here!) and 23 confirmed. The number looks high, but now we need to look at how they distribute. There are a few bugs with a high number of duplicates. Given my limited search skills I found one with 91 duplicates which got a fix released six months ago, but we still see new duplicates for it. I come back to how that happens later. A few bugs reported several times and we get close to the numbers. I just summed up the number of the ten most often reported crashers and that’s already about half of the reported crashes.

So why are there crashes reported so often and are not immediately fixed? This is exactly the weakest link I have been talking about. It’s things we don’t have an influence on.

Graphics drivers

One of the most severe issues we hit with Plasma 5 is an issue with the Intel graphics drivers. I think that this problem is the reason why people complain about instability of Plasma. The only reason. Crashes in drivers (especially Intel) are nothing new, it’s a problem which has haunted us for years. For example the most often reported crash against KWin is a crash in the Intel driver – we worked around that issue by disabling a feature for all Intel users and will never ever enable it again.

Now I know that this sounds like passing the blame to the graphics drivers and I can imagine that you say that we need to QA test. That is true, we need to QA test, also against the drivers. Just that’s not possible. I blogged about why that’s not possible back in 2011. Nothing has changed except that the number of possible hardware and driver combinations further increased.

The biggest problem for us is that the drivers a distro will ship doesn’t exist yet when we develop and test our software. Even if we would use development drivers it would be too old compared to what distros ship.

One could say it’s the responsibility of the distribution to do the QA. Yes, they as a software integrator should make sure that the software works together. And they do, but lots of it runs in VMs which don’t provide the “real” hardware. But expecting distributions to do all the combinations we cannot test, is also wrong. If there is one which can do the quality assurance of e.g. the Intel driver it’s Intel. They have the hardware, they have the developers (AFAIK there are more fulltime devs working on the Intel drivers than we have devs on Plasma), they have the QA team. I do not know how they test, but I am sure they could spot such severe driver regressions.

What to do when we hit such a severe driver issue? Well that’s difficult. If possible we can workaround like the KWin problem I mentioned above. But that still takes time till it reaches the users. In this particular case we informed distributions about a possible workaround on Xserver level and I hope ll distributions applied it. If not please complain to your distribution.

Multi Screen woes

Another source of reported instability is multi screen handling on X11. Again the problem does not lie on our side but in this case Qt. First a word of clarification: auto-testing multi-screen on X11 is extremely difficult. Virtual X servers like Xvfb do not support the randr extension which makes it impossible to mock a correct behavior in X. Also testing with real X doesn’t help as that can only test with the screens one has and physically plugging out a screen during an auto-test isn’t really a solution.

So this sounds like blaming Qt, which of course is not what I want to do. You can rightly question why we as KDE do not help Qt with it. Well we did. Especially Dan Vratil did an incredible job of improving the experience directly in Qt. There were things which one wouldn’t believe are possible. For example there is an xrandr call to read the configuration and that blocks the Xserver in the Intel driver. Now each Qt application did that and caused a freeze. When I figured out the root source for this problem I created a remote denial of service proof of concept against X server and informed the security list about this problem. I did this in January and haven’t got a reply till now and have not talked in public about this. So yeah I just did a full-disclosure. Anyway Dan worked around this problem and fixed many more.

So why is this all still an issue? This is slightly related to how Qt and Plasma releases are not synced. For example at the moment Qt 5.5 will not receive any bug fix releases any more, but all we have in distributions is Qt 5.4. This means any fixes we do will not reach users till distributions roll out Qt 5.6. It’s rather depressive to be honest. You know you fixed an issue, but it doesn’t reach your users. I think this needs works from both Qt and the distributions. We need more bug fix releases and distributions must update Qt more often. I hope that the long term release Qt 5.6 will improve the situation as that gives us also a chance to provide bug fixes and hopefully reach our users.

As it stands there seem to still be crash cases in Qt 5.6. Since recently I have a nice tool which should allow to mock multi screen setup and I want to try to dedicate some time this week to create test cases. If that works I hope we can move this forward.

Issues fixed months ago

Another problem we noticed is that fixes we created doesn’t reach our users. This is mostly to how some distributions work with the exception of rolling release distributions. They create a “stable” and “feature frozen” product. If a major version number increases it’s not going to be updated. I just described the problem with outdated Qt, that’s part of the story. The update didn’t get into the distribution and thus fixes don’t reach our users.

Even more with frameworks we don’t provide bug fix releases and that creates “problems” for distributions. They don’t roll our the new frameworks, although they fix important issues. This is slowly improving, distributions need to get used to this process and also accept that their policy doesn’t apply.

Furthermore one needs to point out that some distributions do have additional repositories to get newer software. If you use e.g. Kubuntu 15.04 I highly recommend to use that. Every non LTS release from Ubuntu is basically a testing distribution. If you use that you decided to go with faster software updates. Please use the ways to get those updates. If you don’t want that please stay with LTS.

This is something which applies to pretty much all distributions. Stay with the long term releases if you don’t want to update to newer software.

Removed features

What we also heard a lot lately are complains about that we removed features. Yes we did that, we streamlined some implementations, we decided to focus on the core, we decided to not port all X11 specific code, but allow 3rd party applications to fill that niche (e.g. SDDM or LightDM instead of KDM). Nevertheless let’s look at some of the complains.

Legacy systray

The biggest problem for our users seems to be the removal of support of the legacy system tray (xembed). This was not a move against our users, but a change we did not expect to cause so many problems. We did evaluate the situation prior to the release and saw that it was possible to do this step without loss of functionality. Nevertheless it created problems. How was that possible?

A key feature to the switch was getting the distributions in. Our distributions had to patch software in the same way as Ubuntu did. So we collected the required changes and informed distributions about it. The patches to Qt 4, which flags to enable in which repositories and so on.

With some distributions that worked awesomely, with some we had problems. In one distributions the GNOME maintainers refused to enable the required flags (boo), one distribution decided to not enable the Qt 4 patch because that’s not what they do, but they already had patches for arm64 (WTF? Support for a theoretical architecture is more important than users on existing hardware? Wtf, wtf!) If your distribution did not do the transition in a sufficient way, please complain to them and not to us.

Now there were things which got overlooked. Skype needed proper multi-arch and the package installation did not always work. Distros were informed about this problem once we noticed. Some proprietary applications used static linking destroying the “magic”. That’s unfortunate, but also not our fault. And also in the area of proprietary applications: wine applications have no fallback. Sorry about that, but we just were not aware of that and we didn’t get a feedback quickly enough.

We noticed that this is a problem and David started to work on a solution for Plasma 5.5. I’m not happy that we had to do that as it just delays solving the actual problem: we need to get rid of the old systray. I’m already seeing the bug reports about unusable systray icons on HighDPI or not working on Wayland. There is also one solution: work together to get this transition done. Bug your distributions to include all patches (if not done yet), bug your favorite projects to port. It’s about time!

Applets per virtual desktop and dashboard

Some of the feedback we got is that users are unhappy that they cannot have different applets and wallpaper per virtual desktop and also on dashboard. Yes we understand that this is seen as a regression, so let’s look at why we changed.

First of all: change is sometimes required also removing features is sometimes required. We are sorry for the users affected by such changes, but we normally don’t do that without good reason. We are extremely careful as you can see in the systray case where we coordinated with distributions months prior to the release to make the transition smooth.

For the features here in question we need to look back at the last iteration of Plasma. Some of the things we learned was that these features just didn’t really work, they were buggy and there were many conditions were it just didn’t really work. An example is KWin which just never really knew when Plasma is in dashboard mode, we failed to properly set up the state and it just resulted in lots of quirks. So when we looked at it for Plasma 5 we realized that it’s extremely close to another mode KWin could handle well: Show Desktop. So we merged those two and improved the Show Desktop experience at the same time.

Multiple virtual desktops in Plasma had always been a quirk. I remember one discussion shortly after starting to contribute to Plasma: we were not able to properly support this feature in Desktop Grid or Desktop Cube. Technically that was just impossible how Plasma worked. We were not able to solve this problem in all of Plasma 4 and we would not be able to solve it in Plasma 5. In addition it also caused problems with various other features, so overall it looked like a better idea to disable this feature in core Plasma. This goes along with the fact that we consider Virtual Desktops as a high productivity and experienced user feature. By default they are disabled.

Now we understand that this is a feature important to some users. But we need to ask you to understand that we cannot maintain all possible features for all possible users and that sometimes the quality of the complete product is more important. Furthermore Plasma is a flexible product and it should be possible to provide this as a 3rd party feature.

Not ported featured

There are a few more features which just didn’t make it to the new release. In many cases that’s because of the features do not have a maintainer. Examples for this are KHotkeys and the application menu. In both cases the port was not trivial due to changes in the underlying infrastructure, so we couldn’t manage it with our limited resources.

But that’s of course a chance for you, dear reader. If you are a developer and loved some of the features we were not able to provide, you can step up and maintain them. We are always looking for more help!

What was important to us is to not overload ourselves with more code than we can maintain. We want to provide a high quality product which we can ensure that it is high quality. This required to cut down in some areas. I think that was the correct decision and I think we reached our goal in providing a foundation for a high quality product.

Improved Workflows

Overall with our new product we put a focus on quality and adjusted our workflows to ensure that we have a high quality. As already mentioned we decided to focus on the core and by that focus only on what we can ensure to maintain. That’s just one aspect to it. Another aspect is the increased usage of automatic testing thanks to continuous integration done directly by KDE and also by our distributions. A big thanks to openSUSE for openQA and Kubuntu for the Kubuntu CI! Those two instances have caught many issues which slipped through our CI.

Additionally we release in shorter cycles (frameworks each month, Plasma every three months). This is only possible by ensuring quality through higher code review, requirements for auto tests, etc. A good overview can be found in sebas’s blog post on the topic.

177 Replies to “Some thoughts on the quality of Plasma 5”

  1. From what I can tell, most whoops I had seem as if they were distribution dependent.

    I’ve had issues, especially with the sound applet, and applications crashing on logout etc in OpenSUSE, KUbuntu, Fedora and Tanglu, despite problems with upgrades, orphaned packages, wrong dependencies -the removal of telepathy UI / IM Contacts would remove your entire desktop environment – etc.).

    That said, I’ve switched back to ArchLinux this weekend, and most of my issues seem to be gone. It’s a bit early to say, but it seems as if the distros do have some issues there.

    For the KDE side: The most prominent issue I think everyone has is the plugging of an external monitor. I’ve had several issues with that as well, and still do have them. Partly, they’re connected to issues with the intel driver, partly it’s simply the X11/Qt/KWIN/SystemSettings combination “not getting it right”. Though, judging since Plasma5 start, the situation has improved, though, it’s not perfect still.

    “When I figured out the root source for this problem I created a remote denial of service proof of concept against X server and informed the security list about this problem. ”
    Are you sure you never talked about this before? I’ve read this somewhere in the past.

    “Legacy Systray”
    Well, the most prominent application having issues or using the legacy systray may be Skype. I’ve not found a single distribution yet where skype actually works in Plasma5, and bugging Microsoft to switch could take some time ;-).

    1. Skype works fine, one needs the i386 version of sni-qt, though, if one uses amd64 architecture.

      1. Hmh, could be that it’s missing in the skype depends if somebody installs it with the deb package provided by Microsoft.
        That’s something you need to know, I’ll test it when I get home later today.

    2. In Ubuntu, using Unity (and very likely using KDE as well), Skype uses an Indicator instead of the legacy systray. So it is already capable of using one.

  2. I think this was somehow a communication failure between the user base and the KDE developers.
    Most distributions still ship KDE4 by default and most of those who provide Plasma5/Kf5 do that as an option for users who are willing to test software. Being such a user I know how high the pain threshold can be in exchange for getting the latest Plasma experience. Many issues are like “Oh, what an annoying bug, but it’s unstable software, what’d ya expect?”
    Another problem is for sure the “Oh, that’s so obvious, I’m sure they fixed it already”.

    So in the end you got less feedback than you needed. I for myself switched to Plasma5 about two or three months ago (started with 5.3). My first impression was that the whole desktop was pretty experimental. Nothing really worked, especially not with some KDE4 configs still in place (I’m looking at you KWallet, but not only at you). It took me a long time to get rid of all these issues without throwing away my whole user dir.

    Right now it’s running more or less smoothly, but I still have some bigger problems and lots of rough edges are still unrefined. Plasma 5.4 made things marginally better, but not perfect.
    A package update I got today got rid of one of those: effects like “Show Desktop” or any sliding Plasma popup lagging shortly but very noticeably when invoked for the first time after plasmashell started.

    Other issues are still there: e.g. a very broken user experience with the Folderview widget which still isn’t integrated with Dolphin and behaves like a total (and very dumb) alien.

    There are also some bugs which only happen rarely, but are still very intrusive. For instance, I sometimes have the problem that some virtual desktops just go black. Panels and widgets vanish, only windows are still there. This only happens to backgrounded virtual desktops, never to the one that is currently in front. So you don’t notice it until you switch your virtual desktop and wonder why there is no plasma panel above your Thunderbird window.
    I searched Google and bko for it and couldn’t find a report. But on the other hand, I cannot reproduce this bug reliably and at the time when it happens I usually have more important things to do than analyzing why my desktops are black. So I restart plasmashell and continue work. And then this bug still goes unreported simply because I didn’t have the time to try everything imaginable to reproduce it or analyze why it happened when it happened. Consider this an inital report. 😉

    And then there are all those minor problems that you got used to when using KDE over the years that you don’t even bother anymore reporting. For instance windows (including kdialog file picker but also full-blown applications) to open at tiny window sizes just because the developer didn’t mind setting a sane minimum size that at least fits the main GUI components. Or take dragging Plasma widgets from one screen to another. It never worked. Multi-screen handling in general: don’t you dare to unplug a monitor if you spent some time on organizing your panels. Never! Ever! This is not a new Plasma5 bug. This also never worked in KDE4. Some of those things you already read in the PlanetKDE blog post you were referring to. But again, some of those things are not new to Plasma5. They’re very old KDE issues which never got fixed and maybe never will? I somehow got used to them but they still annoy me.

    To sum it up: it sums up. All those minor things paired with some bigger issues distort the picture of a stable Plasma5 a lot. And it doesn’t help that apparently there isn’t enough feedback from the community. I don’t blame the developers nor the users alone. Both have to work more closely together on this. After all, KDE is a hell of of big and complex system and bugs are to be expected. But then as the author said in that PlanetKDE blog post, right now I also rather wish for a pure bugfix release without any new features.

    1. I hope you reported all those issues! After all my blog is not a bug tracker. Even if you are not always able to reproduce it: better report it.

      1. Except for the “black desktop” issue: yes.
        Especially some of the mentioned KDE4 issues actually have several and sometimes even very old reports. But most of them never go really fixed or are still work in progress.

      2. I think for a regular user the bug tracker seems more of a developer thing. Plasma might benefit from having an easy way to report _feedback_ from within the desktop which would autofill most of the required info.

  3. Hi,

    I just want to give you some positive feedback. 🙂 I am running plasma 5 on three boxes: one regular AMD laptop and two intel systems. All three of them run very nicely. One is in use by my dear mother. If she’s not the prototype of an end user I wouldn’t know who else. She likes it very much (more than plasma 4).

    Said that, I use Arch on all plattforms. IMHO that’s the distribiution way to go: rolling release, as vanilla as possible. No problems here. Thanks for your work and don’t get frustrated by to many people screaming: the majority is silent because the product is very good.

    1. I’d actually like to second this too, I’m satisfied with Plasma 5 as my daily driver now – I’m very happy with it and the hard work you guys are putting into it!

  4. Couple of comments, as I did a couple of rants on the suitability of Plasma5 in a productive environment:

    1) Issues in drivers and Qt: Having both an Intel (Dell Latitude E5450) and nvidia (Thinkpad T430, disabled optimus) machine at hand, I unfortunately have to say that both have issues on their own. With Intel I don’t get crashes, but rather redraw issues (windows are suddenly viewable on all desktops despite only being on one, of course you can’t interact with them. Both have _heavy_ issues with multiscreen. I use a docking station both at home (nvidia) and at work (intel). I had to completely disable kscreen because it managed to get a configuration so messed up that plasma would refuse to load (it just hangs at the loading screen) unless I deleted the kscreen files in ~/.local/share. In both cases it gets docking / undocking wrong, ending up with seeing half a wallpaper within the larger screen (nvidia) or the second screen sometimes not showing at all (intel). Whilst being told that most of this is fixed in Qt 5.5, among the crash of systemsettings5 in the monitor settings: nope, updated to Qt 5.5, rebuilt, still the very same.

    2) On the suitability in general and on quality: There are complete show-stopper bugs, e.g. not being able to log in at all when a directory provides the users. Whilst this is a critical bug and complete blocker, it has not been fixed since being reported by me over various channels (bugs.kde.org, IRC …)

    3) On features / applications not being ported: the problem is probably more the half-ported state and the dependencies. Since KDEPIM is now ported, I can use that, but then I can’t use Kopete because it doesn’t compile against it. And KF5 is not usable in some (corporate, again) use cases. Marble has recently been ported, digikam has not, thus I can’t update one of them because it depends on the other. These are only two examples among many.

    4) On missing features: some of them, compared to other desktop environments, just hurt, as they provide very basic functionality, such as a simple weather display in the panel or the ability to see upcoming events / appointments in the calendar. These are papercuts, but if you are used to something working and then it being gone in a new release, this definitely makes users unhappy.

    5) On reporting bugs: this is, as always, a very mixed bag. In some cases you get great replies and fixes rather quick, in some cases things like complete showstoppers or bugs corrupting data, confirmed by many users, go unfixed for years (!). And then, in some cases, you get treated quite unfairly and rude, which doesn’t really motivate to write further bug reports. Not to mention that in some cases (two come to mind right away) you get shouted at or ridiculed about something you criticize, then a couple of months / years later it gets resolved / fixed exactly the way you proposed, with people realizing you were right. That’s hardly motivational, too.

    All in all I unfortunately have to agree with most of the criticism. On the desktop plasma5 is usable, with minor papercuts and caveats compared to KDE4, but at least also some nice new things making up for it. On the other hand: in a corporate environment Plasma5 is, in my opinion, completely unusable and I highly disadvise upgrading / using a distribution shipping Plasma 5. It’s not worth the hassle and full of either complete showstoppers (not being able to log in) or at least big annoyances (dual screen on docking stations) in things that are just every day use cases in a business environment.

    1. Whilst being told that most of this is fixed in Qt 5.5, among the crash of systemsettings5 in the monitor settings: nope, updated to Qt 5.5, rebuilt, still the very same.

      Feel free to send me a backtrace. I want to try to add auto tests for multi screen issues this week and need a sample set.

      e.g. not being able to log in at all when a directory provides the users

      Sorry, I don’t get that? KDE doesn’t provide a log in manager. Consider using a different one which provides that. I don’t think that reporting this issue to KDE will get it fixed given that the software is not provided by KDE.

      such as a simple weather display in the panel

      Give a try to http://kde-look.org/content/show.php/Weather+Widget?content=169572

      or the ability to see upcoming events / appointments in the calendar.

      Ah yeah with the ported kdepim stack we can enable that code now. I’ll try to ping someone about it.

      1. > Feel free to send me a backtrace.

        Shall do when at home, this is the nvidia laptop

        > Sorry, I don’t get that? KDE doesn’t provide a log in manager.

        It’s the closest you have to a default (sddm), and it was acknowledged as a problem by various KDE people. Should also have been fixed already, just wasn’t. Probably the reason is because it’s not a problem in sddm itself, but rather the breeze theme.

        That is, side-note, another problem, also with the somewhat fuzzy borders of what is KDE / Plasma. Users see the whole package, they can’t log in on KDE (distributions), whilst it works on others.

        > Give a try to http://kde-look.org/content/show.php/Weather+Widget?content=169572

        That works and is what I use, with minor caveats. Mostly the usability is, compared to what KDE had, a bit bad (you can’t easily add / search for locations, you can’t change the units to Fahrenheit in some places, …). But I think that would be a great candidate for a developer to take, polish and promote to an official status, so Plasma offers one.

        > Ah yeah with the ported kdepim stack we can enable that code now. I’ll try to ping someone about it.

        I assume that a couple of distributions won’t update to KDEPIM that quickly as various applications depending on it aren’t ported to KF5 yet, so you have to decide to either ship an updated PIM stack and remove a couple of applications or stay with a fully working PIM stack, all applications but no plasma integration. That’s what I wanted to point out with halfway ported apps / dependencies.

        Thanks for the feedback so far.
        (Due to a lack of preview button I’m looking forward to broken quotes, apologies in advance for that)

        1. But I think that would be a great candidate for a developer to take, polish and promote to an official status, so Plasma offers one.

          Well best would be to port the weather plasmoid. But it’s a beast and the developer doesn’t contribute any more. So it’s in the “needs maintainer” state unfortunately.

          I assume that a couple of distributions won’t update to KDEPIM that quickly as various applications depending on it aren’t ported to KF5 yet, so you have to decide to either ship an updated PIM stack and remove a couple of applications or stay with a fully working PIM stack, all applications but no plasma integration.

          As it’s just a library and they should be co-installable: hopefully that will work out.

    2. bah, I need an edit button …

      KF5: meant was the KF5 version of ktp, sorry for that.

      And yes: all of these bugs actually are reported 🙂
      (some have a WONTFIX, some are unconfirmed, some are confirmed and we are waiting for a fix, I guess)

  6. I understand that not everything can be achieved at once, but droping support for multiple virtual desktops will make KDE5 unusable for me. Makes me feel sad as a long-time KDE user….

    1. We did not drop support for multiple virtual desktops. It’s all still available. Only different wallpapers and different applets per virtual desktop are no longer available.

      1. > Only different wallpapers and different applets per virtual desktop are no longer available.

        Which for most user means abandon to the virtual desktop and this is to push the activities. Why not but in this case there are some adjustment to make like having an option to get the activities visible when going in a corner of the screen (only virtual desktop available), having a possibility to see all the activities as a grid, having shortcut available to move from one avtivities to another very fast. In this case that will be more or less the same things than the virtual desktop just a change of name. If this is implemented I am pretty sure that most of the critics will go away. Obviously there are also the dashboard wich is still here for no real reason since there are no posibility to get different widget on it. The solution will be to attach it to an activities and modify the shortcut and the corner to show the “dashboard activity”.
        There are

        1. Which for most user means abandon to the virtual desktop and this is to push the activities.

          Please don’t speak for “most users”. If you mean yourself, talk of yourself. Neither I nor you know all users. Speaking for myself: I don’t use activities, I use virtual desktops (normally 4), I never put different widgets or different wallpapers on different virtual desktops. So no, I don’t fully believe into what you wrote.

      2. I used to have different applets based on different task done on different desktop, right now I just removed all applets as I cannot fit them on one desktop. I have only clock, cpu and memory monitor applet. For me is this current applet implementation on desktop without ability to select different applets for different desktops totaly uselless.
        It won’t stop me from using Plasma5 but it will stop me from using any applet at all.

        Also Clipboard history is probably usefull for some. Current UI is nice if you have 20 elements configured but try it with 1000. UI is vasting the space and slider or search is slow.

        Anyway I realy apreciate all the work done on Plasma5 and hope it will evolve into the best Desktop interface in the near feature.

      3. That’s good news. I was not able to find the pager to in the widget list, but I didn’t look to hard and maybe I need to check again…

  7. Biggest problem for me in Fedora 22 and now 23 is kwin_x11 locks up X each time and the stack trace I get is garbage its so unstable I have to use mutter for a window manager 🙁

    Really not good

  8. “One of the most severe issues we hit with Plasma 5 is an issue with the Intel graphics drivers. I think that this problem is the reason why people complain about instability of Plasma. The only reason.”

    I’m using AMD Radeon and have been plagued by freezes. Having the enter: killall plasmashell; plasmashell continually throughout the day gets old after awhile. This has been going on since May… I read posts where people have Nvidia are also experiencing issues. I’ve provided numerous backtraces… so far the only response has been crickets.

    It is quite a coincidence that all three major drivers, Intel, Nvidia and AMD have issues with Plasma – at the same time, especially that in my case I have no problems with Gnome3, Plasma4 or LXQt using Kwin. Is this a surprise to the Plasma team? It appears you only believe there was “only” a problem with Intel. That is not true.

    I also get the fact that there are many moving parts to this, and issues that people report may be caused by things outside the purview of Plasma5. However, there is an old saying…. Perception is reality. Your customers see only one thing… before Plasma5, it worked… after Plasma5 not so much. If there are indeed driver issues which only appear with Plasma5 it would behoove you to work closely with the driver folks to track these down and get them resolved in short order. It is giving Plasma5 a black eye; deserved or not.

    1. Do you have me a link to those backtraces?

      It is quite a coincidence that all three major drivers, Intel, Nvidia and AMD have issues with Plasma

      Yes, because the issues are normally in different areas. I’m actually only aware of the Intel issue I mentioned in my blog post.

      Please note that this is all quite complex and in many cases there is not really an issue but rather a misconfiguration (you won’t believe how often users “optimize” KWin compositor settings and have a broken system afterwards).

        1. Thanks. Difficult to track, though. There seem to be multiple different issues mixed in. The root one seems to be that DRI3 was enabled again. Which IMHO is just not ready yet.

          1. Do you have any suggestions on next steps I should take to getting this resolved. I have provided backtraces as requested but as you can see from the bug report nothing is happening as far as I can tell. This is why I have moved on to LXQt…. and this is why people get frustrated.

            1. I’m not sure. Given that the bug report contains multiple issues I’m not able to get anything from it. I think the issues need to be reported in dedicated bug reports. And also the KDE ones need to go to KDE’s bugtracker.

              1. Sigh… I was the reporter with a single issue… The other stuff was added. I’ll go in and tell the other folks who are having another issue to open new reports. I will also duplicate in KDE bugzilla. Thanks for the feedback.

                1. Thanks. The problem with multiple reports sometimes happens 🙁 My suggestion is to clone the bug then for the various issues and close the original one. Sucks, but well…

  9. I have to agree with Christian’s conclusion: stable enough for a private desktop, not usable for corporate stuff (yet).

    I used my private laptop on which I upgraded to Kubuntu 15.04 in a meeting and plugging in a beamer killed my desktop.

    I’m not skilled enough in kde-related things to just quickly restart a component (plasmashell? kscreen? no idea), so I had to restart and endure an awkward 2 minutes before starting my presentation. (I was an intern at that time, thus I had no better prepared system than my private laptop)

    Thanks for all the hard work anyway KDE devs!
    I’m looking forward to when KDE5 will be as rock-solid as the last releases of both 3.x and 4.x series 🙂

    PS: There is a typo in “[…] I hope *a*ll distributions applied it.”
    PPS: I know that the notation of ‘KDE5’ might not be appropriate anymore. But for a user that does not follow development too closely all these parts are just ‘the KDE desktop’ 🙂

    1. I have to agree with Christian’s conclusion: stable enough for a private desktop, not usable for corporate stuff (yet).

      Sure, I think nobody would suggest to use it on corporate yet. That’s what 4.11 is for.

      I used my private laptop on which I upgraded to Kubuntu 15.04 in a meeting and plugging in a beamer killed my desktop.

      Sorry about that.

  10. Let me explain why your user base is so mad with KDE.

    “but means it’s only about 3.5 per day”

    What that means is that only a small number of people still care (or know how to) about reporting again and again and again and again all the bugs KDE has. Nothing more, nothing less. Pulling numbers from thin air is completely useless.

    But ok, let’s keep playing with the numbers you pulled.

    “Of those 1313 crash reports 127 are still unconfirmed (we need to improve here!) and 23 confirmed.”

    Oh, so, in 365 days you managed to confirm the astonishing number of 23 bugs? WOW. That is super amazing! We’ll get to the end of the pile of bugs in only 50 more Randa meetings!

    Graphics drivers:

    Not really sure how/where you code, but KDE works bad on pretty much any (proprietary) driver. Call it Nvidia, call it AMD. The (only) Intel driver sucks too. Nouveau sucks for a lot of cards. Haven’t even tested AMD open source drivers. So… where do you test your software? Is there some holy combination of hardware that all KDE devs use to develop or is the work done in VMs? Because, really, I haven’t been able to use KDE 5.x without graphical glitches. Ever.

    Multi screen:

    Oh… I’m not really sure where to start here. Multi screen has been so broken I can’t even say it can be fixed. I remember 5.1 launch when I decided to “give KDE a try”. What a bad decision. Had to open ~15 issues (yeah, search for them, my reporter email is alexandernst at gmail dot com) in a day, which makes me think either none of the KDE devs has multi screen setup (wtf!) or nobody cared to test/patch the bugs. And we are talking about the “moving a panel crashes X” (https://bugs.kde.org/show_bug.cgi?id=343406) type of bugs. There just can’t be an excuse for such a bad/silly bug. Those type of bugs just prove that there is not even something remotely similar to a QA testing.

    “But 5.1 is really old by now”. Sure, but problems are still there. And, quoting “As it stands there seem to still be crash cases in Qt 5.6”. So, it’s already been 2.5 years since first KDE/Qt 5.x release, and there is still no proper multi screen support? Do I need to go further on this?

    Legacy systray:

    “We did evaluate the situation prior to the release and saw that it was possible to do this step without loss of functionality.”

    You (KDE devs), by all means, did not evaluate nothing. Did you actually think about how hard (or impossible) would it be to make all the software switch to your new shiny systray thingy? Do you actually considered Steam or Dropbox, Skype, all the Java software, etc etc etc? No, you didn’t, because if you had, you wouldn’t have removed the damn thing.

    5.0 was release without legacy systray support and the entire internet shouted “Please bring back legacy systray”. And the one and only thing I could read from KDE devs was how hard it would be to bring it back, and how much refactoring that would mean, and how crappy the legacy systray is. Well, guess what, crappy or not, you can’t just remove it. The same way you can’t just remove X support (even if it’s the crappiest thing ever). And it wasn’t until 20 days ago (so, more than 2 years after the first KDE 5. release)(http://blog.davidedmundson.co.uk/blog/xembed_back) that somebody took care about bringing that back. More than 2 years for you to understand that what you removed was actually something that quite some people relied on.

    You just don’t test enough. As simple as that. Take a random Nvidia card, take a random AMD card, test your software on those two. I assure you you’ll remove 90% of all the bugs that get reported. The other 10% is, as you say, caused by new drivers that you just can’t test when you release.

    Bottom line: you can pull all the numbers from your bugzilla you want, but the fact is that KDE 5.x is just not polished/tested.
    Be honest with yourself. Take the latest image and install it on your desktop. Try it for a few hours and look what it looks like once it has been shipped by a distro, because that is what end users use.

    1. Oh, so, in 365 days you managed to confirm the astonishing number of 23 bugs?

      Ehm no, you completely misunderstood the number. It means that those 23 are the confirmed and open bugs. All other bugs are properly triaged and fixed.

    2. So… where do you test your software? Is there some holy combination of hardware that all KDE devs use to develop or is the work done in VMs?

      We have a quite diverse usage of GPU and driver. I use two Intel systems (never hit the mentioned problem, though), I know devs using NVIDIA. I think we have a good mix and yeah it looks like we don’t hit those issues. Sorry that you hit them.

      And we are talking about the “moving a panel crashes X” (https://bugs.kde.org/show_bug.cgi?id=343406) type of bugs.

      Why is it our fault if the X server crashes? Each X server crash is a possible root privilege problem. If you hit those, please pretty please report immediately to X security mailing list.

      You (KDE devs), by all means, did not evaluate nothing. Did you actually think about how hard (or impossible) would it be to make all the software switch to your new shiny systray thingy? Do you actually considered Steam or Dropbox, Skype, all the Java software, etc etc etc? No, you didn’t, because if you had, you wouldn’t have removed the damn thing.

      Of course we evaluated. Saying anything else is just wrong and an insult against my work on it. I spent days evaluating the situation and looking at what works. Skype is the primary example for things that work quite fine.

      1. Martin, the average user is not a developer or a distribution maintainer. They don’t know where the bugs are coming from they just see the Plasma desktop behaving badly. I have had composting issues with most desktop environments for at least 5 years with 4 different laptops. I loaded KDE via livecd and VM a few times over the 4.X series on multiple laptops I’ve owned. Mostly just to see how things are progressing and to have a look around. I must admit I don’t usually report most bugs because most of the time I don’t really know the cause.
        Now back to Linux developers and the distribution maintainers who claimed that compositing desktops were fit for everyone. Maybe you need slow down a bit and view things as a little more long term. Because, I suspect that many of the users who are now using a different one of the 13 and counting desktop environments for Linux were your users who at some point have jumped ship.
        Developers need to learn that their old releases even more than one version back may need to stay in service for a longer time that initially expected. You might also consider marking your newer versions as unfit for LTS and corporate use and making sure that everyone understands that…

        I ended up sticking with Mate and until very recently (The last year or two) I never even enabled desktop window shadows or any other kind of compositing effects they used to cause too many issues. Now basic compositing works for me woot! If it’s video driver support for Linux then let me tell you it sucks! At least on the hardware I have used.
        On the other hand I have every thing I need from my computer with the older desktops so I have been happy : )

    4. >>”…you can pull all the numbers from your bugzilla you want…”

      The vast majority of users don’t know what a “bugzilla” is. Of those who do know, they first need to deal with the developer-only presentation and atmosphere that afflicts bugzillas and get over the intimidation and confusion they likely feel there.

      So, all in all, non-developers who post to bugzillas can’t be taken as a representative sampling of users or of the problems users have. Users do not, and should not reasonably be expected to, feel any obligation to report bugs if it means they need to locate a specific bug reporting site, create an account, and try to figure out procedures and language clearly targeting developers.

      Something else: The frequency of releases and the numbering scheme used seems geared to produce false confidence in users. Some savvy users will look at a dot-zero release, e.g., 5.0, and stay away, figuring it will be awash with bugs. But, by the time the fourth and fifth releases are out there, e.g., 5.4., 5.5., etc., users will certainly expect that the bugs are gone.

      Distribution integration mishaps certainly drives some problems. It’s unreasonable, though, to expect distributions not to mix “old” packages with “new” packages so long as the “new” is feature incomplete.

      In particular, the need to ship two Kwallet versions is there because yet-to-be-ported apps require the presence of the old version. That’s not so much distro screwup as it is KDE creating a scenario bound to go wrong.

      (I would rant here about the failure of KDE, not distros, to package and explain this appropriately to users, but there’s already about a decade’s worth of KWallet ranting available via Google. KWallet is, I am sure, the single most common reason users walk away from KDE. I am surprised it was not completely replaced.)

      1. I’ll add that when I see the same miscues happen across different distros, I’m not likely to blame the packagers.

        A stupid case in point: Launch KMail for the first time and the Account Wizard pops up but it is hidden behind the KMail window. No reason for the user to know it is there.

  11. One of your first sub-headings is “the chain breaks at the weakest link”. I agree, though I consider the whole KDE project to be the chain and the multitude of problems and bugs and missing features in KF5 to be the weak links. Even if Plasma and system-settings were 100% bug free it wouldn’t matter that much to a user if the rest of the applications continue to have problems that severel impact their workflow.

    For me the things that are really a step back from KDE 4 are minor issues that impact my productivity as they affect features I’ve used daily in KDE 4 and for which I now need workarounds. For example:

    1) The key combination Ctrl+Space wasn’t working in konsole (reported, fixed since), and Alt+Ctrl+Space isn’t working either (reported, not fixed yet). Both combinations are often used by Emacs users, especially the former one.

    2) The split of wallets. Some apps use the KDE 4 wallet, some use the KDE 5 wallet. Yes, there was a migration but figuring out which app was using which wallet was interesting, so say the lest. It gets worse by walletmanager only being able to manage one type of wallet (either the KDE 4 or the KDE 5 one). While I’m glad it’s finally been ported to KDE 5 (sorry, KF5 probably, I still find the nomeclature highly confusing) it’s a major PITA if one of your passwords change and you cannot update one of the wallets. Yes, Chromium is still using KDE 4’s wallet for example.

    3) kcalculator used to work in KF5, but suddenly it stopped reacting to keyboard accelerators that require shift to be pressend (e.g. * or +). Yes, there’s an open bug for it.

    4) The calendar widget/app/whatever doesn’t show week numbers anymore. This is highly when scheduling meetings, I have to use external calendar tools now. of course there’s an open bug for it.

    5) The system tray change was completely ridiculous. I only found out about that part from one of your development blog posts and figured out where to get the tray libraries. And I’d ask for some more respect for distributions whose policy it is to ship upstream software unmodified if at all possible because each and every change/path at the distribution level requires work and is a source for even more bugs. Why couldn’t KDE/KF5 ship with those tray compatiblity libraries included? First provide a working setup for users out of the box, then deprecate the old interfaces, and after enough time has gone by remove the compatibility layer. But no, you made a hard brake causing a lot of people (both distributors and end users) to scramble for solutions.

    6) In the latest versions the desktop fades to black during login after the loading animation has finished and stays that way for a while. After a minute or so Plasma is loaded normally. From time to time, though, my second screen stays black and won’t change at all at that point (it was showing the loading animation earlier). Logging out and back in again usually solves this. Needless to say neither of the two issues were happening a mere month ago.

    So for me this transition to KF5 is another one in a long history of KDE’s major transitions; I dread each and every one of them because each seems to disrupt my work flow a lot.

    I’ve been a KDE user since 1.x and will probably stay one, so you haven’t lost me yet, but I can understand people being fed up enough to leave.

    1. 4) The calendar widget/app/whatever doesn’t show week numbers anymore. This is highly when scheduling meetings, I have to use external calendar tools now. of course there’s an open bug for it.

      This is now provided as a config option.

      First provide a working setup for users out of the box, then deprecate the old interfaces, and after enough time has gone by remove the compatibility layer

      May I ask what you consider as “enough time”, because we waited several years.

      1. I assume you mean that the new systray functionality/API had been present in KDE 4 for a couple of years already? Fair enough, I wasn’t aware of that.

        However, looking at how many applications hadn’t been using the new protocol/API I do still think that removing it was too early. For me that change affected Psi+, Skype, AeroFS and some Java applications. Pretty much everything but KDE/KF. Not a nice experience at all for your users, even if you feel that you as the developers were in the right and had waited long enough.

        Please realize that we users are the ones suffering while not being able to do anything about it. You as the framework developers say “we’ve waited long enough, the other developers had enough warning, deadline’s past, tough luck”. The app developers who should have reacted haven’t, for whatever reason, e.g. they haven’t even heard of such a change. Doesn’t matter. The user only sees that with a new KF5 his/her applications aren’t working correctly anymore, and we’re left completely alone with this. Having to Google for the symptoms and then stumbling about blog posts describing upcoming changes in the development versions of the KF libraries doesn’t count as informing your users.

        What might have worked better? Not sure. Maybe some kind of detection whether or not a program is using those deprecated interface and presenting some nice information to the user: “hey, app XYZ is using an old interface for the system tray that we don’t support anymore. Please visit website ABC in order to learn more about this and what you can do to rectify the situation.”

        1. There was no reason why Skype didn’t work. It works perfectly fine in Ubuntu through sni-qt. All distributions would have been able to get that. We informed them more than three months prior to the Plasma 5.0 release. It would have been possible to set this up correctly!

          I mean what should we have done? We told the distros: here are the patches, you need those to make skype work. They failed. What should we have done? I really am out of ideas. I didn’t think that this would fail, if we tell them. Yes that are our users, but it’s also the distros users. I would expect that distros also want the best experience for their users.

          1. We cannot install 32-bit sni-qt by default on our 64-bit distributions because that drags in huge parts of the multilib universe, and many of us distributors ship pure 64-bit by default.

              1. Yes, but Skype is a third-party program that we do not ship or support, so it is up to the user to install its dependencies. (Technically, the upstream RPM should require sni-qt%{?_isa}, but I doubt it ever will, so users will always have to install it manually.)

                1. That’s nonsense. It’s one of the most important applications for our users. Distros should make sure that it gets the dependencies pulled in correctly. And I don’t care whether or not your dependency system is able to do that.

      2. You waited several years without providing a working setup for users. Just a “try those random libs that we think might work, but no promises”.

  12. I was installing Kubuntu 15.04 for a friend at the weekend. Previously had some bad experiences, so this time I installed 5.4.2 from backports and rebooted before doing anything else.

    – Crash (of plasma-desktop) when dragging applications to the panel.
    – Crash (of systemsettings) when removing user icon.
    – Crash (of drkonqui) when interacting with report of the above.
    – Disappearing entries in the desktop effects list.
    – Lockup of systemsettings shortly after the above.
    – Strange problems when changing desktop theme (transparent panels, wrong fonts and taskbar-entry borders).
    – Flickering with any backend but xrender (both fglrx and radeonsi).

    I’m sorry, but three different crash bugs on a brand-new installation, when performing trivial configuration, isn’t a stable, usable desktop. Clearly it’s offputting when it happens to non-tech-savvy users, so I’ll have to pick a different desktop for friends/relatives for now.

    Hopefully it’ll come out like KDE4, where by 4.8 or thereabouts it really was a stable and polished desktop and by farthe best choice out there. I was just hoping that this time around that point would have been reached sooner.

    1. Complain to the maintainer of the Kubuntu backport repository for not testing his software. If you want stable software, just don’t use this kind of repository, use Kubuntu LTS. Anyway, Martin and other KDE developers are not responsible for anything there…

    2. Kubuntu 15.10 Beta (with installed updates) is more stable than 15.04 for a month or (because of newer KDE Frameworks, Qt, Mesa, etc.) Only if you would know about this, your experience would be better, but you doesn’t know (that okay too 🙂
      So, due to bug in fglrx https://phoronix.com/scan.php?page=news_item&px=Ubuntu-15.10-4.2-Cat-Not-Ready I recommend remove fglrx, stick with radeonsi, and then upgrade system to 15.10, it will be released in next two days.

  13. Thanks Martin. Keep up the good work. I just want to let you know I appreciate it; I hope you’re able to deal with this without getting too burned out. I depend on a daily basis on all your hard work. Thank you.

  14. Martin, while your arguments are all valid (I’ve done UIs, I know how we can get blamed for everything), I think that’s not the right thing to do to address complaints.
    The real question here is: is Gnome/Xfce/whatever more stable on the same software stacks? Because if they aren’t, then it’s obviously not a KDE problem. Of course, that’s not easy to do when different DEs don’t all have the same features and on top of that one may equate lower number of bugs reported to lower usage overall.

    In the end, the fact remains that many things don’t always work as you’d expect them to. So users coming from Windows or OS X will look down on the UX. At least Win10 has managed to break a few things on that desktop, too when upgrading from Win7, so now I have some level of feature parity 😉

    Last, but not least, thank you and your team for your work. With all its bugs, KDE is still the only DE I’m comfortable with.

  15. I now suffer mostly from a crash coming from current QScreen becoming nullptr when the monitor is disabled. kwin, plasmashell, krunner .. all of them crash. I run git versions of KDE, as well as Qt 5.5. openSUSE devs say that Qt 5.6 may fix the QScreen problem but causes other problems. Qt devs on the other hand say that KDE uses the QScreen API in a wrong way. So how is it exactly?

    > Also, KDE developers should make sure not to 1) assume that QScreen* returned from any Qt function is guaranteed to be non-null 2) hold any QScreen pointers.

    https://bugreports.qt.io/browse/QTBUG-42985

    1. yeah I am aware of the comment by Qt devs. It’s fun given that all our bugtraces we have end in Qt internals. Anyway: if you have me a backtrace, please send it to me. I want to look at that problem and auto test it.

      1. Here is my backtrace but my issue was quickly closed and marked as RESOLVED DUPLICATE so you would never see it on your own
        https://bugs.kde.org/show_bug.cgi?id=353823

        On a side note, why are crashes in KDE caused by upstream bugs marked as resolved? Shouldn’t those be marked as resolved only after upstream is fixed? If they are marked as resolved users experiencing those issues will never find them!

        1. Because there is nothing for KDE to fix there, so bugs.kde.org is the wrong place to track them, and keeping them open would distract from the actual KDE bugs. UPSTREAM and DOWNSTREAM are just a nicer version of INVALID.

            1. That is a policy issue, not a tooling issue. Even if KDE were using GitHub (which would be a bad thing because it is proprietary), bugs in other components would still get closed.

          2. Actually you’re wrong. There is job to do which is work with upstream to resolve the issue. Issue that is open can help users track it as well.

    1. No serious project will use it because it’s not multiOS. As simple as that.
      On top of that, most serious projects (that need it) have a working tray already, so “why change it?” if it works*

      *everywhere except broken KDE5

  17. Also, thank you Martin for allowing to comment on your blog without WordPress account and without Facebook, I wanted to comment on other developers’ blogs but couldn’t.

    1. no, we release bug fixes together with new features every month. Just like Firefox and Chrome don’t do dedicated bug fix releases.

        1. Right, dedicated releases. Not every release is that. Just like Ubuntu has an LTS, just like Plasma just had an LTS with 4.11. Maybe at some point we see the need for that, at the moment we don’t.

  20. First, thank you Martin (and all KDE devs) for your work on KDE that I benefit from.

    I think it would be helpful to be slower to move to new major versions of KDE. It took a while for users to feel like KDE4 was stable and feature-ful enough to use and enjoy, and then the process starts over again with KDE5. I’m glad my distros (Mint and Slackware) are being slow to ship KDE5. Even though they still ship KDE4, though, KDE4 is only in maintenance mode and developers are putting a lot of time into KDE5 – so I’m not sure the extra polish that KDE4 could still use will ever happen.

    I would suggest slower, smaller, incremental changes, rather than large changes all at once. For example, for KDE6, migrate to Qt 6 without changing the UI at all. Porting to the new Qt version could be the only change, so users don’t have to lose any features, and they would hopefully face less bugs.

    Anyway, that’s my $.02 as a user – smaller, slower, more incremental changes instead of the massive changes that happened (and are happening) with KDE4 and KDE5.

    1. It’s funny because when KDE 4 shipped, it was more or less promised that KDE 4 was a one-time thing and that “KDE 5” would be as you propose. Sadly, that promise was either forgotten or deliberately ignored by the Plasma 5 developers.

  21. I have encountered so many problems with Plasma 5 on Fedora 22 on different pc’s that I don’t know where to to start. I encountered crashes and freezes after suspend, problems with dual screen setup, kdewallet which didn’t work, programs ignoring locale settings. In the end I moved back to Gnome which is as good as bug free for day to day usage on the same hardware. Its doesn’t matter to me what the cause is for the crash. As long as kde crashes on intel and gnome doesn’t on the same hardware kde is doing something wrong in my opinion.

    –

  22. My biggest gripe with Plasma 5 is probably concidered a bugfix.

    With KDE 4 I could have a qwerty keyboard layout and a dvorak layout. The Dvorak layout would effect only text entry, everything else would remain qwerty. This for me was KDE’s killer feature.
    Why?

    I prefer to type Dvorak and I use a lot of productivity apps. With most productivity applications the physical positions (and hence the ergonomics of performing an action) are way more important than the mnemonics. With KDE I could get by without constantly having to switch keyboard maps.

    I have submitted a bug report many months ago but not heard anything back. I suspect this has to do with changes in Qt and would like to know who I should light a fire under. I liked having my cake and eating it too dammit.

    1. I don’t get what you mean with “everything else would remain querty”? What UI elements do you mean?

      2. Mostly keyboard shortcuts.

        Undo remains CTRL + the left most non modifier key on the bottom row, Cut remains CTRL + the key to the right of that, Copy CTRL + the key to the right of that etc.

        This is particularly important for applications that are driven by one hand on keyboard and one hand on the mouse or a tablet like Krita. One either ends up with a much less ergonomic way of doing things or switching layouts everytime one wants to enter text.

        Remapping the keys indidually is a complete pain in the backside, and makes the application unusable if say a coworker wants to use my machine.

        1. That’s in application shortcuts only? What about global shortcuts, e.g. Alt+Tab to switch windows? I’m asking because I want to know whether it’s a problem in Qt or in KGlobalAccel.

          1. Global shortcuts also stay with the qwerty layout in KDE4. basically the only thing that actually switches to dvorak (in my case) is text entry.

            I suspect the change is in Qt as Qt 4 applications still show the old (desirable) behaviour.

            1. What about global shortcuts in Plasma 5?

              I suspect the change is in Qt as Qt 4 applications still show the old (desirable) behaviour.

              yeah, that’s a very strong indication that it’s in Qt. And also I get a feeling that your right with the initial statement that this is actually a wanted bug fix.

              1. It might appear that way at first glance however I challenge you to actually use a desktop productivity app (KF5 based Krita for example) using the keyboard in a dvorak layout.
                Even using kate or dolphin is considerably more painful.

                The physical position of the keys is way more important than the mnemonics, for anybody who is more than a casual user of an application.

                The old behavior is extremely desirable for a subset of users. For this reason I am way more productive in KDE4 than I am in any other desktop environment by a significant amount.

                Fortunately my main productivity app (Blender) behaves the way I want it to.

                1. I don’t think that dvorak layout was the use case considered here. But rather people switching between qwerty and qwertz or the french layout. For them I think it makes much more sense to have an application consistent layout.

                  It’s a corner case. I’m not sure what I should think about it. I see and understand your thoughts, on the other hand I think it’s obvious that it should be the way it is now. I doubt that both can be supported at the same time.

                  1. Looking at the Qwertz layout I don’t think anybody in their right mind is going to prefer reaching across to the keyboard to undo an action. (again what is the link between undo and the letter Z? the point of having that particular shortcut is that is really easy to excute with the left hand). The french Layout is less of a problem. Dvorak is just a really obvious case of how bad this can be.

                    The main thing I can think of that would make this seem less like a bug is when configuring layouts in KDE the ability to mark a layout as the one physically printed on the keyboard, shortcuts would then be displayed in terms of that layout.

                    1. You know: it took me 20 years to figure out why undo is Ctrl+Z. I only realized after switching to qwerty be default. For any German user it would be totally confusing to have to do Ctrl+Y. Yeah one can argue that it doesn’t make sense, but that’s what German users know. Blame Microsoft and Apple if you want 😉

                    2. Yeah I fully realize this is a case of doing it right or being wrong in the same way as everybody else is.

                      Thing is that KDE has been doing it right (mostly) without knowing it for most of the right for the best part of a decade.
                      I didn’t know that this was the right way of doing things until I started using KDE4 after a couple of days it became obvious. I don’t want to go back.

                      Ok so stepping back a bit.
                      What if we only care about this behaviour with multiple keyboard maps.
                      If you have both QWERTY and QWERTZ on the same desktop would it be reasonable to assume that you probably prefer to have the QWERTY shortcuts regardless of layout?

                    3. If you have both QWERTY and QWERTZ on the same desktop would it be reasonable to assume that you probably prefer to have the QWERTY shortcuts regardless of layout?

                      I think my blog post here is the wrong place to discuss this. This needs to be done in Qt as Qt is responsible for it.

                    4. But of course 🙂 What I really want to know is who I need to convince / where I can discuss it – bugs.kde.org apparently isn’t.

                    5. I’d say create a bug against Qt. From your position it’s a regression, so that means bug report in Qt.

  23. Even if I would have probably used a softer tone, all the issues reported by Alexander are exactly what I encountered from day 1 after getting Plasma 5 in Kubuntu 15.04. In the first 2 hours of use I opened something like 15 bugs in Kubuntu. One user, 2 hours of casual use, 15 bugs, when Plasma was already at 5.2/5.3. Even if the root cause of all this is elsewhere (drivers, qt, etc.), one cannot help wondering how could it be that, with the same drivers and qt, Plasma 4, Gnome, Unity, Cinnamon, all seem to work reasonably well.

    Apart from that consideration, from the post, it looks like most of the issues are caused by the distro, putting Plasma 5 together with components that are not the best match for it. But this cannot be completely the fault of distros, when, at least for distros such as Kubuntu, the choice of which version of Plasma to ship is substantially made by prominent KDE developers. If the Ubuntu base is not ready for Plasma 5, then why forcing Plasma 5 on it?

    One last note for the systray. Please accept that people use legacy software and depend on it. Accept that people at times use commercial software and depends on it. Accept that KDE and Gnome cannot provide the whole of the software that people will ever need. Acknowledge that Java exists. Accept the idea that there is software that will never be updated to use the new protocols and is still useful or even indispensable. This software does not need to run in the most perfect way, but needs to be usable. A widget capable of swallowing stalonetray would have been more than enough.

    1. when, at least for distros such as Kubuntu, the choice of which version of Plasma to ship is substantially made by prominent KDE developers.

      Kubuntu shipped with Plasma 5.2 although we released 5.3 days after. If I remember correctly many Plasma devs urged Kubuntu to ship with 5.3.

  24. I think it is quite early for KF5/Plasma5/… to be stable enough while Qt is not there yet: https://bugreports.qt.io/issues/?filter=17137

    The filter lists P1 (Critical) issues reported in the last 180 days for released Qt versions. There 125 issues matching that filter. If you just select Qt 5.4 and Qt5.5 (including RC, Beta, Alpha releases for that milestones) you get 117 reports. 102 for Qt 5.5.x.

    There are 390 unresolved P1 issues in Qt’s bugtracker. More than 1/4 of all P1 bugs are reported for Qt 5.5.

    And Kubuntu 15.10 will ship with Qt 5.4.2.

    1. I should make a correction: The numbers 125, 117 and 102 above are just the reports within the last 180 days. These numbers become 390, 215 and 114 if you remove the 180 days restriction.

      So, 114 out of 390 P1 issues are for Qt 5.5.x.

  25. As for stability, I have been getting (unreproducible) Plasma 5 crashes on an Arch Linux system with Mesa ATI drivers.

    But they’ve been very rare, and when it does happen Plasma quickly restarts itself and neatly restores everything like it was with all applications still running, which is pretty impressive.

    So, kudos to the devs.

    1. You said that KDE resources are limited, so why starting Plasma Mobile?

      Plasma Mobile and Plasma Desktop share a huge amount of code. The differences are minimal and Plasma Mobile helps the desktop: HighDPI and Wayland got a huge push due to the project. It’s not mutual exclusive and it’s not stealing development time from other products.

      1. Thanks for your reply, and another thing:
        you have a huge amount of applications to mantain, why don’t drop something?

        I mean konqueror should be discontinued.
        kleopatra and kgpg do almost the same things and maybe it’s better if they merge.
        Then we have dragonplayer, kmplayer, juk, amarok, kaffeine, kscd as a music player, we can’t mantain 6 music players, especially if there are already good Qt alternatives (like VLC for example).
        We are mantaining even superkaramba (!!).

        Last thing, is there a place where you devs discuss development? Or a wiki explaining future developments?
        I mean, maybe if you tell us before your intentions to drop xembed maybe someone could have told something about it, right?

        And last last thing :P. If you develop plasmashell on a specific version of Qt (say 5.4), why don’t you tell distros to use that specific version to ship with plasma?
        IMHO most bugs derives from bad coordination between KDE devs, Qt devs, distro mantainers, users and Intel/Nvidia/AMD.
        To me it’s time to fix that before fixing bugs.

        Btw I’m happy to see you open to users opinion, this is very important in open source projects, since users can be a huge help to boost projects.
        Maybe this should’ve been done earlier thought….

        1. none of the applications you list are maintained by Plasma. It’s not our (Plasma devs) job to decide what of those applications should be maintained.

          I mean, maybe if you tell us before your intentions to drop xembed maybe someone could have told something about it, right?

          Well of course I did communicate this through my blog several months prior to the 5.0 release. So yeah, we told people.

          If you develop plasmashell on a specific version of Qt (say 5.4), why don’t you tell distros to use that specific version to ship with plasma?

          That’s what we do, but it’s more difficult than it sounds. Normally we ask distros also what they can provide and only increase once distros tell us it’s no problem.

  27. Hi Martin,

    Thanks for all the hard work. Did not yet experience blocking issues at all, as openSUSE Thumbleweed user. Don’t get depressed by harsh feedback and keep up the good work!

    – One who knows how depressing negative voices are when the positive voices keep silent 😉

  28. “KDE .. got lots of praise for the state it is in. So how come that there is such a discrepancy between what we see and what our users see?”

    As for the praise for the state of Plasma 5.x, if it’s from the “Linux media”, then please take it with a grain of salt. I have long observed that most reviews of distros and desktops are very superficial. Most of these reviewers never get past a live CD or a quick peek in virtualbox. They never go into any great depth, and they hardly ever step on any toes. Everything’s usually sunshine and rainbows.

    I pretty much ignore any reviews from the “linux media” as they usually never align with reality.

    The bugs really show up when you actually try to use the software work, not when you’re admiring the desktop wallpaper.

    1. This blog post is about stability woes, so people who are happy are unlikely to comment. Well, I am one of those people. I installed Kubuntu 15.04 as soon as it came out, both for home desktop (Nvidia) and my work laptop (AMD). I am extremely satisfied with KDE Plasma 5 on both.

      Yes, there are problems when docking/undocking the laptop, or closing/opening the laptop screen with external monitor attached. I don’t do that often, doesn’t bother me.

      Yes, Plasma crashes one or two times a week. It also restores everything right away, so doesn’t bother me.

      I don’t use Skype or Drobox, so I haven’t noticed anything weird with the system tray, except that it seems more consistent now.

      Day to day use is fast and smooth. Everything looks great. Dolphin is still the best file manager around. I could go on, but I’m sure you get the point: it’s not just reviewers taking a live CD for a spin that are happy. For my use case, Plasma 5 is already very, very good.

      1. I think there are different kinds of users. Some, like you, are fine with software crashing periodically. Others want software that doesn’t crash.

        I would rather more focus be put on keeping software from crashing at all. I think it’d be nice to have a policy that says the software doesn’t ship with any known crashing bugs.

        1. If you are at home, it’s not a problem if it crashes. The problem is I can’t use Plasma5 on my business laptop and it’s the only I have 😉

          I love Plasma 5, Dolphin and all config options which other distros don’t have, but I can’t use Plasma if it crashes five times in 8 working hours.

          I will try it in a year again. And don’t foget to add ‘share’ tab in Dolphin.

  29. I agree that plasma 5 is in good quality, but I do run into the occasional crashes. The crashes themselves don’t cause much inconvenience thanks to the crash handler, but I feel sad that I am unable to report them due to the lack of debug symbols (they are not provided by Arch Linux). People (including I) have asked multiple times on the mailing list for the support of debug symbols, with no success. Judging from the bug tracker, quite a number of users using the newest version and reporting bugs are using Arch. I think it is unfortunate that KDE is missing out on crash reports from these users.

    1. Honest question as I thought about that: would you appreciate to not see the crash handler at all, but instead the software just auto-starts? I was wondering whether it makes sense to show DrKonqi on Arch given that there are no debug symbols.

      1. I actually thought about that recently, and I think that for core desktop processes (plasmashell, kwin, akonadi, & co.) it would be nice to auto-restart and put a notification that it crashed. For applications I’d still rather keep the DrKonqi, since:
        a) I do not necessarily want to restart the application, and
        b) I probably just lost my data and a DrKonqi dialog is harder to miss if it crashed when I was away from the computer.

      2. I’d rather see something telling me the software has crashed than just restarting without me knowing what’s going on.
        DrKonqi is still useful in informing me in crashes that happen repeatedly on a specific action, and I can report those manually (perhaps compile a version with symbols for reporting).

        Plasmashell already auto-restarts on crashes (and showing a crash dialogue).
        Kwin is still broken in this respect, it does not auto-restart or display a window informing of the crash. The whole system just sort of hangs (I have to use my console shortcut to open a shell to restart kwin). I’ve filed a bug report (#353030), but so far no response.

    2. Actually they have been working on debug symbols. According to https://bbs.archlinux.org/viewtopic.php?id=199267 only two things are missing:
      “1) devtools: alter to build debug packages by default and sign/upload them to our server with the other packages
      2) dbscripts: recognise a debug package and add it to the foo-debug repo when the main package is being added to foo.”

      Well, i have no clue about bash so if anyone is up to the task go ahead please. 🙂

  30. What features is missing in KHotkeys? For me, i never see keyboard + mouse button – this most valuable feature about me. It is possible? Any limitations, if it possible please write to, i will start to implement it. I’m not very familiar wit Qt and KDE, if can make done it.

  31. First of all, I’d like to say thanks to all KDE team members for putting so much great effort on it to create the best DE in my opinion.

    Having said that, please don’t get me wrong when reading my criticisms. I understand how open-source works, and that’s fine when things go wrong. I understand even though I may get mad because I have work to do and the latest dist-upgraded forced me to change my entire overflow. I’m not a customer, so, even though I may complain, I understand I don’t have any rights 🙂

    I’m mostly bothered by the approach taken in this article to justify all the hassle caused by Plasma 5, and worse, pretending such hassle didn’t exist but were actually small glitches.

    That’s not true, and, indeed, the lack of full support to tray icons, when several applications still use the old system, is the one affecting basically all users, including me. I learned here that I could install sni-qt:i386 to fix the Skype issue, but there are other 3 icons in my alternative trayer application. I have two instances of Thunderbird with an extension to minimize to the tray and it won’t work in Plasma 5.

    The other application not showing up in KDE systray is actually only required because Plasma 5 removed a feature I used everyday, all the time: mouse gestures support. I had to install easystroke, which is not in the Debian repository and doesn’t work as great as gestures used to work in KDE 4. It was really sad news to me when I learned its support has been dropped 🙁

    As you can see, you noticed tons of reports from sad users. Enough reports to see that there *was* a problem, and they were not minor ones. Most users seemed to be upset by upgrading to Plasma 5. In the early days I had to switch to XFCE because I couldn’t use KDE at all.

    That’s okay if it was too much work for you to perform a great transition, typical from what we would have seen if we were paid customers of some company’s product. What is not fine is the justifications for this. I’d certainly prefer to hear the honest explanation: “sorry, but we preferred to make the transition easier for our developers rather than easier for our user’s base”. And that’s fine, I completely understand that, and it would be an honest response.

    Now, it’s not right to put the blame on distributions because they decided not to patch Qt. I wouldn’t like to have Qt patched too if I were writing Qt applications. When creating a Rails application, I won’t fork Rails, apply my patches and use it in my project to fit my needs. I’ll try to work with Rails team instead to get the fix merged in the main code, or if it’s not possible, or if I can’t wait for this, I’ll try to look for other approaches that doesn’t involve changing Rails.

    I don’t think it’s fine for KDE to rely on some patched Qt to work, but, of course, this is my opinion. I just think that, regardless of you agreeing or not, you should respect those that think this way, including distributions policies. You can’t blame them because they do not agree with your policy and will adopt theirs instead. This is the bit I didn’t like in this article.

    I find you amazing in working hard in KDE and Plasma so that we can enjoy it, but it’s fine to accept that there were problems in the process of upgrading from KDE 4 and to accept that lots of those problems are not anyone else fault, but the blame is on the KDE team. I’m not saying people will be mad on the KDE team, they understand that there are too many changes for a small team to be able to manage in a perfect fashion. But pretending it’s someone else fault is not correct either.

    I hope you understand I have no intention on bashing on you or on the KDE’s team and that I do respect you a lot and I’m really grateful for all your work. All I said here is about the posture adopted in this article, not about KDE development approach itself.

    Thanks again for your wonderful work!

    Kind regards,
    Rodrigo.

    1. Hey Rodrigo,

      > I have two instances of Thunderbird with an extension
      > to minimize to the tray and it won’t work in Plasma 5.

      What extension are you using for Thunderbird?

      I was using FireTray, and had problems. Upgrading to FireTray 0.6 fixed them, and it is working now quite well.

      Remark: FireTray 0.6 does not yet show up when searching for the extensions, but can be downloaded when listing all versions:

      https://addons.mozilla.org/en-US/thunderbird/addon/firetray/versions/

      regards, Wolfgang

  32. First I want to thank you for all the amazing work that all the dev are putting in KDE. This is my desktop for so many years now. I really love it. I will be honest and I will say that sometimes I am trying Gnome or Unity but I am always coming back to KDE because of the configuration choice.
    The main things that I reproaching to Plasma5 and KF5 is that, as it happen for KDE4, it is not possible to install it in parallel with the previous version. This is the real mistake. It happens one time and it is happening another time. This is the real reason why people are angry. You are forced to give away your well establish workflow for something different and with new bug and you cannot come back to the previous one. So what happen: angry and people going to stable things: Gnome or Unity and the consequence is that the user base is diminishing as well as the report of problem. This is the reason of the sudden discovery of “our user are not pleased”. I am sorry for that especially with all the good work done.

  33. I am very pleased with plasma 5. The skype issue needed 2 minutes to fix (i386 sni-qt package). The kaccounts/signon/telepathy stuff is the only part that really doesnt work. But hey, I am on OpenSuse and have either experimental repositories (work) or tumbleweed (laptop) so for me it is obvious that some things are not as mature as the current stable release of my distribution.
    I love the direction of plasma, I use activities a lot and dont need any virtual desktop – activity linking. The file – activity linking is great. I cant imagine another desktop environment. The skype issue is surely an issue to some users but this have to be fixed by the people building the skype package lik microsoft itself.
    And the distribution problems are just the way linux as an ecosystem works. If there is no central authority which controls the process you have to communicate and trust a lot. And if you are a linux user you have to deal with this things. Some things are perhaps preventable but I think we all have to help instead and not to rant.

    By the way: The new plasma api to write plasmoids really rocks. Its so readable and simple. The qml kconfig interface is also great. I love it!
    Plasma 5 is great and will be even better in the future

  34. First i think its good to see that QA and Bugs is a major topic within KDE!

    The most problems i currently have with debian sid is that kmail has lost the ability to open my kwallet. But well its debian “unstable” for a reason…

    The worst offender with bugs has been KMail and akonadi. The endless switches in indexers (which i never found out how to use properly) eat up CPU/battery and heat up the laptop.

    Another bad thing is that akonadi destroys old settings, so switching between different KDE versions has broken the older stuff quite often. It would be really nice if there would be more emphasis in downward compatibility.

    Besides the stability issues i must say that usability wise i see unfortunatly a lot of backward movements. For example by default all disks (even the statically mounted disks) are displayed not by their mount path (which has a meaning) but by there size in dolphin? WTF!?! It makes much sense to display usb sticks and alike but please also display some information like vendor and not the raw size which is confusing at best.

  35. Arch Linux has Qt 5.5 I’m sorry that users choose the “release” distributions. Though sometimes I empathize with that because I occasionally get hit with weird bugs, there is no good fix for the issue sadly. I personally think that rolling stable is the better model, though I sometimes think one should always way for the .1 release of those that do regular semantic releases.

  36. I am running Plasma 5 on my X200 (intel GMA something).
    Seems fine and snappy. I do get the occasional glitch but a dmesg shows the intel driver complaining about something or other. It’s still pretty stable for me. Doesn’t ever crash and it’s snappy as all get up.

    1. I must say that in general we don’t recommend nouveau yet. It might or it might not work. In general the proprietary driver gives better results.

  38. One has to consider that we are not “comparing” anymore to a Windows 95 or XP, but to Windows 7 / 10 or OS X El Capitan. Its not like Windows crashes every couple hours any more like it maybe used to. I believe users are much less forgiving regarding crashes as they used to be 10 years ago.

    The first time I installed Plasma5 the system was pretty much unusable because of screen flickering ( https://bugs.kde.org/show_bug.cgi?id=348302 ) .
    Apparently a problem of my gpu / gpu driver. I replaced the gpu, it was kind of dated anyway, and it’s much better now. But still there are so many papercuts, I would never recommend Plasma5 to someone who is not very tech savvy and has a high frustration tolerance.
    Session restore not working correctly, kwallets, problems with come core apps like ktp, kontact …

    Now off to restart Plasma 5, my third monitor didn’t wake up this morning 🙁
    This never happened till like a week ago. I just reported it as a https://bugs.kde.org/show_bug.cgi?id=354115 . I hope it’s not duplicated 🙂

  39. One has to consider that we are not “comparing” anymore to a Windows 95 or XP, but to Windows 7 / 10 or OS X El Capitan. Its not like Windows crashes every couple hours any more like it maybe used to. I believe users are much less forgiving regarding crashes then they used to be 10 years ago.

    The first time I installed Plasma5 the system was pretty much unusable because of screen flickering ( https://bugs.kde.org/show_bug.cgi?id=348302 ) .
    Apparently a problem of my gpu / gpu driver. I replaced the gpu, it was kind of dated anyway, and it’s much better now. But still there are so many papercuts, I would never recommend Plasma5 to someone who is not very tech savvy and has a high frustration tolerance.
    Session restore not working correctly, kwallets, problems with some core apps like ktp, kontact …

    Now of to restart Plasma 5, my third monitor didn’t wake up this morning 🙁
    This never happened till like a week ago.
    https://bugs.kde.org/show_bug.cgi?id=354115

    Before I forget it:
    Thx for all the work !!
    And every time I reported a kwin bug I had feedback in less then half a day 🙂

  40. I am an enthusiast KDE user for years. At the moment I am working on Ubuntu 14.04 LTS (KDE 4.13.3), with one nVidia GTX 960 driving 3 27″ monitors @ 2560×1440. It works like a charm and I love it.
    Looking forward to discover KDE 5 when Ubuntu 16.04 will be released.

    I could not miss the tweak-ability of KDE. It is great to be able to customize so much, that is what sets KDE apart for me.

    At work we also use multiple KDE desktops driving more than 1 monitor.

    Thanks 4 the great work Martin & KDE-colleagues !!

  41. Maybe it’s blasphemy to some folks, but maybe it would be a good idea to provide a fully KDE-built distribution of plasma and its applications with its own package manager? Just like with Chrome or Skype, I don’t care that much who built the software as long as I (relatively) trust the party who built it and as long as I get a stable user experience. If KDE5/Plasma was built by KDE devs it could ship just the right experience to the end user, binaries could have the right debug symbols (in separate files) and right compilation flags, a good matching Qt version and so on.

    Such release could simply assume certain GLIBC version. It should be perfectly doable to make it work on most modern Linux distributions in a cross-platform way. Think of like KDE for Windows is built …

    1. Yes, it would be blasphemy .. 😉

      Instead I would recommend you to go with one of the KDE-centric distros out there (like I do):
      http://chakraos.org/
      http://kaosx.us/
      come to my mind.

      They care (and only care) for the best KDE experience.

      However they have a (much) smaller team than your average distro (so you might not find your package for xyz there),but theay are all the way more enthusiastic. 🙂

  42. My two cents:

    1) Whenever I’ve had issues with kwin (not often), someone (often Mr Grässlin) has been quick to respond and at least find the cause of the issue. When I’ve reported issues with Plasma, responses have been slower coming and less helpful. So keep up the good work Martin!

    2) It may well be true that some of the issues with the KDE5 desktop have been caused by buggy drivers. Blame them if you like, but that is *not* an excuse for releasing your software as a “stable” release. Of course, the issue here is not KDE maintainers deciding to release, but users of distributions wanting to try the latest features and then wanting to go back. Still, it would be nice to be able to choose between KDE4 or KDE5, or between Plasma 1 and Plasma 5 on the same distribution.

    1. > Still, it would be nice to be able to choose between KDE4 or KDE5, or between Plasma 1 and Plasma 5

      We tried it in openSUSE. It’s a universe of pain, and causes issues to no end with packaging. In the end (with Plasma 5.3) we went with P5 as default.

      1. adding to that: from upstream side I think it would have been impossible. We have hundreds of binaries and much more plugins. For each we would have had to rename them and ensure that this actually works. And fighting regressions were dbus names or plugin names are hard coded from KDE 1 times (yes, such code exists).

  43. I am really amazed by the gentle and constructive attitude you Marting take the critism raised. This is the attitude of a real professional! Thanks for this state of mind. I am also amazed that, even many commentators seem to have a real reason for beeing upset, the thread is focused on the topic and no personal attacks are made. Seems like we all grow up. You hear other stories these days from the kernel mailing list.

    While I see most of the issued raised myself on an Arch box Intel with an i7 second generation graphics chip, KDE is still the best environment for me. To be honest, I am impressed day by day how well I can addapt KDE to my really specific needs, and kwin is an integral part of this.

    I hope, that some of the issues might get easier to get right once X11 is replaced by wayland.

  44. Hi Martin,

    Can Vulkan solve some of the problems/bugs related to the graphic drivers? I’ve read on your blog that you do not want to support Vulkan, not yet at least, but I wonder if maybe it will be worth it?
    Dajomu

    1. Let’s wait and see. I don’t believe in silver bullets and I don’t believe in Vulkan being one.

  45. Thank you for this overview of the situation. It is good that everything is down from 100+ daily reports to single digit numbers. I also know your position on Vulkan however I think many of the problems stem from the inconsistencies in GL implementations. GL has been around for 25 years and has grown more complex with the different vendors and implementations. Vulkan offers a new break which can allow for a constant lower level control and reliability across vendors.

    You previously were hesitant(I hope I am not misrepresenting your thoughts on this), claiming it was just another GL implementation you would have to target and it wouldn’t improve things much except for the spinning cube effects(which would need a rewrite). KWin has a long history like GL it has many options and features that reach back quite a while now. So what I am proposing is this, eventually port to Vulkan but not a full port just a minimal port and only to Wayland. No special effects and what not, and this should not show up in the desktop(except for a fall-back). Vulkan would only be used as a stable base for minimal setups (like plasma-mobile) or a fallback if things can’t work otherwise. The full effect stack would not have to be ported(unless other devs wish to do so). By having a lower level but stable branch you would control much of the pain points you currently have with OpenGL directly instead of the drivers so there would be less inconstancy. Kwin would have a stable reference point and a feature break where you won’t have to care about legacy or backwards compatibility(which should simplify things). I thank you for all the work you have done so far, and the time and thought you have put into the Wayland port. I am very hopeful that Vulkan like Wayland will improve things going forward in the long term.

    1. Given the history of OpenGL on Linux I don’t believe in any promise about Vulkan being stable, working across vendors and what not. I just don’t buy into the marketing bullshit. It’s the same people doing Vulkan, the same people who did the mess with OpenGL core profile and what not. Let them proof they can do better, than let’s evaluate Vulkan.

  46. Pingback: Martin Gräßlin antwortet auf Kritik an KDE Plasma 5 | ShaZenux

  47. Martin,

    Thanks for the discussion and concern. I personally think the long and short of the current situation is that distributions and every day users cannot now successfully move to KDE 5. I have been a KDE user for 15 years, and while I am able to muddle through missing components and erratic behavior, I am not inclined to spin this version onto critical machines– including my own day to day desktop– and I am personally glad that Debian didn’t bother with it in Jessie. I remember the pain of KDE 4, so the transition is nothing new although the magnitude of changes is greater. I don’t think you should expect most mainstream distributions to buy into the incremental sorting out of things that is going on with KDE right now– if you continue to sort out the system, there is plenty of time for distributions to pick up 5 with much less frustration than is currently possible.

    I can’t really see functional advantages to most of the changes yet, but I also realize that the current trend in desktops is much different than it has ever been before, so I will stick with KDE and adopt it for daily use when I don’t have to find clever solutions to simple problems. Thanks for the development effort, and please understand that most of your users don’t have time or inclination to fool with bug reports and workarounds.

    RL

  48. Maybe Plasma 6 on Linux should support Wayland and Vulkan only, since those new components have less superficial area that can hide corner case bugs..

    1. Then users will have to suffer the Wayland and Vulkan bugs/regressions in addition to the Plasma 6 ones (and the unfixed Plasma 5 and 4 ones, if any). Bad idea.

  49. It’s fantastic to see such openness from a developer. Thanks for sharing your concerns.

    I took this article as you feeling stuck in between a rock and a hard place, the frustration of working really hard and that effort going unappreciated and unused…by too many people. I can understand distros sticking to their principles of not patching, for them please don’t promote plasma until things have caught up.

    Plasma is awesome a day like many things, people want it now and they want it to work great, which it does for the record. I’m an arch user and have been using plasma since the start of the year (even though I know I shouldn’t have) as daily driver. It’s just so much better than anything else and (weird as it may read) that’s the problem.

    There are many cars which have major issues but people still buy them because there’s more to love than hate. Unlike cars however, this is open source and people (like the OP) built kde in their own time, we need to respect that MUCH more than we do, I’m looking at you media.

    Everyone’s a critic where they should be contributing. I really wish I had enough time to contribute more than the odd bug report myself but ultimately, thank you, thank you again and again for producing this epic product that helps me work productively (the bugs are simple to workaround) and in a beautiful environment.

    I took the time to read every comment and don’t think I’m alone with this opinion.

  50. Tangentially related, I have been trying to find if there is any recommended way to run the very newest release of Plasma/KF/KDE applications. Should I give up and compile everything myself, or is there some blessed reference distro out there with a known-working way to test the very latest?

    1. There are various distributions providing daily packages. E.g. Kubuntu and OpenSUSE. Probably more, I don’t know all of them 😉

Comments are closed.