Snap Wayland Experiment

Development
1

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.

6 Likes
2025: The Year in Review
2

This works on WSL2 by default so :+1: - 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.

image
image1920Ă—1080 168 KB

2 Likes
3

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, :crossed_fingers:

4 Likes
4

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.

grafik

I'll let you know if there are any problems.

1 Like
5

Thanks for letting me know :slight_smile: - 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 :smiley:

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 :slight_smile: (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)

6

Yes of course. I'm on my good old workhorse dell latitude 7490. :slight_smile:

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
7

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 :laughing: - 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.

8

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

  1. enable the Orca screen reader with meta-shift-s and
  2. 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
9

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 :confused: .

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 :frowning:

10

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 :slight_smile: )

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.

11

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. :sweat_smile:

12

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 :slight_smile:

1 Like
13

The important “File Edit … Help” toolbar at the top of the Joplin window was not showing at all on my brand new Joplin 3.3 install on my Artix KDE Plasma XWayland OpenRC … desktop. Since I had never used Joplin before, I didn’t even know that such a toolbar existed, and spent a day or two lost trying to import existing work from another tool, and similar confusions.

Finally I happen to realize I was missing that critical UI piece, from some offhand comment in the middle of my umpteenth Joplin youtube video. I had persisted, since Joplin otherwise “felt good”.

Apparently my Artix/XWayland/Plasma/KDE/QT/… desktop software is only 98% compatible with current Joplin code – all but that menu bar. Not many run this particular combination of software, so I’m not too surprised.

So … now I have a question - how can I work around this missing menu bar problem:

(1) Run Joplin inside a virtual machine or container with a vanilla install of Ubuntu 22.04 LTS desktop software (chosen because it’s been around a while and in common use …). That works! My menu bar is alive and well there. But this is a rather heavy handed and inconvenient remedy, that integrates poorly with the rest of my Desktop software.

(2) Run Joplin aur/joplin-beta 3.4.4-1 (from the Arch AUR repository) with the additional AUR package: aur/joplin-beta-appimage-wayland-hook which invokes Joplin with the added command line arguments:

--enable-features=UseOzonePlatform --ozone-platform=wayland

I'd have to modify the way that hook is applied to work with my OpenRC rather than systemd environment, but that's easy, and a common sort of problem for us anti-systemd renegades.

(3) Set ELECTRON_OZONE_PLATFORM_HINT=auto on the command and run Joplin 3.3 or 3.4-beta (? which one) as the above discussion describes was being implemented, and then seems to be noted as being "disabled." (??).

===

Which of (2) or (3), and if (3), which of Joplin 3.3 or 3.4-beta, has the best chance of working, providing a Joplin that fits in fully with my other Desktop environment software, and providing the important top menu bar, in my odd-ball desktop environment?

14

Options one two and three are fairly substantially different. Especially option one. “Run an entire VM” for one app is a big ask for most people though.

Your problem at a technical level sounds like Electron isn't using Client Side Window decorations for whatever reason. There's an electron flag for that ( --enable-features=UseOzonePlatform,WaylandWindowDecorations )

It's difficult to say more because the overall interaction is between the specific desktop environent and it's general support. I am surprised to hear issues with Joplin with KDE here though, assuming both are updated (or fairly new, with KDE being a full DE and not so easily swapped).

It looks like Joplin 3.5 for January 2026 might have a chance defaulting to Wayland, looking at the other upstream stuff lining in place; so the real answer is how much work are you willing to put in Vs seeing if the 3.5 betas might fix this for you?

(I say this because Chromium 140 (beta) defaults to Wayland, which might inherit to Electron, which then Joplin would make use of, but you wouldn't see that in stable sooner than January).

15

James you are my hero! Installing joplin-desktop via snap worked like a charm first time.

Joplin GUI was failing to open after some recent updates (or me randomly installing packages from a Fedora 42 Post Install Guide) and i spent at least 24 hours trying everything and anything to get it running again, including:

  • System: rolling back installs + updates
  • Flatpak: installing previous versions of resources that had recently been updated or removed
  • AppImage: Installing the stable + older + preview releases
  • COPR repository install with dnf

Nothing was working and if I was lucky I could see an error message:

Gtk: gtk_widget_get_scale_factor: assertion 'GTK_IS_WIDGET (widget)' failed

Eventually I installed snap and the snap version of joplin-desktop and BINGO! It worked first time without even needed to set any environment variables or run with the ozone-platform flags.

Luckily I’d also backed up the Joplin application folder used by my previous flatpak version, so I was able to re-use my old SQL database and resources folder (after 1 change to the version table so that the database version matched what the app version was expecting).

So to anyone on Linux having issues with the GUI not showing (or loading then disappearing) the snap version is the solution.

Thanks again James!

My System: Fedora 42 Gnome Nvidia AMD

16

Hello :smiley:

Glad to see it works for you, it’s strange that the others didn’t and especially the Flatpak, I know NVidia has some specific Flatpak quirks, in that there’s a NVidia GPU Driver Flatpak that needs to be kept in sync with the host driver, which isn’t always reliable; but might be related to Flatpak’s issues?

Ensuring that’s installed and functional might be helpful; but wouldn’t explain why the AppImage and COPR repositories don’t work really, it could be worth posting a support thread for those because there’s a chance it’s a deeper issue than just yourself or something worth documenting for future bug reports :slight_smile:

But the snap is currently still in XWayland mode unless you’ve overridden it, it’s likely to change for all Joplin releases in version 3.5 (if the Electron runtime is bumped up sufficiently, though looks likely), meaning in January 2026 full Wayland Joplin will likely be default in all packages without any overrides for any of them. If you’re happy with the XWayland experience it’s probably worth just waiting, because I think for the most part it’s been 99% there for a while now but there’s been some recent major unblockers for the 1% cases that presumably have finally been solved to a satisfactory standard of Google themselves, so my main plan for the snap specifically is, just wait and do nothing, since it’s currently looking inevitable anyway in the very short term.

17

Just to provide some finality to this thread.

All users on the snap are using Wayland now (if they're in a Wayland session, of course). This has been live for a week and no one has raised any issues. This should also be in the 3.5 series of Joplin by the time it reaches stable.

1 Like