On Sat, 30 Sep 2017 at 22:36:06 +0900, Osamu Aoki wrote:
> This is a placeholder bug to discuss how Debian's glue hook code for the
> keyboard input method (currently, my humble im-config) should be moving
If im-config is started as a D-Bus session service (with a file
in /usr/share/dbus-1/services, like xdg-desktop-portal-gtk), then it is
advantageous (and very simple) to add a systemd user-service, like I did
for xdg-desktop-portal-gtk. This will be used if dbus-user-session is
installed and active (requires systemd-logind and systemd as pid 1),
and ignored if not. It makes the process inheritance and cgroup tree
look like this:
systemd pid 1
|- (system services)
\- systemd --user for uid 1000
|- dbus.service
| \- dbus-daemon --session
\- your-daemon.service
\- your daemon
(so systemd --user knows your daemon is a separate thing and not part
of dbus-daemon). Traditional D-Bus activation looks more like this:
systemd pid 1
|- (system services)
\- systemd --user for uid 1000
\- dbus.service
\- dbus-daemon --session
\- your daemon
which misrepresents the relationship between dbus-daemon and your
daemon, and makes it harder for a user or sysadmin to terminate,
restart or disable your daemon.
If im-config is not a D-Bus session service then the equivalent of
https://github.com/flatpak/xdg-desktop-portal-gtk/pull/52 is not
directly applicable.
> If ibus is started outside of im-config, it may be better to
> automatically set im-config to set to "REMOVE". (I think Ubuntu at one
> point in history did so under Unity.)
Sorry, I don't know how im-config works.
If ibus is made available as a systemd user service, and everything that
would start ibus knows how to start it as a systemd user service (or via
D-Bus activation, having configured dbus-daemon to start ibus as a systemd
user service), then that has the advantage that you will not accidentally
get two copies of ibus running and fighting with each other.
There will need to be a fallback code path for systems that do not run
`systemd --user`, which might involve traditional D-Bus activation, or
running ibus directly.
> Also, I am wondering if all wayland based environment
> get started after executing /etc/X11/Xsession.d/*
Wayland-based environments do not execute /etc/X11/Xsession.d/*.
They do launch /etc/xdg/autostart/*.desktop (at least, GNOME does,
and I would be very surprised if KDE doesn't).
Traditional X11 desktop environments do execute /etc/X11/Xsession.d/*.
The scripts in /etc/X11/Xsession.d/ could have logic like this:
if systemd --user is available
ask systemd --user to start my service if necessary
else
use traditional implementation
if that's what you want?
> ... especially it's confusing how dbus etc. work.
Wayland-based environments currently rely on systemd --user and
dbus-user-session to start the session dbus-daemon. There could be a
non-systemd implementation, but as far as I know nobody has written it.
> Maybe this kind of hook script is not
> needed any more. Maybe we should also place hook code at some other
> place to be compatible with the new situation such as wayland.
Please describe which daemons/services you need to start, what
configuration those daemons/services need, and which processes need to
be able to connect to those daemons/services? With that information,
perhaps someone can suggest a design.
smcv
