Something funny happens when you take something that was super broken and you make it work a lot better: people start to use it more! And then they submit bug reports for all their unusual use cases that you failed to anticipate or that hadn’t been getting exercised in a long time. So in the short term it looks like things are worse, but in fact they’re better because the bug reports are becoming about more and more exotic use cases over time.
I saw this happen starting 2 years ago with the Plasma Wayland session (which has since become very robust), and now it’s happening again with multi-monitor setups. We finally nailed the basics, so people are trying it out again, abandoning their xrandr hackaround scripts, and submitting bug reports about the issues with their wild and wacky screen arrangements. 🙂 And this is great! So we spent a ton of time this week working on fixing all those edge case bugs to make our new multi-monitor system even more robust. With a strong foundation, fixing the bugs isn’t that hard!
And while the core Plasma team worked on those things, a lot of great work also was done by everyone else to add features and polish the user interface! So there’s lots to see this week:
New Features
Using the context menu item present in Dolphin and the desktop, you can now set an image to be the wallpaper for the lock screen too, or for both the desktop and the lock screen at the same time! (Julius Zint, Plasma 6.0. Link):
User Interface Improvements
Kate and KWrite now internally save their set of open documents shortly after they’re opened, so if either app crashes or gets killed due to memory pressure, you won’t lose your open documents when you re-open it anymore (Waqar Ahmed, Kate & KWrite 23.04. Link)
Okular now zooms smoothly rather than in steps when you Ctrl+scroll using a touchpad or a high-resolution scroll wheel (Friso Smit, Okular 23.04. Link)
When setting up a new Plasma system, apps that are pinned to the Task Manager by default in Plasma (Discover, System Settings, Dolphin, and a web browser) but not actually installed by default on the operating system you’re using will now simply be omitted, instead of remaining visible with a broken icon and doing nothing when clicked (Fushan Wen, Plasma 5.27.2. Link)
Welcome Center has received a visual overhaul to bring it more in line with other KDE apps, so now its interactive buttons appear in a footer and there are dots showing all pages and which page is active (Oliver Beard, Plasma 6.0. Link 1 and link 2):
Discover’s application page has received yet another visual overhaul, making better use of space, reducing redundancy, and looking better overall (me: Nate Graham, Plasma 6.0. Link):
System Settings’ Flatpak Permissions page now includes a search field for the apps list and a pretty header for the apps details pane (Ivan Tkachenko, Plasma 6.0. Link):
Significant Bugfixes
(This is a curated list of e.g. HI and VHI priority bugs, Wayland showstoppers, major regressions, etc.)
Fixed a recent regression that could cause Plasma to crash when waking up the system while using a multi-screen arrangement (Aleix Pol Gonzalez, Plasma 5.27.1. Link)
Found a better way to fix incorrect scaling in the Plasma Wayland session for XWayland-using Electron apps that does not result in any regressions, and also fixes scaling in Steam, too! (Luca Bacci and Fushan Wen, Plasma 5.27.1. Link 1 and Link 2)
Fixed a recent regression that caused line artifacts to appear around panels when using a fractional scale factor in the Plasma Wayland session (Arjen Hiemstra, Plasma 5.27.2. Link)
Fixed a case where KWin could crash in the Plasma Wayland session while a video was playing in VLC (Vlad Zahorodnii, Plasma 5.27.2. Link)
Fixed a case where KWin could crash while logging out of a Plasma Wayland session and leave you hanging (Vlad Zahorodnii, Plasma 5.27.2. Link)
When using the recently-released version 1.8.11 or later of the fwupd library, Discover will now always launch properly (Adam Williamson, Plasma 5.27.2. Link)
Fixed a recent regression that could cause powerdevil to crash with certain multi-screen arrangements, breaking power management (Aleix Pol Gonzalez, Plasma 5.27.2. Link)
Fixed a case where System Settings could crash while applying or reverting screen arrangement changes (Arjen Hiemstra, Plasma 5.27.2. Link)
Fixed a major recent regression in how Aurorae window decoration themes were drawn in the Plasma Wayland session (David Edmundson, Plasma 5.27.2. Link 1 and link 2)
Fixed a semi-recent regression in the Plasma Wayland session that allowed the cursor to briefly go 1 pixel beyond the screen on the bottom and right screen edges, somewhat breaking Fitts’ Law and causing hover-enabled UI elements on screen edges to flicker (Xaver Hugl, Plasma 5.27.2. Link)
Fixed an issue in the Plasma Wayland session where desktop size would be computed subtly incorrectly when using a fractional scale factor and cause various off-by-one-pixel visual and functional glitches all over the place (David Edmundson, Plasma 5.27.2. Link)
Discover no longer shows complete nonsense for most distro-repo-provided apps in the “Distributed by:” field on app pages (me: Nate Graham, Plasma 5.27.2. Link)
The semi-new QML version of the Present Windows effect now works properly with the keyboard when invoked in its mode that only shows the windows of a specific app, no longer allowing you to invisibly focus windows of other apps too (Vlad Zahorodnii, Plasma 5.27.2. Link)
When using a fractional scale factor in the Plasma Wayland session, the cursor is now rendered correctly in XWayland-using apps (Xaver Hugl, Plasma 5.27.2. Link)
Multi-screen arrangements consisting of screens from the same vendor that differ by only the last character of their serial numbers (imagine a large company buying monitors in bulk) will no longer get scrambled on login (David Redondo, Plasma 5.27.2. Link)
Fixed a semi-recent regression in the Plasma Wayland session that could cause the Baloo file indexer service to crash frequently (David Redondo, Frameworks 5.104. Link)
When getting new add-ons using the “Get New [Thing]” dialog, the sheet to let you choose which thing you want to get in case there’s more than one is now correctly scrollable in case it does not fit in the view (Ivan Tkachenko, Frameworks 5.104. Link)
Other bug-related information of interest:
- 16 Very high priority Plasma bugs (up from 12 last week). Current list of bugs
- 44 15-minute Plasma bugs (up from 43 last week). Current list of bugs
- 152 KDE bugs of all kinds fixed this week. Full list of bugs
Automation & Systematization
The tutorial for writing Kirigami apps has been rewritten for massively improved usefulness and helpfulness! (Thiago Sueto, Link)
The continuous integration systems for Gwenview and Kamoso now build the apps as Flatpaks for every change! (Neelaksh Singh, Link 1 and link 2)
Changes not in KDE that affect KDE
In the Plasma Wayland session, power management when using DisplayPort screens now works again for users of the Neon and Fedora KDE distros, which it turns out had not been building the KIdleTime library with its proper Wayland support enabled (Jonathan Riddell and Marc Deop i Argemí, right now! Link).
…Okay so technically Neon is in KDE, but it seemed more awkward to mention Neon separately elsewhere and Fedora KDE here, since both distros suffered from the same underlying issue that was causing the same user-facing bug, and both needed the same change to fix it.
…And everything else
This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.
How You Can Help
If you’re a user, upgrade to Plasma 5.27! If your distro doesn’t offer it and won’t anytime soon, consider switching to a different one that ships software closer to its developer’s schedules.
If you’re a developer, consider working on known Plasma 5.27 regressions! You might also want to check out our 15-Minute Bug Initiative. Working on these issues makes a big difference quickly!
Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
And finally, KDE can’t work without financial support, so consider making a donation today! This stuff ain’t cheap and KDE e.V. has ambitious hiring goals. We can’t meet them without your generous donations!
Adventures in Linux and KDE 
Sweet work all over the place once again. Regarding the Discover’s application page: I feel that a new user will always click on “install” without having any clue about what the function right next to it is for. This is a problem with flathub installs in general, the software centers just slab an option there and expects the user to know what flatpak is. Linux is overwhelming enough for the average Windows-Joe without the whole flatpak thingy, I swear most have never ever heard of it and can’t really wrap their heads around it either..or actually can’t wrap their heads around the fact that the OS is offering an old version of a program instead of a shiny new one with all the dependencies included. I propose this: Get rid of the function to the right where the user chooses flatpak/repo/snap/whatever, instead make the “install” button with a drop-down list where the user will actually have to choose and doesn’t automagically choose the distros repo version every time, more often than not resulting in installing an old version of the program without even realizing it.
LikeLiked by 1 person
I see why you want to force the user to have that kind of fine-grained decision making when they install an app, but from my experience of teaching non-technical people how to use a KDE Plasma setup, they really don’t understand the subtle differences between application channels. It’s too much to take in. Just getting them used to the idea that “everything is in Discover, look in there for whatever you want” is already a big step in their mind. I could see them panicking and freezing once they decided to install an app from what you’re suggesting because they would have to choose between menu items that mean nothing to them.
I notice that these users just want something that works. And for them in their unsophisticated usage, the installed application works so they’re happy.
I think the way it is is fine for the users that I have to train: simple by default, powerful when needed.
LikeLike
In general, I think Discover should prioritize Verified Official releases (as Flathub and I think Snap have verifications), then order by user-preferred defaults, and highlight which ones are the most updated.
It’s a very specific issue though and I think just prioritizing Flatpak in general is good enough for most users, especially as most of them are on SteamOS anyways.
LikeLike
The way to make this maximally user-friendly is to not have apps available from multiple sources to begin with. And on most systems, that’s the way it is by default: typically distros expect for users to get apps from distro repos or Flathub. So in general people with multi-source setups have configured it this way themselves and know what they’re doing.
Some exceptions are Ubuntu-based distros which offer distro apps as well as Snap apps, but IMO this is another reason to avoid Ubuntu-based distros today. Then there’s Neon which by default offers apps from both Flathub and Snap which IMO is just weird and I think they should ditch Snap once and for all.
LikeLike
@Michael
Fair enough, but when the user decides to uninstall the repo app and it possibly takes some dependencies with it, there’s a big problem. I don’t really want to “force” users to choose, I merely want them to have the options presented to them so they can make an educated decision. Ideally, the dropdown options would show clear (short) information as well: Option A: Great Program, version 2.1 (New, everything included) Option B: Great Program, version 1.5 (Old) I am quite sure that a new user that, as you say, just wants the installed application to work, will install the flatpak version. Blindly installing repo versions is just asking for trouble in the long run, in my opinion. Sure, the option should be there but absolutely not as default. Ever.
LikeLike
What Discover does has to be balanced with what distros want. If Discover starts being pushy and prioritizing Flatpaks of its own volition or trying to convince users not to install distro packages, then distro packagers will complain to us about it. If we don’t address it, they’ll patch out the code for it or stop shipping Discover entirely.
The issue of distro packages being ancient also isn’t an issue that affects all distros. On rolling release distros like Arch and openSUSE Tumbleweed, you get up-to-date apps. On Fedora, they’re mostly up to date. On these distros, Flathub isn’t as important and mostly serves as a way to get apps that aren’t packaged by the distro for policy reasons. We’re really only complaining about Debian and Ubuntu here, which intentionally ship old app versions. On those systems, the user can benefit from Flathub so they can get newer apps.
Ultimately I think the best solution here is for distros to stop packaging apps themselves and embrace getting them from Flathub. Some distros already do this, for example Neon, SteamOS, Kinoite, and MicroOS. This way, we have that desirable single app source for users, and we also reduce work for distro packagers so they can focus more on development of the distro itself and less on the crank-turning work or shipping app updates.
LikeLike
@Nate
Yeah, but rolling distros are not for new users. Being careful not to anger distros is not the way either. Speaking of which, Ubuntu and it’s derivatives just announced the very user-hostile decision to treat flatpak as garbage, so why kiss their behinds since they already made up their minds on what’s best for the users? Is it really offensive to distros for KDE to just make a dropdown list where to pick the preferred version? Really? Or is there some technical limitations to this..? KDE desperately needs a flagship distro that keeps up with the development and is also suitable for everyday use by average Joe. Canonical are clearly fighting this all the way, I’m not recommending Kubuntu to anyone anymore. KDE Neon is a loose cannon, Manjaro is a flaming carcrash, Fedora just decided that it’s very scary to provide media codecs etc etc.. What’s left for the Windows noob-people looking to switch? In my perfect dreamworld Zorin would ditch XFCE and switch to KDE, fingers crossed…their GNOME version is already stellar for new users. But yeah, we’ll see how all this pans out..We also need that super KDE distro if we are ever going to get computer manufacturers to mass produce affordable linux computers. Michael here earlier again played the “simple by default, powerful when needed”-card, but used it weirdly because it should be done in the same order it is written. Simple flatpak version by default. This, like you mentioned, would be best for everyone and distro maintainers wouldn’t have to care about a million apps in their repos either..yes, in a perfect world.. We still have quite a mountain to climb.
LikeLike
We have to be nice to distros if we want them to distribute our software, it’s pretty much as simple as that. There can be some give-and-take, but we can’t piss them off on purpose and not care.
Ultimately I want us to double down on our own distro more, and release a next-generation Neon that we can formally recommend as the reference “KDE OS”. Honestly I think Neon itself is close but it’s not quite there, and we need to work on that. It needs to be so good that distros *feel* the competition and get inspired to improve themselves!
LikeLike
When was it decided that a welcome dialog was a good thing again? These things are a terrible no matter what or where. Stuff should work out of the box. I didn’t even bother clicking on next when it popped up for me, and boi am I glad I did seeing that it has 8(!) pages for settings that should not matter??!
LikeLike
Love the bug fixes and improvements, hate the ‘tans.’ Please don’t let the manga cartoons infect any more of plasma. This stuff is an acquired taste and quite of-putting to those not into it.
Am I the only one for whom Wayland is unusably blurry no matter what settings I have if I activate scaling? I’m using AMD renoir onboard graphics.
LikeLike
“Terrible” is a subjective judgment, and the people that I train to use KDE Plasma systems for the first time appreciate these kinds of things–they’re leaving behind familiar Windows or Mac and they want to be reassured that this is going to be a friendly computing environment. They have no frames of reference for what they’re getting themselves into.
Since the window only appears once, and a technical user can kill in in a half-second, I see it being positive for the community we want to grow.
LikeLiked by 2 people
It might matter greatly to first-time newcomers. Historically typical KDE users likely do not need an initial explainer, but a non-techy switcher from Windows hopefully appreciates the pointers towards some important aspects of the new system. This should ease the sink-or-swim and hopefully remedies a bit of the initial uneasiness/unfamiliarty. Also, hopefully less initial googling of “How do I do …”. 🙂
LikeLiked by 2 people
I found it useful even for me as a long-time full-time user.
LikeLiked by 2 people
(Can’t reply to reply for some reason)
> They have no frames of reference for what they’re getting themselves into.
That would be my point. You’re asking questions about things that someone who has no idea about Plasma shouldn’t know anyways. If it’s about theming etc., than as always: *use sane defaults*. If you have to ask the user about something, you’ve picked a bad one. Simple as that.
Yes, sometimes it’s a 50/50 choice, but picking a default is better than this. If people cannot find where/how to switch to a dark theme (for example) unless with a welcome dialog, then they have bigger problems or plasma needs to fix things to make it easier to discover.
If you want to welcome inexperienced users, show a sticky popup notification when a link/button if you must, but this stuff is just terrible. And it’ll grow to have even more and more options confusing newbies even more and leading to even less effort into picking sane defaults and putting options to where they belong and wording them nicely.
To put it differently, welcome dialogs have been eradicated on the desktop for a reason. They an anti-pattern. And I really don’t get why they’re coming back (don’t get me started on mobile apps making them mandatory).
LikeLike
I found it super useful for new users (remember that the goal is to have Plasma in every device on the Universe) and also for not so new users. And espcially now it is pretty and usable with bottom buttons 😉
LikeLiked by 3 people
It’s a good framework for if the distro wants to ship a new user landing. I always go through those because they usually have things like themes and restricted-codecs install.
Kubuntu Focus made a good use of it, and Vanilla OS is planning to make use of it for their KDE spin I believe, and overall it’s a good thing to have rather than every distro making their own version of it (IIRC FerenOS and Garuda has their own) instead of just plugging in to something the DE made.
You can of course always just close and skip it, but it’s there for new users and for distro who wants to ship a user landing/tour/first-setup and it’s good that an integrated official solution exists IMHO.
LikeLiked by 1 person
The intention for the app is that users such as yourself would close it immediately and never see it again.
LikeLiked by 1 person
> Stuff should work out of the box.
You’re right. The vast majority of users do not care to configure a desktop at all. And you don’t need an extra guided configuration dialog for power users.
A dialog regarding the most important configuration knobs (language, timezone, etc.) does make sense for Joe User as part of a local distro installation process, but not (again) when starting the desktop. And 8 pages is indeed ridiculous.
LikeLike
@Jan
Gatekeeping is not helping anybody, we’re on a mission to get people away from Microsofts jaws of tyranny and dictatorship here =) If your biggest problem is a short instructional welcome tour after install, I’d say you are using a pretty good system.
Imagine you’ve driven automatic cars all your life and hop in a stick shift, a welcome tour on the screen could be rather handy.
LikeLike
Totally agree. I draw the line at everything being dumbed to the lowest common denominator to facilitate the newby (thereby making life painful for experienced users) but KDE walks the line admirably IMO.
Clicking close once on a welcome app is not a big hardship, and in fact even as an experienced user I’ll click through it on a new installer. Yes I’m capable of configuring everything to my liking without help, but it’s a convenient ‘TO-DO’ to quickly guide me through the required tasks.
LikeLiked by 1 person
Have you guys tried it out? I see some misconceptions borne out of assumptions rather than experience. Most of the pages don’t involve configuring anything; they teach you about parts of the system and about KDE itself. There are precisely two things you can configure in the welcome app: an opportunity to turn on telemetry (it’s off by default) and an opportunity to configure online accounts.
LikeLiked by 2 people
I think Discover is starting to look really nice now. I remember when I would avoid it, but now I go to it often, great work!
LikeLiked by 1 person
Agreed RE Discover. I felt it was a god-awful choice when I first started using Plasma but it’s definitely coming into focus.
LikeLiked by 1 person
Discover is starting to look really great. It is heading towards Mac OS X levels of being both functional and good-looking, while retaining a nice KDE-uniqueness.
But one criticism jumped to mind. Why are there 5 different ‘caret’ symbols dotted around the window frame for the Krita shot e.g. ^ etc. This is visual clutter, and confusing for new users – “what do all those arrows do”. Either the iconography needs to be improved, or thought given to how many window controls are really needed by default? and how many should be moved to accessibility/off by default.
LikeLiked by 1 person
Two of them are in the “keep on top” titlebar button which is not there by default; I’ve added it on my system because I use that functionality on a semi regular basis.
If we made all buttons look framed, then the arrows in the back button and the source chooser would be more visibly obvious as UI controls connected to specific things. See https://invent.kde.org/teams/vdg/issues/-/issues/12 for a discussion on this matter.
LikeLike
I like some of the ideas in that discussion, but I think its also the case that the maximise/minimise buttons should really not be represented by up/down carets as:
a) it doesn’t really match to what you are doing to the window, and
b) it overlaps too much with situations where you actually do need to use a caret symbol (e.g. go back one page).
But I’m sure changing the max/min buttons iconography would open a can of worms…
LikeLike
Huh, the Kate and KWrite change is nice, would it be possible to eventually make a Notepad++ like experience where you can exit and then it’ll open last saved+unsaved documents?
And those are a LOT of Wayland fixes I see. That’s great, hope Plasma 6 will be a great just-works Wayland experience.
LikeLike
Kate already does that, in fact! If it’s not working, it’s a bug, or the feature has become disabled.
LikeLike
It would be great if it was possible to set an image viewed in Gwenview as the wallpaper.
LikeLike
You said:
> Something funny happens when you take something that was super broken and you make it work a lot better: people start to use it more!
There’s nothing more to add to this!!! 🙂
I was thinking to switch over to wayland since 5.24 and always returned to X because of bugs/glitches/whatever.
Since 5.27 it’s not flawless, but very, very good. (Like, still no fontmanager in systemsettings showing a preview of the fonts installed, having to use ‘xcb’ for kfontview, no putting windows in front when they are already opened and sth. is added to them, kate still opening in a way too small window on a two monitor setup…)
Yes, there are bugs. Yes, we have bugreports for that.
But without people starting to use wayland/kwin, it won’t get better because of missing feedback.
For me, you all did great work to make wayland and plasma a stable setup for daily use.
I just want to say thank you very, very much.
And keep going in this direction!!!
LikeLike
I have been using OS X for a few weeks now, and Stage Manager is an absolute killer feature for productivity. Hard to explain, but you need to use it to appreciate it. Definitely a step up from Virtual Desktops, or Window Tiling.
Would be great to see KDE introduce something unique like this for Plasma 6.0. Tiling managers really aren’t great for focus. When you read a paperback book, you might have twitter open on your phone, but it’s not glued to the margin of your book. You flick between devices, and both are physically visible at the same time. That’s kinda what Stage Manager is.
LikeLike
(where one thing is in your dominant focus, and the other is in the periphery).
LikeLike
I’ve lodged a bug in OpenSUSE’s bugzilla for tumbleweed, after updating to Plasma 5.27.1, the fonts in the applications went tiny, but the window decoration fonts, widget fonts, and panel fonts remained as before. After reading you blog post I wonder if this may be because I use a dual monitor setup, one 4k, one 1920×1200. I use X11 and ‘xrandr –output DP-4 –auto –output DP-1 –auto –scale 1.75×1.75 –right-of DP-4 –mode 1920×1200’. Can you point me to any descriptions of other “unusual cases” that might hint at possible solutions.
LikeLike
I resolve my dual-monitor dual-dpi tiny font issue by disabling the GNOME/GTK Settings Synchronisations Service. I think the new service might be picking the lower of the two dpi’s and overwriting ~/.config/xsettingsd/xsettingsd.conf accordingly.
See https://bugzilla.opensuse.org/show_bug.cgi?id=1208681 for details.
LikeLike
This is unfortunately never going to work properly. We don’t support mixed-scale for multi-monitor setups on X11, and forcing it using xrandr will result in all kinds of bugs. You’re on your own here. 🙂 If you want supported mixed-scale multi-monitor setups, use the Wayland session!
LikeLike
Being able to turn off Kscreen2 and the new GNOME/GTK Settings Synchronisations Service makes an X11 solution possible. I haven’t encountered any bugs, it’s worked perfectly. I’m thankful that the developers had the foresight to allow all the smarts can be turned off. Xrandr is my best buddy (that plus nvidia-settings and the arch wiki).
I was considering moving to Wayland once application state/positioning is saved and restored across sessions. Wayland’s been looking quite good – and I write this as an Nvidia user.
( Kscreen2 isn’t related, it more that I don’t want my apps being moved around just because I use DisplayPort instead of HDMI/DVI, but it’s good that there is an easy way to disable it.)
LikeLike
Ok cool, just note that when you turn those things off, you lose various features and end up using an unsupported setup that isn’t tested or guaranteed to work by the developers. So if you encounter bugs with GTK app sizing and theming, window positioning, mapping Plasma desktops or panels to physical screens, or screen arrangement in general, don’t submit them to https://bugs.kde.org. I’m not sure how much the openSUSE folks want bug reports about any such issues either as they won’t be able to fix them any more that we can in KDE. It’s up to you to fix those bugs yourself. 🙂
LikeLike
Thanks for the clarification. I understand now that it was pointless to raise these bugs. I only bothered raising them at the KDE site when I read bugs were wanted about weird setups. I thought I’d make an effort, but I guess my setup is off the map weird, a blend of old and new components. Someone had the same issue with 2x2K monitors, I’ve suggested they raise a bug.
LikeLike
Great things you’re doing with whole KDE.
Would be grateful if you could point me in good direction for the following:
1. reported a bug, but I think badly, so no one got to look at it or is that normal (aka you guys are focused on more critical bugs) ?
https://bugs.kde.org/show_bug.cgi?id=466192
2. Wayland and remembering window positions
I have Firefox (multiple windows) opened over multiple Virtual Desktops.
On X11 it remembers about 90% of FF window placement across Virtual Desktops after quitting/reopening the app.
But on Wayland it always opens on one VD and doesn’t remember any of positions.
LikeLike
Really happy to see all of the multi-screen improvements in Plasma Wayland! The experience was… passable for Plasma 5.23, it had a lot of the same issues that my work Mac has (blurry text on mixed DPI setups, blurry legacy applications on the Retina display with *no* workaround), but now it is near-flawless save for apps without Wayland support not scaling well on mixed-DPI setups (not a Plasma issue, has to be resolved by application maintainers). The only “bugs” I encounter now are minor blocky text issues which I have seen are already reported and tracked. Each release has exponentially reduced these and I’ve no doubt it’ll be eliminated in the future.
Awesome job to everyone on the Plasma team, your hard work makes everyone’s lives so much easier and these days Plasma is virtually a “it just works” experience across my multitude of hardware and setups.
Hopefully someday I can get a machine set up for Plasma development and look into making some contributions (I co-authored a very minor commit with yourself a few years ago for Discover!)
LikeLiked by 1 person
That’s so great to hear! Thanks for sharing.
LikeLike
I really like that flatpak permissions are natively available in System Settings, but there may have been some overlooked UX in the interface. Under Advanced Permissions, I cannot add a new entry in a subcategory that doesn’t already have something to show. For example, for Firefox I see the Add New button on the Environment subcategory because there’s an existing var I’ve set before, using Flatseal. I cannot do the same for Steam because there’s no preexisting env var defined for it, so the entire subcategory is hidden. Unless I’ve missed some UI hint completely, this should be something fundamental to address.
Completely unrelated, but with PipeWire being default, the multi-monitor improvements reminds me: have you thought of incorporating playback controls into the same Display Configuration or similar UI? My rationale is since display out carries audio, whenever the user is changing display (e.g. for presentation), the output probably needs to go over there as well. That is, if I move a window playing video to the TV, the audio from that window should automatically redirect over there as well—provided there’s audio output on that link, of course. IIUC, with PipeWire’s design it should be far easier to do this kind of things.
Have a good day, and thanks again for the wonderful work.
LikeLike
Your mention of pipewire prompted me to give it a spin… and I’m glad I did. This fixes an issue I’ve had on two completely different laptops of the 100% volume setting being much quieter than under Windows. Now I don’t have to raise the volume above 100% with the associated clipping artefacts.
LikeLike
About the Flatpak page, can you submit a bug report?
About the audio subject, I don’t think it necessarily makes sense because not all display outputs have built-in speakers capable of playing audio. VGA and DVI never do, and even among HDMI and DP outputs, most don’t unless they’re TVs. Whether to move audio to a newly-connected display output is a very challenging topic as a result. Thankfully it’s mostly out of KDE’s hands as this logic is largely controlled by PipeWire (and PulseAudio before it).
LikeLike
Sure, but where do I submit bug reports for System Settings? bugs.kde.org or do I need to look for the specific KDE project for System Settings and report there?
And regarding audio, no I don’t mean for you to implement logic to determine whether such switch over needs to happen or not. Instead, if a user were to connect to a HDMI/DP display that advertises audio out, then Plasma will be automatically be aware and pair the speaker and monitor together. Of course, manually pairing will be great, say a VGA projector that a user can pair to a surround system rather than the computer’s desktop speaker. So if it’s playing on laptop screen, audio out will be on the paired built-in speaker; if its moved to a different screen that is capable of audio, audio out can be moved to the speaker that screen is paired with.
Forget it, I don’t actually know where I was going with my random garble of thoughts. I’m probably confusing something with the original thoughts I had on PipeWire streams. Come to think of it, I can’t easily get audio to play on built-in speaker if headphones are connected to my laptop.
And, like Android, MPRIS should be improved so apps can declare what kind of audio it’s playing: if it declares itself BGM or user can set it as BGM from the Media Player controls, then playing anything else would automatically pause the BGM stream; it’d be cool if games detect an active BGM stream can give users option to use that as game’s BGM instead. After BGM and active playback, it’d be dialer stream: apps like Plasma Mobile Dialer or other apps that facilitates VoIP/calls can supersede any other media playback. And on the Media Player, user can decide on which output device any of them are playing, if at all.
Right, the reason I remembered this is because of a FOSDEM presentation about how PipeWire/WirePlumber enabling such complex routing. Sorry for the thought vomit that’s completely unrelated to Plasma, I just thought I need to express it somewhere before completely forgetting everything.
LikeLike
I apologize again for the off-the-rails comment. It was way past midnight, I actually fell asleep, woke up to notice your reply, and then proceeded to reply with whatever incoherent thought my brain could squeeze out. Please feel free to ignore.
LikeLike
Technically, the root cause of bug kde#462695 was not exactly the same on KDE Neon and on Fedora. The KDE Neon packaging was simply missing the built KF5IdleTimeWaylandPlugin.so in the file list (debian/libkf5idletime5.install). (The changes to build dependencies (debian/control) there are only reordering, nothing missing was added.) If that had been the only issue in the Fedora RPM specfile, RPM would have produced an error about the unpackaged file. (Apparently, dpkg does not complain about that though.) Instead, the Fedora RPM specfile was also missing several build dependencies (BuildRequires lines) so that the automagic in CMakeLists.txt decided to silently not compile KF5IdleTimeWaylandPlugin.so. (This is a prime example of why automagic optional dependencies are harmful. Everything should be REQUIRED unless explicitly disabled with a CMake -D flag.) So the Fedora fix adds the missing BuildRequires lines AND the missing file list entry under %files.
LikeLike
I’m happy with the multimonitor support in Plasma 5.27. It already worked well for me since many months, but occasionally some settings were scrambled, but as you explained elsewhere, the new method of registering and remembering monitors fixed that. So all in all, multimonitor works now way better than on Windows, IMO, aside some extreme cases. Give it time and most of it will be fixed, and we’ll be ready to add new features to it, which will shame all other DEs or OSes :D.
As to the Wayland, I’m astonished how well Plasma works on Wayland even with hybrid GPU with Nvidia. I even switched to Wayland for a week, and it was mostly fine. However, I came to the conclusion, that PLASMA IS WAYLAND READY BUT WAYLAND ITSELF IS NOT READY. It is a crime if someone makes Wayland a default in current state, because:
– There are upstream issues that cause Wayland session to be problematic, like SDDM problem:
https://bugs.kde.org/show_bug.cgi?id=445449
– Aside shutdown problem, there is also suspend issue, see: https://forum.manjaro.org/t/kde-plasma-issues-logging-in-shutting-down-and-restarting/135307
– Wine is not Wayland ready yet, but it’s getting there: https://www.gamingonlinux.com/2023/02/wayland-driver-for-wine-is-getting-closer/
– Popular apps that are often needed for work, like Zoom, TeamViewer, Teams and others, won’t have desktop sharing on Wayland (if some have it, please, let me know, I can say for sure that Team Viewer don’t have it yet), so if there will be no solution on Linux side, I doubt that all popular programs will adjust their apps for Wayland.
– And most of all: windows won’t survive any Wayland/Kwin crashes. See this:
I already witnessed it when I wanted to restart Kwin or when I was playing with desktop settings, Kwin crashed – all windows, including latte-dock were just gone.
This all makes Wayland not ready yet. The danger of losing the data alone is a red sign. Until it won’t be fixed, it shouldn’t be recommended for work environments.
LikeLike
Nate, you said here in comments, that distros should get rid of snaps.
I disagree wholeheartedly, because:
– there are apps that are only available as snaps and not possible to get as flathubs
– snaps are easier to manage in cli
– snaps integrate better with system (they may follow the theme, have global menus)
– if I am not mistaken, they use a bit less space than flapacks
So if I have a need to get apps outside of repo (not available) or AUR (not working well or problematic to maintain), I prefer to get snaps, just because they integrate with system better. Flatpacks look awful and require an incredible amount of space. If you have a lot of flatpacks, this would make sense, because those would share the libraries, but if you need very occasionally few apps, snaps are a better idea IMO.
Besides, KDE is inclusive, not exclusive, so KDE should not decide to get rid of them. So if snaps will be an important part of Linux ecosystem, they deserve to be included in Discover.
LikeLike
It’s just my opinion, you don’t have to agree with it. 🙂
LikeLike