[07:01] <ochosi> bluesabre: thanks for fixing the accountsservice/xfdesktop bug!
[07:55] <ochosi> bluesabre: idea: what about leaving light-locker-settings as is and making a xubuntu-patch for xfpm instead that adds a locking-tab for light-locker?
[07:56] <ochosi> (in the 1.6 release we could merge this upstream, but since debian wants a stable xfpm release from us asap i don't think we can implement that before the release)
[09:36] <bluesabre> ochosi: would lls then be obsolete?
[09:39] <ochosi> bluesabre: no, not for other DEs
[09:42] <bluesabre> ok, gotcha
[09:43] <ochosi> thing is, with xfpm handling ll, we could get rid of the desktop file manipulation
[09:44] <ochosi> (assuming we'll have a release of the dbus interface soon, which i hope)
[09:45] <bluesabre> that would be cool
[09:45] <bluesabre> dbus makes everything better
[09:47] <ochosi> yeah, in this case it does
[09:47] <ochosi> thing is we need some sort of daemon to apply the dbus settings at session start
[09:47] <ochosi> and i thought xfpm would be a good place to handle that
[09:50] <bluesabre> not necessarily
[09:50] <bluesabre> have a minimal gsettings config for light-locker
[09:51] <bluesabre> it keeps the last defined settings
[09:51] <bluesabre> or, there are settings that apply to current session, and permanent
[09:51] <bluesabre> maybe
[09:51] <ochosi> hm, how do the gsettings get loaded at startup?
[09:52] <bluesabre> same as any other app?
[09:52]  * ochosi is gsettings-ignorant
[09:52] <ochosi> so you're saying we can get rid of the desktop file even with lls?
[09:53] <bluesabre> I don't see why not
[09:53] <ochosi> ah good
[09:53] <ochosi> in that case let's stick to lls and improve it
[09:53] <ochosi> at least for this release
[09:53] <ochosi> seems better than patching xfpm
[09:54] <bluesabre> ok, just to make sure I'm not confused here
[09:54] <ochosi> we can always implement the lockscreen handling in later xfpm releases
[09:54] <bluesabre> the gsettings would be for light-locker itself
[09:54] <ochosi> yup
[09:55] <bluesabre> and that could actually be a second interface of sorts, since it can update its policy when settings are modified
[09:55] <ochosi> hm?
[09:56] <ochosi> you mean gsettings-editor could be a second interface?
[09:56] <bluesabre> in a way
[09:56] <bluesabre> nvm
[09:56] <ochosi> errr? :)
[09:57] <bluesabre> with gsettings, you wouldn't need an external app starting light-locker in a specific way, or sending dbus commands at startup
[09:57] <bluesabre> it would start up with preferred settings
[09:58] <ochosi> a-ha
[09:58] <ochosi> that sounds way better
[12:13] <brainwash> bluesabre: can you also mark https://bugzilla.xfce.org/show_bug.cgi?id=10882 as invalid?
[12:13] <ubottu> bugzilla.xfce.org bug 10882 in Workspace Switcher "On every workspace switch accounts-daemon rewrites /var/lib/AccountsService/users/xxx file" [Major,New]
[12:13] <brainwash> or ochosi ^
[12:19] <brainwash> ali1234: is bug 1243354 also related to our dbus problem (meta report)?
[12:19] <ubottu> bug 1243354 in xfce4-terminal "Xfce4-terminal cannot run on more than one X screen at a time" [Medium,Confirmed] https://launchpad.net/bugs/1243354
[12:21] <ali1234> no
[12:21] <ali1234> that happens because when you run xfce4-terminal it listens on dbus, then if you open a new window it opens it from the same process
[12:22] <ali1234> so if you run another copy on another x screen, it says on dbus "hey please open a new indow"
[12:22] <ali1234> and then the original process opens a new window on the orignal x screen, because that is all it can do
[12:22] <ali1234> the original process has no access to the other screen
[12:28] <brainwash> ah, thanks for the explanation :)
[12:30] <ochosi> brainwash: done
[12:37] <brainwash> ochosi: thanks
[12:41] <ochosi> np, thanks for pointing that one out