On Tue, 21.01.14 20:21, Simon McVittie ([email protected]) wrote:
> > On 21/01/14 19:22, Lennart Poettering wrote: > > On Tue, 21.01.14 19:49, Giovanni Campagna ([email protected]) wrote: > >> This won't work, because the Exec line from .service has a different > >> purpose than the Exec line from .desktop: the first runs the service, > >> the second activates the application provided by the service (ie, it > >> opens a window) > ... > >> So we would need a new line, ExecService=, that has the same purpose > >> as the Exec= key from service files. > > > > Well, this seems unnecessary. And app should just check for > > $DBUS_STARTER_BUS_ADDRESS or $DBUS_STARTER_BUS_TYPE. If that is set it > > is bus actviated. If it isn't it is not. In the latter case it should > > pop up a window. > > No, that doesn't work; child processes of an activated process will > inherit DBUS_STARTER_* from it, but should normally be starting in > "interactive, pop up a window" mode. For instance, run gvim from > gnome-terminal, then look in /proc/`pgrep gvim`/environ - the actual > terminal bit of gnome-terminal is an activated service. > > libdbus used to try to remove these variables from the environment so > that the activated process' children wouldn't get them, but this was (a) > not thread-safe, and (b) broken for several years with no apparent harm > done (the names of the variables were changed years ago, but the code to > remove them wasn't updated to the new names), so we removed the > offending code. > > If you want the protocol for activation to involve testing these > variables, then it would need to include a variable with the pid of the > process that is expected to obey those variables, similar to the systemd > LISTEN_FDS/LISTEN_PID protocol - but to be honest I think ExecService > might well be a nicer way to do this anyway. An alternative might be to also check $MANAGERPID == getppid() or so... But yeah at that point it might make sense to go ExecService, indeed... > Possibly slightly silly idea: desktop files are .ini-style, D-Bus > services are .ini-style, so a file containing both would not be > unreasonable... > > [Desktop Entry] > Name=Terminal > ... > TryExec=gnome-terminal > Exec=gnome-terminal > Icon=utilities-terminal > Type=Application > ... > [D-BUS Service] > Name=org.gnome.Terminal > Exec=/usr/lib/gnome-terminal/gnome-terminal-server Umpf. Can't say I like that... > Using .desktop for service-activation is a nice idea, although for it to > be merged, I'd want to have some D-Bus Specification text and a > regression test. Sure, of course this would need to be added to the spec. I'll bring this up on the dbus ML as soon as we have a rough idea that we actually want this all... > > If we instead ran it as part of a specific user session > > then it would go away as soon as that one session died, which is less > > desirable... > > When you say "session" here do you mean in the PAM sense: thing that a > user can have more than one of at a time, all sharing a "systemd --user" > if in use? Yes. > AIUI, we have traditionally had: > > * one session dbus-daemon per "login" > * one (gnome-shell, gnome-settings-daemon, ...) per "login" (if X11) Correct. > and you're proposing: > > * up to one (user bus, systemd --user) per (user, machine) at a time Correct. > * up to one "login" per (user, seat, machine) at a time, > potentially several sharing a systemd --user Well, we were just discussing this bit on IRC. I'd actually allow as many "login"s per user, per seat, and per machine as people want. The display manager would merge them all into one big "xinerama" workspace. However, it obviously makes little sense to log in twice on the same seat as the same user if this happens, because that way you could see a some parts of the workspace never at the same time. Hence, on the lower-level we'd not make restrictions here, howeber, I'd expect that gdm would not allow this and simply activate the existing login on the same seat when the user tries to log in multiple times on the same seat (pretty much the same as it already does that right now). > * one (gnome-shell, gnome-settings-daemon, ...) per systemd --user > (if at least one "login" is X11 or Wayland) Correct. > where by "login" I mean situations like "user sits down at a gdm prompt > and types in their password" or, if you're @1990sLinuxUser, "user logs > in on a tty and runs startx". Yupp. Lennart -- Lennart Poettering, Red Hat _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
