> - MusicBee. There just does not seem to be a good music manager for Linux that can replace MusicBee. I rarely use it as a music player, there are dozens of great options for Linux music players, but MusicBee feeds my Airsonic instance, and I have not found a good way to manage music graphically in a way that maintains this setup.
For a traditional "all batteries included" collection management music player try Strawberry and Quod Libet. You should also look into the MuiscBrainz Picard tagger, it's a bit unwieldy to use but is very powerful once you learn it's wonky workflow.
I used Quod Libet as my main music player for a year or two, but I found it lacking and iirc sometimes laggy (it is written in Python!). Updates also seem to be infrequent.
Consistency of titlebars has been dead in every OS for decades now. This is not even a flatpak problem anyway, but I do think wayland/gnome ought to have some kind of fallback decoration. This wouldn't even be meant to solve this problem, but would be a nice gesture for situations where a dev really don't care about how the decoration functions or looks, like when opening a game window or movie player like mpv or even just having a friction-less experience when creating your first window in a new app.
> tray icon w/light and dark mode support
Flatpak and specially gnome are championing the background app portals. I have reservations on how it's not a full replacement for tray icons, but Desktop Environments are free to implement it like a tray icon.
> global keyboard shortcut
AFAIK it's a solved problem, but there is an adoption lag for DE's and apps.
> redraw events after resizing
Not sure what you mean by that? Apps resize fine in flatpak
Every problem in flatpak can be addressed. It sucks they weren't addressed sooner but I suggest you look into the efforts being made for flatpak-next. Even right now it's the closest thing we got to a unified gui experience in linux.
But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.
All these issues can happen in any platform, Linux is just the more annoying/unpredictable one, with GNOME taking the cake for being so obtuse. There is either a carelessness from the developer or the ad-hoc nature of those "tray icon" systems is to blame.
> But then you run into the problem of apps assuming the tray icon exists or is visible, but isn't, leading to problems such as the program just disappearing when you close it's window with no way to reopen it (some do reopen when you try re-executing it, others do nothing or just spawn a whole new instance...) or even having no access to some function that is exclusive to the tray icon menu.
Can you name some that act like this? In 30 years I don't think I've ever seen that behavior...
I think this is expecting a full block down to the domain? But most browser ad blockers are a lot more granular than that, and for good reason. Blocking a whole domain can have a lot of undesirable side effects.
Do you want the indisputable advantage of Wayland? No dropped frames in the desktop, even at high framerates. Back in 2023 when I was still using X11 dropping frames was par for the curse, no matter the machine, the configuration or the DE. You could only hope to get a fluid presentation when using a full screen program that used DRI unredirection (or DRM or whatever it was called) because... it eschewed X completely. Now, it used to be even worse if you go back many years from that, so there was progress, but there were always these tiny drops impacting fluidity. It also got worse the more loaded the machine was, any task in the background consuming 40% of the machine could make it feel like you were using a 30hz monitor. Or, if you dared to use 120hz it felt more like a stuttery 70hz, even at idle.
That same year I decided to give Wayland my third shot and what you know... it not only was perfectly smooth all the time but it had finally reached a point where I could use it on my HTPC. Less than a year later and it was finally usable on my desktop and laptop, and since then I haven't really looked back.
This sounds more like random configuration problems with your drivers. The rendering model for modern X clients is the same as for Wayland, so the idea that there could be room for a fundamental improvement is based on misinformation.
Random? I saw it happen on every linux machine running X I came across over the last two decades, it wasn't just mine, it was colleagues machines and so on. Maybe if you combined KDE, AMDGPU drivers, the right distro and X from around 2022 and onwards you could get a mostly smooth experience, but the behavior when pushing the system a little bit or trying high refresh rate would prevail.
The point is, even if you could get a smooth experience it was at best an exception, specially across most of X11 life. There are many reasons why the Steam Deck shipped with Steam running through the gamescope micro compositor, and one of them was sidestepping some of the X11 jank.
Not my experience and we have lot of Linux machines. Drivers and hardware expectations of programs certainly change over time, but this has not much to do with Wayland vs X.
I think the main difference is that there aren't really any deal-breaker kind of bugs any more, and as far as features there are none missing that users care about compared to X11. It's mostly just annoying bugs and the usual "third party" (including KDE) apps looking off in GNOME because the devs can't reach an agreement on some things, users be dammed.
For a traditional "all batteries included" collection management music player try Strawberry and Quod Libet. You should also look into the MuiscBrainz Picard tagger, it's a bit unwieldy to use but is very powerful once you learn it's wonky workflow.
reply