I think it’s pretty obvious at this point that the obsidian team has no interest in ensuring their users have a pleasant wayland experience.
To try and absolve themselves of any responsibility by claiming that bugs in the electron code, which they knowingly built their entire application on, and then making no effort to work with the electron team to solve the issue makes this quite clear.
If they did care about their users wayland experience they would be actively working with users to reproduce the bug and then working with the electron developers to actively speed up the process of resolving the bug. This issue has existed for over a year and to all appearances all the developers have done is look for evidence in electron’s bug lists and point at whatever they found.
The issue is present in many other electron projects, including vscode, and in chrome itself.
I am personally following many upstream reports.
I have seen movement towards the resolution of this issue now that Wayland has been enabled by default in several distros and more people are complaining.
I do not have this issue on vscode or chrome on wayland currently, from my pov. this appears to only be an issue with obsidian, ChromeOS is moving to Wayland so if the issues are truly upstream, I can’t imagine they are far from being solved, could you link the issues your following?
Ok, I did hear about that protocol preventing smooth tab detachment and re-attachment, I assume that a workaround was used in chromium / vscode for the time being? explaining why it works in those programs today; where-as obsidian relied exclusively on that functionality? since it works on pretty much every other platform.
Fair enough! Wayland 1.34 was released a couple weeks back in march, I understand it’ll probably take a minute for Compositors and subsequently electron to implement xdg-toplevel-drag, and that the Obsidian Team probably doesn’t have the resources to create temporary compromised work-arounds, and would rather just wait for the full, & cross-platform upstream implementation.
You could run something like xeyes. A bit silly but if the eyes of the tool are able to follow your cursor when the cursor is inside the application you want to check, then its running X11. There is also xlsclients, which just prints all X11 programs to the terminal. But I don’t know how these tools perform with flatpacks.
Xeyes will follow the mouse in Obsidian and Chromium, but not the desktop. I learned some new things, not least the fact that the Flatpak version isn’t official - thanks!
Here’s the definitive answer regarding XWayland, by following the Github link from the Fedora software center:
There don’t appear to ways to work around these issues, and until they’re resolved the Obsidian flatpak will use XWayland by default.
@AlanG Yes it’s not, only the AppImage from the website is official. But okay then the Flatpak version you were using is actually in XWayland mode. Thanks for checking
On the current Insider-Build v1.6.3 I am able to drag and drop tabs under Wayland. I am running Arch-Linux with hyprland.
Can someone confirm that, also running the Insider-Build?
