On Wed, 2012-10-24 at 06:25 -0400, Matthias Clasen wrote: > On Wed, Oct 24, 2012 at 4:11 AM, Bastien Nocera <[email protected]> wrote: > > > > > You still haven't answered why it's important to keep ConsoleKit. We're > > giving 6 months headway to people that'll need to replace it, which, > > from your code, should fairly trivial. > > > > I've spent 30 minutes looking into this, this morning. I've attached > the logind D-Bus apis that I found being used in gnome-session, > gnome-shell and gnome-settings-daemon. That looks easy enough, but > there's some complications: > > - The shell assumes that the object path for the current session > object is /org/freedesktop/login1/session/ + getenv > ("XDG_SESSION_ID"), I'm sure there's other assumptions like this > elsewhere > > - We expect PrepareForSleep to be emitted before and after > suspend/resume, which is hard to do, as we learned in upower > > - The inhibit api is using a mix of D-Bus with fd passing and an fd-based api > > - The session state api used in GnomeSettingsSession is not using > D-Bus, but a library api which is based upon various filesystem > interfaces (/sys/fs/cgroup/systemd, /run/systemd/, plus an fd-based > api for notification. The actual api we're using is minimal: > sd_login_monitor_new > sd_login_monitor_get_fd > sd_login_monitor_flush > sd_session_is_active > > > Is it possible to reimplement this all compatibly inside ConsoleKit ? > Probably. But 'fairly trivial', I'm not so sure about.
The object Colin proposed adding only covers the last section, which has D-Bus equivalent. That's fairly trivial. I wasn't commenting on any of the other uses of logind, seeing as that's not what we're discussing. _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
