Gnome 49 based flatpak app’s mouse cursor size changes unexpectedly (It is inconsistent in size with the system cursor size). It changes to bigger size when I hover over the gnome 49 base flatpak app. Here is the video https://jumpshare.com/share/iLr0DWyzoy1THzfRv2Pu
It is okay for gnome 48 base flatpak app. Here is the flatpak install app list. I have tried all options given in this discussion Flatpak Cursor Size but nothing seems to work.
This is what works for me on a KDE 6.9 Flatpak app:
I’m not able to reproduce this on fedora - with a scaled monitor (which I think is usually a component here)
This solution didn’t work for me. But I managed to get way with it by disabling the Wayland display from socket setting in Flatseal app, and it worked perfectly well as it running only by X11 socket. I don’t know why this is the case for Wayland. Can you explain?
Same issue here. Setting env variable like said by @theappgineer did not work. Only by disabling wayland from flatseal seems to work.
I watched the video, and what’s happening isn’t simply the cursor getting bigger; the cursor used is also changing.
You appear to be using Ubuntu’s default cursor, Yaru, but the app in question uses Adwaita.
It’s possible that the app in question can’t tell which cursor you’re using or can’t access your cursor’s files.
If the problem is simply a lack of access, you could copy the folders from /usr/share/icons/ to the $HOME/.icons/ folder.
Then use Flatseal to give that app access to the $HOME/.icons/ folder.
This is a regression in the GNOME 49 runtime: Cursor is incorrectly scaled in Flatpak apps using GNOME 49 runtime on Wayland (#1188) · Issues · GNOME / gnome-build-meta · GitLab
Upstream knows about it, but their response is that LTS distros should “just” package a newer version of GNOME, or that all users affected by this should “just” install another distro.
Right.
And then of course the issue is closed and locked in a typical GNOME fashion.
So I guess the only reasonable way forward is asking Flatpak application maintainers to not use the GNOME runtime, but the freedesktop.org one instead?
Well, to be fair to GNOME, they have a fix for this in the versions they support. And given they, like any other developers, only have limited resources, they have decided on a certain window in which they support their software directly.
If some distribution decides to advertise software as supported which isn’t supported by the upstream, I think it’s reasonable to say the distribution should be responsible for backporting the fixes or provide up-to-date versions.
GNOME released a broken runtime. This has nothing to do with the distros. The GNOME 48 runtime did not have this issue. The Freedesktop runtime does not have this issue. The KDE runtime does not have this issue. Only the GNOME 49 runtime does.
There is nothing reasonable at all about releasing something that breaks users’ software and then saying “lol just install Fedora”. This is arrogant, demeaning and unprofessional, and exactly this kind of mentality is a poison that will forever hinder open source adoption.
Flatpak was supposed to solve the issue of not being able to run newer versions of applications on LTS bases, but when runtime maintainers introduce breaking changes like this and then tell users to “just not use an LTS then” it’s doing the exact opposite.
The fix should be in the runtime, not in the distro. Because it’s the runtime that broke this.
I think Flatpak was mainly about being able to having a package system that can work on all distributions, and sandboxing applications. Running a Flatpak on Fedora 43 and Ubuntu 25.08 should for example be the same.
When it comes to LTS you always will have the issue that the API newer software expects will not be available, because the base system has been arbitrarily set to an older state.
Same as here: If I read it right, the GTK in the runtime now uses a protocol to communicate with the display compositor about the cursor. The supported versions of the display compositor do offer this protocol, the one in the LTS has not, hence the error.
Now, for my personal, opinionated rant:
The best solution if you want to use an LTS is to use software on the same state as your base system.
An LTS version is useful if you need as few changes as possible. For example a production server, or a workstation for an application which needs to reliable run. But in these cases the software running on these bases is stable as well. Big changes would only be done in an carefully planned update.
If you have a personal system and want to use new software, you only make it more difficult by using an LTS system. I mean, you also miss out on any improvement made since the LTS version came out for example.
So yeah, either use an LTS system as it was supposed to (stable with few changes, so no new software) or use a system that is suited for your actual use-case.
So you really think it’s normal and acceptable for a Flatpak runtime to break for the most-used distribution base by far? Seriously, how many distros are based on Ubuntu LTS?
If I were a Flatpak maintainer depending on the GNOME runtime and they simply said “yeah we introduced a bug for 75% of your users but we don’t care, just tell them to install another distro”, I’d be quite unhappy to put it mildly..
It’s just hugely unprofessional, and what kind of impression would that leave on your users?
I mean, you could easily turn this thing around towards the maintainers of the distribution, who have made the decision to build their system on an base which they know will be outdated and will cause issue with more modern software.
So, I stand by my point:
For a system where continuous operation, and I mean around the clock with very few pauses, is required and maintenance and updates are planned for all components, then an LTS is a good solution.
In any other case, using an LTS is, in today’s world of constant change and connectivity, just not a good idea.
I mean, if you want to talk in extremes, sure you could install Arch instead.
I would be happy if you would just use the non-LTS versions of Ubuntu as well. Like Ubuntu 25.08 for example.
Its not a bug, its a missing feature in the LTS distribution.
Also: I’d argue that if a distribution chooses to use old, not longer supported versions of a software and decides to give that to their users, it might be their issue to fix, not Upstream who have already fixed it in their supported versions.
Also:
Since it’s GTK4 which uses the new protocol, you are basically requesting applications to stop using GTK4, because an LTS distribution has an issue with it.
Good luck with that.
You’re welcome to look into it and implementing it.
As I said before: The resources a developer has are finite. And especially in open-source they are often scarse as well.
Which is why GNOME only supports its limited set of versions. If a distribution wants to support something older, its expected from them to, well, support it.
Anyways, since this is leading into an endless discussion, let’s stop this here by agreeing to disagree.
I mean, just talking about “how bad GNOME” is (because Ubuntu is using an outdated version that misses a feature modern GTK4 asks for) also doesn’t help the situation, now does it?
I would assume the GNOME developers would be open to discuss if there are ways to improve the situation, if someone is willing to put their resources into it. And if they act with good faith, not starts with accusations.
I just like to end this discussion. My position towards LTS should be clear, and I also don’t consider “developer is bad because they dont support old versions with new software” to be constructive.
You should be more concerned, about your distro running an EOL shell.
And you’re also conveniently ignoring, what this protocol brings to the table - you should at least know, that they did not do that for regressions sake…
