Is there a community or database where people have tested different plugins on Linux either natively or with Wine to see if they can get things working?
There is, if you look up yabridge that’s like a plugin bridge that natively runs windows vsts in reaper for Linux through wine with almost no hassle. They have a list somewhere
I love Joplin, but for this write up, I think I would have reworded the sub titles to be less click-baity.
“8 Joplin Superpowers to Boost Your Note-Taking Experience”
“Create a Notebook”
Okay… Not exactly “super powers!” If you’re literally talking about some of the most basic functionality of the app. The end of the article does get into customizing it with plugins, etc so that’s good.
A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.
I still would have preffered a modular approach, where compositor, window manager, server/mouse+keyboard are plugable. Well, it’s probably possible with Wayland, but the ecosystem is not there yet.
It’s initial bcachefs anyway, which doesn’t support all features yet and still needs a lot of work. I wouldn’t run bcachefs yet on any system where an LTS kernel is necessary.
Wayland is great! Except for all list of not-a-bugs that I’d like to see fixed. Still, I’m not going back to X, so take that how you will.
What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly.
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
A lot of this is slowly (painfully?) changing, and the adversarial nature is a bit frustrating. Wayland fixes so many little things that I find it well worth it though, and I say that as a game developer frustrated by many of the core design decisions.
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
I would like them to keep that behaviour. At least make it an option or allow whitelisting certain applications. Nothing I hate more in an OS than windows stealing focus without asking.
Focus stealing is one of the worst things in the world, I am so glad I haven’t had to deal with it since I switched to wayland. (Except for stupid firefox tabs stealing focus from other tabs, that still happens obviously and happened to me during a test for my university and almost invalidated my score)
Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private.
I do like that. I have encountered a number of bullshit things like HR mindless training videos (ok, the fourth time I’ve seen this guy contemplate accepting a bribe… I get it. Don’t accept bribes! Leave that shit to Clarence Thomas) or ad playbacks that refuse to proceed unless they are focused. It’s annoying as hell. The problem you point out also sounds really annoying.
What are the not-a-bugs? Things like covering up a Wayland window will block it’s rendering thread indefinitely with no way to detect it happens to handle it. This can lock up some games, or cause you to time out in a networked application. Some Wayland core folks don’t want applications to know if their window is visible or not because it’s mild information about a user’s attention that should be private. Every game dev on the other hand is asking “WTF!?” as it causes their games to break randomly
Please don’t make up what “Wayland core folks” think. You don’t know it, and your claims are waay off.
It’s not about security. It was intended to allow the compositor to throttle apps to improve efficiency… Which of course in practice doesn’t work like this at all, because OpenGL swap buffers and Vulkan FIFO presentation modes were never intended to be used this way.
As for why that hasn’t been fixed yet, it’s not as big of a problem anymore:
Mesa (at least for Vulkan) and Xwayland gurantee one frame per second as a minimum refresh rate
toolkits and libraries use mailbox presentation internally and check frame callbacks themselves for when to render
xdg shell now contains a flag for apps to know to inhibit rendering because they’re hidden. That doesn’t guarantee that presentation won’t otherwise block though
a (set of) protocol(s) is being worked on to replace frame callbacks with a mechanism actually suited for OpenGL and Vulkan
Another mild example is that windows cannot be raised except by the user or by launching them. This is supposed to be a mild security precaution so a program can’t pop up a legitimate looking dialog over another application and trick the user. Realistically it means that applications can’t open and focus URL in your web or file browser. Instead they have to give you a notification telling you “Firefox is Ready” and make you do it manually.
That’s not even close to how activation works on Wayland, and no, it’s not just a security thing, it’s a usability thing. Apps can only raise themselves if the currently focused app gives them focus, so that random apps can’t cover up what you’re working on just cause they need to show you an ad or an “important” pop up question or whatever. If it doesn’t work for a specific app, make a bug report about it to the app.
A bit of a zombie thread, but I’m not making anything up here. The blocking issue gets discussed a lot in gamedev circles, and there are issue threads that have been locked by folks with the power to do so because they just said “no”. One of them (Maybe Sebastian Wick? I don’t remember… doesn’t really matter) gave verbatim that use case where a video service they use would stop playing videos when the browser was in the background, and that is why they won’t report . Maybe they weren’t a “core” developer, but they had the ability to say “no” and end the discussion thread.
As for it being not a problem anymore, it still occurs even on Fedora 39. The 1 second present timeout still only works for XWayland, and that’s… not a great solution. Also, realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does. We are already supporting multiple rendering APIs, and combining that with multiple UI libraries just to get a window to draw a triangle into is a combinatorial explosion. Last I remember reading from the SDL folks, they were waiting for the functionality to appear in Wayland before they could implement it, and they weren’t expecting anything to change soon either. Speaking personally, my current game project is single player so I can just pave over the timing issues when they come up:
Long frame detected: 6463.731931 ms. Skipping ahead!
The most frustrating part to me is much more meta. You get discussions with other game devs that have heard about this stuff and they continue to think that supporting Linux is just way too much work. Sometimes they are right, but rarely for the right reasons it seems. I believe in the glorious Wayland future… I just wish it would get here a bit faster. ;) On the other hand, if we rushed it and botched it then it would never arrive at all I suppose. (sigh)
As for how window activation works, you got me there. I just heard other people discussing that one, but it did explain why on Wayland I would just get “Firefox is ready” notifications when opening links instead of just showing me the page like X did. Though I’m quite happy that it’s gone now in Fedora 39. Progress is good!
The 1 second present timeout still only works for XWayland
Oof, I thought the corresponding MR for Wayland was merged… But it was from Sebastian and after he got into a heated discussion again and started cursing, the MR got closed by someone else :|
realistically unless SDL2, GLFW or whatever engine a gamedev is using handles it for them they just don’t have the time to worry about what GTK, Qt, or XDG shell does
SDL does handle it, but only for OpenGL; it can’t do anything about Vulkan. GLFW doesn’t do anything about it either, so that is pretty annoying.
I believe in the glorious Wayland future… I just wish it would get here a bit faster
Don’t we all. Let’s hope the current upstream approach to fix this issue gets somewhere sooner than later…
Sadly, this is going to be preaching to the choir. Wayland has its faults but if it truly was an inferior approach compared to X then someone would’ve forked X or spawned a totally new project. Turns out it takes time, money, and developer power that simply isn’t coming into X or any competing standard. Wayland is “good enough” to be the next standard and that’s how it’ll be for the foreseeable future.
If a BSD fan really thinks X is pivotal to BSD’s future, then maybe BSD will need to consider forking it and fixing it, but I’m sure the real solution will just be supporting Wayland on BSD too.
For most of its 15 year history implementations have been woefully and obviously insufficient. Nobody forked X because nobody needed to. Its feature complete and has been for a long time and there was nothing wrong with using X while Wayland implementations see progressive improvement.
Not only is nobody forking X but many people are building Wayland compositors.
Listening to the detractors, you get the impression that Wayland is a failure and / or that X may still be the better choice.
Then you realize the only people still working on X are paid by enterprise distros with long-term support obligations. All the toolkit people have moved to Wayland. The major desktop environments have shifted to Wayland. All the “new” window managers are for Wayland.
Wayland is already supported on BSD ( FreeBSD at least ).
The actual developers have spoken and Wayland has won.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.