ochosi | bluesabre: thanks for fixing the accountsservice/xfdesktop bug! | 07:01 |
---|---|---|
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:55 |
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) | 07:56 |
bluesabre | ochosi: would lls then be obsolete? | 09:36 |
ochosi | bluesabre: no, not for other DEs | 09:39 |
bluesabre | ok, gotcha | 09:42 |
ochosi | thing is, with xfpm handling ll, we could get rid of the desktop file manipulation | 09:43 |
ochosi | (assuming we'll have a release of the dbus interface soon, which i hope) | 09:44 |
bluesabre | that would be cool | 09:45 |
bluesabre | dbus makes everything better | 09:45 |
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:47 |
bluesabre | not necessarily | 09:50 |
bluesabre | have a minimal gsettings config for light-locker | 09:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:55 |
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:56 |
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:57 |
ochosi | a-ha | 09:58 |
ochosi | that sounds way better | 09:58 |
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:13 |
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:19 |
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:21 |
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:22 |
brainwash | ah, thanks for the explanation :) | 12:28 |
ochosi | brainwash: done | 12:30 |
brainwash | ochosi: thanks | 12:37 |
ochosi | np, thanks for pointing that one out | 12:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!