After upgrading to the latest version 4.11.3 my session starts in an un-themed flavour and my .xsession-errors contains: xfsettingsd: Unknown option --display. Type 'xfsettingsd --help' for usage. After that I have a .desktop file entry in application started during session login that spawns xfsettingsd without any arg and the theme is finally loaded, but this transition between un-themed and themed session is pretty annoying. I'm not sure which process is trying to start xfsettingsd with the --display option but I guess it's related with how xfce4-session works. I tried replacing the xfsettingsd binary with a shell script that simply wraps the actual command and drops the --display arg and everything works as expected (i.e. the theme is loaded properly without any visible transition).
Created attachment 5664 re-enable gtk_get_option_group() I didn't dig too much into the code, but reading the diff between 4.11.2 and 4.11.3 I found both gtk_get_option_group() and gtk_init() were commented out in main.c The attached patch enables the gtk_get_option_group() again but keeping the gtk_init() out. It solves the described issues for me.
Good catch. I forgot xfsm does that so that applications end up on the correct monitor. I was trying to avoid the gtk_get_option_group call because it calls gtk_init on our behalf before xfsettingsd can fork which causes issues on Ubuntu (possibly because they load gtk modules for stuff they patch out of gtk). https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-init "Note that there are some alternative ways to initialize GTK+: if you are calling gtk_parse_args(), gtk_init_check(), gtk_init_with_args() or g_option_context_parse() with the option group returned by gtk_get_option_group(), you don't have to call gtk_init()." Another option is to use: g_option_context_set_ignore_unknown_options(context, TRUE); to ignore the --display option rather than make it fatal.
Created attachment 5665 Fix for --display being fatal Proposed patch. If gtk_init doesn't cause any issues with forking (and it's just dbus) then the first patch would be better.
The gtk_init() before fork() problem happens because Ubuntu loads modules at gtk_init() which open the dbus (specifically dbusmenu). After the fork, Gtk will try to reuse that dbus handle, but it's no longer valid due to being owned by the previous process. This means all dbus calls subsequently made by the program will hang. In general this is just one way that forking after gtk_init() can go horribly wrong, so it should be avoided whenever possible; as such I would recommend going with the second patch.
Verified the second patch, committed it here: http://git.xfce.org/xfce/xfce4-settings/commit/?id=178f429abeba73643fe6ef794a07b78f3b40e5cf
Marking as fixed.
Please label as 4.11.4 to allow distributions who provided 4.11.3 to distribute a fixed version.
We will release the fix with the next version, however there might still be a few more small issues we wanna take a look at. Meanwhile distributors can always ship the patch with 4.11.3.