GNOME Bugzilla – Bug 772408
data: Update session desktop files for g-s-d changes
Last modified: 2016-10-11 09:36:30 UTC
.
Created attachment 336902 [details] [review] data: Update session desktop files for g-s-d changes gnome-settings-daemon has been split up into separate daemons, which means we'll need to invoke those separately. See https://bugzilla.gnome.org/show_bug.cgi?id=772370
Created attachment 336938 [details] [review] data: Update session desktop files for g-s-d changes gnome-settings-daemon has been split up into separate daemons, which means we'll need to invoke those separately. See https://bugzilla.gnome.org/show_bug.cgi?id=772370
Created attachment 336959 [details] [review] gnome-session: Export ibus configuration for legacy toolkits As was done in gnome-settings-daemon before 3.23.1.
Review of attachment 336959 [details] [review]: we actually already do that in main () i think
Review of attachment 336938 [details] [review]: so one question i have is, "which of these should leave the user with a fail whale if they fail to start?". Anyone that shouldn't, maybe should get started another way. (dbus activation, xdg autostart, systemd eventually)
(In reply to Ray Strode [halfline] from comment #4) > Review of attachment 336959 [details] [review] [review]: > > we actually already do that in main () i think Yeah, we do. I'm fine doing this in main() as it doesn't have the same problems as changing the locale after the fact (setlocale() is not thread safe), but why do we run maybe_push_env_var() when that should already have been done in the startup script? Either we do it in one or the other, not both.
(In reply to Ray Strode [halfline] from comment #5) > Review of attachment 336938 [details] [review] [review]: > > so one question i have is, "which of these should leave the user with a fail > whale if they fail to start?". Anyone that shouldn't, maybe should get > started another way. (dbus activation, xdg autostart, systemd eventually) If they crash, it's fair to say that gnome-settings-daemon would have crashed as well. So I'm not fussed about requiring them all right now, as long as we nicely stub the ones that can't run on specific environments (gdm and/or wayland). I'd like to move to using systemd *before* making some of them runtime activated (the "run gsd with systemd" bug has some of that work done for the xrandr plugin), or timer based (not done yet, but housekeeping would use this). But if we take too long implementing the systemd session bits, we can always optimise the g-s-d bits and revisit this gnome-session patch.
Comment on attachment 336938 [details] [review] data: Update session desktop files for g-s-d changes Marking as needs-work as we'll want to use rev-DNS notation for the desktop filenames.
Hi, > but why do we run maybe_push_env_var() when that should already have > been done in the startup script? Either we do it in one or the other, not > both. Yea no good reason. Just the maybe_push_env_var calls predate the import call in the shell script wrapper. we could drop them.
Created attachment 337158 [details] [review] data: Update session desktop files for g-s-d changes gnome-settings-daemon has been split up into separate daemons, which means we'll need to invoke those separately. See https://bugzilla.gnome.org/show_bug.cgi?id=772370
(In reply to Ray Strode [halfline] from comment #9) > Hi, > > but why do we run maybe_push_env_var() when that should already have > > been done in the startup script? Either we do it in one or the other, not > > both. > Yea no good reason. Just the maybe_push_env_var calls predate the import > call in the shell script wrapper. we could drop them. Patch in https://bugzilla.gnome.org/show_bug.cgi?id=772562
Created attachment 337162 [details] [review] data: Update session desktop files for g-s-d changes gnome-settings-daemon has been split up into separate daemons, which means we'll need to invoke those separately. See https://bugzilla.gnome.org/show_bug.cgi?id=772370
Review of attachment 337162 [details] [review]: we have to branch and wait for the g-s-d side to land first of course, but otherwise, this seems fine