As per GNOME Shell + Mutter See Changes For Tracking Software Rendering, VNC To Toggle Animations
Looks like a desktop specific dbus API, without any documentation that I could find.
Now instead it's part of the org.gnome.Mutter.ScreenCast/RemoteDestop API to allow any remote desktop or screen cast application to inhibit animations while its session is active.
Merged by Jonas Ådahl 2 months ago, yet I can't see this API as a dbus interface or gsettings, even on Fedora 32 with mutter 3.36.1, so I've asked: how to use.
Meanwhile:
$ gsettings list-recursively | grep -i animations org.mate.interface gtk-enable-animations true org.mate.interface enable-animations true org.gnome.desktop.interface enable-animations true com.deepin.wrap.gnome.desktop.interface enable-animations true
And this toggles it:
gsettings set org.gnome.desktop.interface enable-animations false
The only problem is that gsettings are global for the user and not per-session, and so this will affect other sessions until we reset it on exit.
Not a huge problem anyway since most desktop environments don't deal well with having multiple sessions for the same user simultaneously.
Implemented in r26293.
Problem is that we can't enable this new code by default because Gio.Settings can very easily segfault the whole process:
$ python3 -c "from gi.repository import Gio;Gio.Settings.new('hello')"
(process:490782): GLib-GIO-ERROR **: 18:19:01.514: Settings schema 'hello' is not installed
Trace/breakpoint trap (core dumped)
So for now, this needs to be enabled using:
XPRA_MODIFY_GSETTINGS=1 xpra start ...
(gdb) bt
#0 0x00007fffea5817b5 in _g_log_abort () at /lib64/libglib-2.0.so.0
#1 0x00007fffea582839 in g_log_default_handler () at /lib64/libglib-2.0.so.0
#2 0x00007fffea582a6b in g_logv () at /lib64/libglib-2.0.so.0
#3 0x00007fffea582c53 in g_log () at /lib64/libglib-2.0.so.0
#4 0x00007fffea32d3d9 in g_settings_set_property () at /lib64/libgio-2.0.so.0
#5 0x00007fffea4ad751 in g_object_new_internal () at /lib64/libgobject-2.0.so.0
#6 0x00007fffea4af338 in g_object_new_valist () at /lib64/libgobject-2.0.so.0
#7 0x00007fffea4af68d in g_object_new () at /lib64/libgobject-2.0.so.0
#8 0x00007fffea48faa8 in ffi_call_unix64 () at /lib64/libffi.so.6
#9 0x00007fffea48f2a4 in ffi_call () at /lib64/libffi.so.6
#10 0x00007fffea6b9c35 in pygi_invoke_c_callable (function_cache=function_cache@entry=0x555555709f50, state=state@entry=0x7fffffffcfd0, py_args=py_args@entry=('hello',), py_kwargs=py_kwargs@entry=0x0) at ../gi/pygi-invoke.c:690
#11 0x00007fffea6bb5e8 in _function_cache_invoke_real (py_kwargs=0x0, py_args=('hello',), state=0x7fffffffcfd0, function_cache=0x555555709f50) at ../gi/pygi-cache.c:930
#12 _constructor_cache_invoke_real (function_cache=0x555555709f50, state=0x7fffffffcfd0, py_args=('hello',), py_kwargs=0x0) at ../gi/pygi-cache.c:930
#13 0x00007fffea6bb76c in pygi_function_cache_invoke (function_cache=<optimized out>, py_args=<optimized out>, py_kwargs=<optimized out>) at ../gi/pygi-cache.c:863
#14 0x00007fffea6ba389 in pygi_callable_info_invoke (user_data=0x0, cache=<optimized out>, kwargs=<optimized out>, py_args=<optimized out>, info=<optimized out>) at ../gi/pygi-invoke.c:770
#15 _wrap_g_callable_info_invoke (self=<optimized out>, py_args=<optimized out>, kwargs=<optimized out>) at ../gi/pygi-invoke.c:770
#16 0x00007ffff7d61f6c in _Py_CheckRecursionLimit () at /lib64/libpython3.7m.so.1.0
#17 0x00007fffea85c710 in ()
#18 0x00007fffea7e12f0 in ()
#19 0x00007fffea6ac380 in _function_info_call () at ../gi/pygi-info.c:567
#20 0x0000000000000000 in ()
This needs to be reported upstream..
I know it's extra hustle for an upstream bug, but can't you do it in the same way as OpenGL probing is done (i.e. with a new process doing it and let it crash instead)? 😕
can't you do it in the same way as OpenGL probing is done
Better solution: r26294.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2602