From all the distros I had to test (based on Ubuntu 22.04 LTS & 24.x), KDE Neon is the most finished for general use (Desktop, Media-Center, Tablet PC and laptops).
Like many of us, I had a lot of setbacks but they have since been corrected as, for exemple: autorotate, digital multi-channel audio support, pipewire, WINE (I use Lutris for Windows games and apps), ,…
As a new Linux user I came from Windows and I use now KDE Neon as a daily driver (graphically set to mime Windows) but I continuously test other distros. But still, no matter the distro (Ubuntu Gnome, Mint Cinnamon, Zorin, Kubuntu, Wubuntu, Fedora, …) based or not on KDE plasma, I have some crashes here and there randomly when using some tricky apps (TV apps mainly). Here, these apps devs must also do their job to correct these compatibility problems.
And I’m not in hurry to migrate to any 24.04 LTS build since the migration compatibility is catastrophic with lot of missing libraries and drawbacks. Here, Linux (in general) must do some real Mind-blowing job to compare to Windows compatibility over OS generations. Just my impressions as a recent Linux user.
So, for those interested, after the update to 24.04 I was able to install wine from their official repo following the procedure on Debian/Ubuntu · Wiki · wine / wine · GitLab without having to mess with the libpoppler version and it worked!
It seems this is not recommended by Neon devs but I did not find any other alternative to have a working wine with 32bit support available in cli and by other programs relying on it.
When Wine is installed as a Flatpak, installed applications aren’t visible to the rest of the system. The only ‘workaround’ I’ve found is to use WineZGUI to launch installed applications.
Not all applications are suited to Flatpak containers, Wine is definitely one of those applications.
You run an .exe or .msi via Wine Flatpak, upon installation the installed software is not visible to the rest of the system - Therefore the installed software does not appear under the Application Launcher menu as the sandboxed application is unable to create a launcher.
Install Wine as a Flatpak and try it for yourself without WineZGUI - It’s definitely not as straightforward as installing Wine via apt, and as stated is a compromise at best.
Not all applications are suited to Flatpak containers - This is the harsh reality regarding implementations like Flatpak and Snap.
Oh! OK! So you need to create a menu launcher yourself.
I’m using it. That’s why I’m asking! I have a nikrotik router and I need to use a windows application (winbox.exe) to manage it. I have no issues doing that with wine as flatpak.
Hence: Wine Flatpak is a compromise at best and doesn’t run well from a sand boxed container.
Such an indifferent attitude isn’t going to attract users to KDE Neon, meaning less bug reports. What needs to happen is KDE Neon needs to be developed inline with package releases from actual distro’s based on the LTS release schedule.
Lutris and Bottles use self-contained Wine runners that are completely independent from one’s system, much like proton’s wine implementations on Steam.
Lutris itself doesn’t need to be a flatpak, and though on Ubuntu at least, it wants to have stock ubuntu wine installed, it doesn’t need it to run. (using the --no-install-recommends)
It is an unfortunate thing, and a harsh reality that Plasma dependency updates have broken wine more than once in the past, and likely will do so in the future. And it likely won’t change.
Bottles is essentially the solution I’ve adopted. The problem with Bottles is that I can’t move my install directory to another drive even when configuring file system access under KDE Settings > Application Permissions. So I have software (including games) being installed to my main SSD (which is of limited capacity) as opposed to one of my larger capacity drives.
Flatpak is a great idea, and I hope it continues to improve and become the defacto standard regarding Linux software installation - But the reality is that at this point in time, regarding certain applications/implementations, it can be a compromise at best.
And who is going to do that?
Do you think that they haven’t actually tried dealing with this at all?
it is not a simple thing, as they have to rebuilt every dependency of a dependency that has a 32-bit component that the third-party WineHQ stuff wants to have. Which means a LOT of stuff completely unrelated to Plasma, and a pretty small team of volunteers doing this.
I will take a look at this later. I can swear I used this to install WoW to my game drive, when I had a game capable system. It might have been via Lutris, though. I did experiment with both. I am not sure how well the System Settings permissions work or how deep they can go for flatpaks, but Flatseal may be a preferred/official tool for this.
From the perspective of end users (not developers, developers make up a small fraction of end users) the response we’ve been told is that KDE Neon is only intended for use with KDE software - From our perspective we haven’t been told that KDE developers have tried dealing with this issue in any way whatsoever.
No one’s discounting the complexity of the issue, but the fact remains that the KDE DE in it’s current form is really only suited to either rolling release distro’s or distro’s developed more along the lines of immutable distro’s - Which, once again, involves a measure of compromise to end users as not every application runs well as a Flatpak.
However, the fact you state that KDE devs have tried dealing with the issue does deserve a measure of respect - Just bear in mind that this very thread tends to suggest the opposite is the case.
I was able to move my install location under Lutris, however when I used Lutris it wasn’t a flatpak, which was an issue when I couldn’t install Wine via apt. Under Bottles, every time I try to move the install directory to another drive altogether I get errors and software refuses to run or even install from scratch. As stated, I’ve mucked about with permissions to no avail, I even tried symlinking - Which didn’t work.
This is a remarkably unfair and ignorant comment. I am reporting my experiences as an ‘end user’, not a developer - It’s no good creating a distro that needs users in order to submit bug reports when that distro is not suited to end users as it will only officially support ‘KDE software’. An OS is effectively useless when it doesn’t support the software people use.
I am not exaggerating anything, furthermore you have actually supported my points considering your own experience in your replies.
I’m not interested in any form of us vs them argument, I’m simply posting from the perspective of that important user base KDE developers need in order to keep creating a great DE.
Rest assured that they haven’t tried so and they focus on providing the best KDE software. I know that it is a cliche, but in any case you can contribute I guess in that respective, either by your work, or by funding someone who is willing to do so. I seems like there are too many users who believe that we should be able to install wine deb package, so it might not be hard to find someone to do so.
