RE: mastodon.social/@ebassi/115429…

Got nerdsniped around lunchtime yesterday, and ended up implementing a shared "reduced motion" setting for GNOME and the rest of the xdg stack:

- gitlab.gnome.org/GNOME/gtk/-/m…
- gitlab.gnome.org/GNOME/gsettin…
- github.com/flatpak/xdg-desktop…
- gitlab.gnome.org/GNOME/xdg-des…
- gitlab.gnome.org/GNOME/gnome-c…

#a11y #accessibility #gnome #gtk #xdg #portals


Time for plumbing a whole new accessibility setting from desktop to toolkit: 3 hours

Time for knowing what to plumb: 20 years

Time for bikeshedding on the type of the setting: Positive infinity


in reply to Emmanuele Bassi

This kind of stuff is not hard, per se; some middling competence with C and time will get you far enough. The hard part is building enough cachet with the ecosystem to get you through the door; the considerably harder part is having enough time (and fireproof pants) to deal with the inevitable bikeshedding when it comes to sharing functionality across projects
in reply to Emmanuele Bassi

Having said that, there are plenty of similar changes that can be implemented across the stack by relative newcomers; the recommendation is to stay laser focused on a small enough scope, and avoid trying to generalise solutions, turning a fix into a rewrite of the world. That's a sure fire way to burn out, never finish anything, and build a reputation of an architecture astronaut that never amounts to anything except hot air on issue trackers
This entry was edited (4 days ago)
in reply to jntesteves

Yep, the existing settings portal is not exposing the "enable animations" toggle that GTK expects, and KDE has a setting for the animation duration (with zero meaning disable animations) instead. Ideally, once we have this shared setting, we can properly bridge it, and implement true reduced motion, instead of a janky "turn every animation into an immediate end state transition"