The beta branch of the joplin-desktop snap now sets ELECTRON_OZONE_PLATFORM_HINT=auto by default. Ideally for Wayland, you should now get better scaling, and importantly, font rendering; Joplin probably benefits from good fonts. This should work for both Wayland and X11 users seamlessly.
This also includes Joplin 3.3.3, since it includes a much newer version of Electron to aid with stability for the Wayland tech.
Can anyone willing please give it a go, via sudo snap refresh joplin-desktop --beta or sudo snap install joplin-desktop --beta if you don't currently use the Snap.
If it does or doesn't work, fab, please let me know, even if that's just confirming legacy X11, but for Wayland too of course.
If it's super broken for you, run sudo snap revert joplin-desktop to go back to the last version you had; including your entire application database (i.e, all your notes will revert too, they're backed up with rollbacks each release, although will sync back to your sync target state if you do).
Preferably after the next beta release goes to stable, people should revert back to tracking stable (sudo snap refresh joplin-desktop --stable), if you don't, you'll follow the stable releases again by default automatically for now as the beta branch will become empty (I don't use it), but in the future might get opted into newer beta's (not often).
Ta.
Note: it'll probably be 30 minutes after this post before it's ready for release.
5 Likes
This works on WSL2 by default so 
- but the mouse feels a little jittery and likes to change shape (size?) a lot. Hopefully that's not a thing on real Linux.
Edit: The mouse being jittery was caused by Windows having AMD Freesync Premium with Windows Dynamic Variable Refresh Rate enabled. It's great off. The shapeshifting seems better too.
2 Likes
As an update to this, unfortunately the usage metrics show the beta branch hasn't really gotten much use, with only 10 people having downloaded it in a week (A grand total of 0.04% of users vs the stable channel).
As is, it's not a great position to be in with lack of data and test cases on real hardware. Fundamentally I'm fairly tolerant to being a little risky and trying this for the stable release, but I really would appreciate if anyone could still give this a go and report back whether it works for them or not. I'm fairly convinced the X11 users won't notice regression, but the Wayland experience across distributions going back 10 years on all the different variety of hardware isn't something a virtual machine or just myself can test sufficiently.
Right now my current thoughts are that I'll likely do a phased release of 3.3 when it becomes stable and push it through anyway. If it needs reverting, given the automatic updates, that's something that can be risk managed.
But ultimately there's still 4 or so weeks before 3.3 would be due to go stable, so, 
2 Likes
Snap beta works perfectly for me. It even feels a little better than the Flatpak. But I think that's just subjective.
I noticed that the icon is different from the one in the flatpak via the installer script. But I think that's good. At least I can tell the two apart and I like them both.
I'll let you know if there are any problems.
1 Like
Thanks for letting me know 
- really appreciated. Out of curiosity, would you be able to share your Desktop Environment and graphics card?
I'd expect any differences with the Flatpak come down to different bundled Mesa drivers in one vs the other. There's not really a reason to say one would be better than the other objectively aside from each might update those drivers at different times. I think though the Flatpak doesn't enable Wayland by default because when they'd tried, there was some turbulance involved (which is more about the quality of Electron than the quality of Flatpak, there's no reason to believe either tech is intrinsically better at just speaking Wayland) - hence me being keen to not rush into the same state.
But anywhoo, thank you 
The logo was a donation from a graphic designer who adapted it to the Gnome conventions which is why it looks a little different to the original; admittedly not everyone will be running Gnome but my logic for accepting it was better to be right sometimes than just wrong everytime (there's technically the ability to allow the snap icon to use system themes for the icon, but it's not well fleshed out and I don't think most themes would include a Joplin icon, so effectively isn't a real option unfortunately)
Yes of course. I'm on my good old workhorse dell latitude 7490.
echo "Desktop-Environment: $XDG_CURRENT_DESKTOP (Sitzungstyp: $XDG_SESSION_TYPE)" && echo -e "\nGraphiccard & Driver:" && lspci -v | grep -A 10 VGA
Desktop-Environment: ubuntu:GNOME (Sitzungstyp: wayland)
Graphiccard & Driver:
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07) (prog-if 00 [VGA controller])
DeviceName: Onboard IGD
Subsystem: Dell UHD Graphics 620
Flags: bus master, fast devsel, latency 0, IRQ 137
Memory at eb000000 (64-bit, non-prefetchable) [size=16M]
Memory at a0000000 (64-bit, prefetchable) [size=256M]
I/O ports at f000 [size=64]
Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: i915
Kernel modules: i915
1 Like
Thank you so much, if you do end up keeping using it, please let me know if anything weird happens (like, some of the Wayland reports with Electron are "Missing titlebars" (since there didn't use to be native support for CSD), then if you forced CSD support, the bug flips to "Too many titlebars" on other DE's 
- it's somewhat unpredictable what even has the potential to go wrong (aside from, it'll just look funny, no reason to expect e.g., data loss)
I've noted down that team blue from around 2016 seems to be working grand on Gnome, thanks for that.
Thank you for releasing the v3.3.3 beta for testing!
I'm noticing some issues with the Orca screen reader on GNOME (Ubuntu 24.04, Wayland).
In particular, if I
- enable the Orca screen reader with meta-shift-s and
- launch the Joplin v3.3.3 snap,
then changing focus doesn't cancel the previous content read by the screen reader.
For example, if the Orca starts reading the note title input's content, then I press tab several times to focus the note body, I need to wait for the screen reader to finish describing the title, the note toolbar, then the editor toolbar, before it starts describing the note editor.
I notice the same issue if I run the v3.3.3 AppImage with --ozone-platform=wayland --enable-features=use-ozone-platform, but not when running the AppImage with XWayland.
System information
System details report:
# System Details Report
---
## Report details
- **Date generated:** 2025-04-04 19:10:08
## Hardware Information:
- **Hardware Model:** innotek GmbH VirtualBox
- **Memory:** 15.6 GiB
- **Processor:** 13th Gen Intel® Core™ i7-1360P × 4
- **Graphics:** Software Rendering
- **Disk Capacity:** 32.8 GB
## Software Information:
- **Firmware Version:** VirtualBox
- **OS Name:** Ubuntu 24.04.2 LTS
- **OS Build:** (null)
- **OS Type:** 64-bit
- **GNOME Version:** 46
- **Windowing System:** Wayland
- **Kernel Version:** Linux 6.11.0-21-generic
Orca version: 46.1
1 Like
I think accessibility support in Wayland is one of the big blockers for Google Chrome not making the Wayland backend the default yet.
It's one I'd passively considered but hearing it in concrete terms is a little disappointing.
It's unfortunate because I'm unsure whether practically we can assume most users who make use of those kind of accessibility tools just run everything in X11 because the Wayland experience will likely be similar for other non Joplin apps, but then I'm not sure; because presumably it must be possible to get working in some capacity and therefore it might only be Electron apps doing it, they might find e.g., GTK works fine and Joplin too did until it changed underneath them 
.
Thanks for bringing that up, it's a heavy but important consideration in the short term; hopefully longer term it just becomes functional as the Wayland Chrome stuff gets worked on, but in the short term when Joplin is actively encouraging more development on accessibility, it makes me less inclined to defer from upstreams defaults 
Just to provide an update on this;
Generally speaking the feedback has been minimal but positive on the whole. Despite that, the feedback above regarding Orca, alongside other things I'm seeing elsewhere, both specific to Joplin e.g., Github with 3.3.5 coming with more IME overrides; and external Electron projects, leads me to believe that for now, this isn't worth making default before either Joplin upstream or Electron upstream does.
Unfortunately, giving people slightly better fonts at the expense of e.g., punishing the blind is the kind of awkward and ironic moral dilemma I'd rather not deal with personally.
On the plus side, it looks like this is probably at a state that it really should be close to becoming upstream defaults (and I know Google are internally testing Chrome with Wayland by default, so there's definitely the right eyes on the problem )
For now, I'm going to push 3.3.5 over the beta release so people can keep being updated who were on the beta. This disables the Ozone platform environment variable so people will be using X11 again, and once 3.3.5 is stable, beta will probably go back to being unused generally.
So should we use the appimage again or will you push updates frequently? Or does everything stay the same just without wayland support?
Sorry, I'm a little bit confused. 
The daemon handles everything magically, you'll get the current beta (3.3.5) now because I've uploaded it, when that turns stable, you'll get it as stable, and then keep getting stable thereon because I don't use beta (there was a preference years ago from Laurent to avoid it given the package is already unofficial - so using the branch for the snap is rare). This is now just the normal 3.3.5 upstream without any modifications vs the stable snap (I.E., Wayland)
My only concern when I do these is that people might pick beta once and then years later get bumped back into another one unexpectedly, but in reality it's not that many people to care about and I can't justify the effort of releasing betas if people don't use them, except when there's exceptional stuff like e.g., this (and it's not just Joplin, I've asked literal scientists on other projects before and it doesn't ever seem to get any real traction).
I'd had some thoughts on e.g., how to approach this with snap specifically - but there's not snap specific tech involved here. There's arguable a benefit with Flatpak/Snap Wayland support in that they can bundle newer Mesa Drivers than e.g., the AppImage can, which would make them winners by default on older OS', or other bits like GTK3 being consistent, GTK4 being guaranteed and consistent, etc.
But if you wanted the exact same result for the AppImage as what was tested in the snap, I'd consider e.g.,
echo 'export ELECTRON_OZONE_PLATFORM_HINT=auto' >> ~/.bashrc
(Which will effect other Electron apps too, you might prefer instead to modify the .Desktop file to the same effect)
If you were happy with that for the snap, it should be about the same for most Electron packages on your system, but there's unfortunately more nuance for edge cases right now
