[00:00] <bluesabre> Oh, right. Words. :(
[00:01] <bluesabre> saxx_: cool, how do you like it?
[00:01] <saxx_> I've always loved it, but finally made the move and started using is as main OS
[00:01] <Unit193> ochosi: I don't use it, so I'd not be the best example.
[00:02] <Unit193> ochosi: I think we could likely spruce up bluesabre's file a tad?
[00:02] <ochosi> sounds good
[00:02] <bluesabre> saxx_: awesome, welcome to full-time xubuntu usage :)
[00:02] <ochosi> we just need an assignee to be able to track it
[00:03] <saxx_> Thanks blue :) I'll be on here a lot for sure :)
[00:03] <brainwash> we switch to compton in 14.10?!
[00:04] <ochosi> cool, welcome saxx_ :)
[00:04] <saxx_> Thanks ochosi :)
[00:04] <ochosi> brainwash: no, but considering to provide a default config for ppl who wanna use it
[00:04] <ochosi> brainwash: weren't you one of the compton advocates? :)
[00:04] <brainwash> well, yes and no
[00:05] <ochosi> people don't seem to wanna decide today
[00:05] <brainwash> what kind of default config? hardware differs and demands special configuration options
[00:05] <Unit193> brainwash: So easier usage, but not shipped.
[00:05] <brainwash> or you mean shadow settings and so on?
[00:05] <ochosi> yeah
[00:06] <ochosi> exceptions for xfce4-notifyd and tabwin
[00:06] <ochosi> whatever can be generically pre-configured
[00:06] <ochosi> that's why we need a person in charge of that
[00:06] <ochosi> i'm happy with anyone stepping up to do that tbh :)
[00:06] <brainwash> I don't like the fancy stuff
[00:07] <brainwash> so I don't feel like messing around with it
[00:08] <ochosi> bluesabre: fwiw, the stuff i pushed to your phone wrt the lid-lock bug was relevant :)
[00:08] <ochosi> i can repeat it here though, if you wnat
[00:08] <ochosi> want/need
[00:08] <bluesabre> ochosi: I got it
[00:09] <ochosi> ok cool
[00:09] <bluesabre> I'll try to hack on that a bit tonight
[00:09] <ochosi> btw, caveat: could be that the xfconf variable isn't working so great even in the current patch
[00:12] <bluesabre> woot
[00:12] <ochosi> :)
[00:12] <bluesabre> need to sit down and really hack on this
[00:12] <bluesabre> I wish the issue affected me so I could verify :D
[00:13] <ochosi> hah, you wish?! :D
[00:13] <ochosi> just get your old computer from the drawer
[00:14] <ochosi> anyway, i gotta hit the sack now
[00:16] <bluesabre> seeya ochosi
[00:16] <ochosi> night bluesabre 
[00:16] <ochosi> oh btw, there's still a parole branch (goto-feature) waiting for your review in case you're bored or something ;)
[00:17] <bluesabre> or yeah
[00:18] <bluesabre> I need to stop slacking!
[00:18] <ochosi> hehe
[08:31] <knome> heh, first one to complain about desktop wallpapers on login screen ;)
[08:32] <ochosi> nah, there is even a bugreport about that
[08:32] <knome> aha, haven't seen that
[08:32] <knome> what'cha gonna do?
[08:33] <ochosi> and we have a branch with a fix, i.e. an option to disable it
[08:33] <knome> :)
[08:33] <knome> oki
[08:33] <knome> sounds good
[08:33] <ochosi> so in 14.10 ppl will be able to switch it off
[08:33] <knome> i now have way less hair
[08:33] <ochosi> we should probably get the greeter-settings UI installed by default
[08:33] <knome> just FYI
[08:33] <ochosi> you mean then before you became XPL?
[08:33] <knome> mhm, sounds sane
[08:33] <knome> hah!
[08:33] <knome> nah, since yesterday ;)
[08:34] <knome> it's literally so *cool*
[08:34] <ochosi> :}
[08:35] <knome> what's up with the black screen fix?
[08:35] <ochosi> well bluesabre returned a bit late last night, so we couldn't work on it together
[08:35] <knome> right
[08:36] <knome> wasn't there one ready already?
[08:36] <knome> or didn't that fix it?
[08:36] <ochosi> yeah, but one with drawbacks that was mostly a proof-of-concept
[08:36] <knome> hmmh
[08:36] <ochosi> it should test whether not inhibiting logind solves the problem
[08:36] <ochosi> (and it does)
[08:36] <knome> right
[08:36] <ochosi> doing a proper fix is (as always) more work
[08:36] <knome> of course
[08:37] <ochosi> the main issue being not breaking xscreensaver
[08:37] <knome> is it completely triaged now though?
[08:41] <ochosi> i dunno, i'm less worried about the bug status then about fixing it
[08:41] <ochosi> also the comments are still flowing in for it (which is annoying and a bit useless), so i stopped checking the bugreport
[08:42] <knome> heh, well, it's not really about the bug status
[08:42] <knome> i'm worried about fixing it too, and being completely triaged is a good thing for that
[15:42] <ochosi> omg, i wonder how ppl can think this is a good thing... http://worldofgnome.org/running-gtk-applications-different-themes-per-app/
[16:37] <elfy> ochosi: no chance of that in xfce then :p
[16:38] <ochosi> well you can do that already anyway
[16:38] <ochosi> it's just a very silly thing imo
[16:38] <ochosi> (even in gtk2)
[16:41] <elfy> well I'm glad I've never seen it ;)
[16:46] <GridCube> ochosi, why would it be silly? don't the themes reside already in the system? is loading the themes for each applications counter productive?
[16:57] <knome> why would you implicitly want to make your system not look consistent/integrated?
[17:07] <GridCube> because not everyone like things to look the same all the time?
[17:07] <GridCube> because some people might want to visually differentiate some applications from others visually?
[17:07] <GridCube> i don't know
[17:08] <GridCube> i used visually twice
[17:10] <ochosi> :)
[17:11] <ochosi> well anyway, ppl could and did always do this, i still think it's the worst
[17:43] <elfy> lost the sound indicator :(
[17:50] <GridCube> :(
[19:27] <ochosi> elfy: how did you lose it?
[19:28] <elfy> no idea ochosi 
[19:28] <elfy> the others are there
[19:29] <elfy> not got around to checking updates
[19:30] <elfy> nothing apparent
[19:30] <ochosi> odd
[19:30] <ochosi> checked any logs yet?
[19:31] <elfy> just checked apt history log for today
[19:31] <ochosi> so it just happened today?
[19:31] <elfy> yea - was there last night
[19:31] <ochosi> humm
[19:31] <elfy> I know that - had recoccurence of the last 20% vol change making no difference
[19:32] <elfy> I'll check I didn't cause it
[19:38] <elfy> ochosi: I guess that it did cause it :p
[19:38] <ochosi> so it's back nowÃ
[19:39] <elfy> current choice is vol control that works from 20% -100% or no indicator
[19:39] <ochosi> err, what?
[19:40] <elfy> I've got this again bug 1321485
[19:40] <ochosi> oh :/
[19:40] <ochosi> i wasn't aware of such a bug
[19:41] <ochosi> hw related?
[19:41] <elfy> I had it some time ago - for time read couple of years - came back
[19:41] <elfy> ochosi: same hardware I have had since I started using ubuntu in 2007 :p
[19:41] <ochosi> right
[19:41] <ochosi> odd
[19:41] <ochosi> and the ignore_dB does what exactly?
[19:42] <elfy> I have no idea what it does exactly software wise but it allows the vol keys to work properly down to mute
[19:43] <elfy> possibly something not matching in alsa and pulse
[19:43] <elfy> *shrug*
[19:44] <ochosi> hmyeah, shrugging would also be my reaction :)
[19:45] <elfy> heh
[19:45] <elfy> I ought to really check in 14.04 
[19:45] <elfy> low volumes via keyboards isn't something I often do 
[19:57] <knome> pleia2, cool, xubuntu talks
[19:57] <knome> well. almost
[19:58] <elfy> shall I remove (TODO: Link to docs for it). from the lightlocker article :p
[19:58] <knome> yeah...
[19:58] <knome> :P
[19:59] <knome> good job reviewers!
[19:59]  * knome looks in the mirror
[19:59] <pleia2> knome: haha, just a little xubuntu
[19:59] <knome> ;)
[19:59] <knome> screenshots and all!
[19:59] <ochosi> hehe, indeed
[20:00] <elfy> done that then
[20:00] <elfy> lol
[20:00] <knome> ta elfy 
[20:08] <ochosi> fwiw, is there a docs-link now?
[20:14] <knome> http://docs.xubuntu.org/1404/guide-keeping-safe.html#lock-your-screen ?
[20:19] <ochosi> mm, sounds okay to me
[20:19]  * knome tries to squeeze any sound of the URL but in vain
[20:19] <Unit193> Clearly not using espeak.
[20:20] <knome> mm
[20:33] <ochosi> on a more serious note, is anyone here (apart from me) interested in setting up some sort of bug-bounty programme for xubuntu?
[20:35] <knome> it's not a bad idea, but the bounty and target will be clearly defined and generally accepted by the team
[20:35] <knome> what would the bounty be? some of the mag money?
[20:35] <elfy> I've just got some vague unease that's very hard to put into words
[20:36] <elfy> apart from a vague sense of unease ;)
[20:36] <brainwash> way too much work to set it up and maintain such a system
[20:37] <knome> does it need a high-leve bureaucratic system?
[20:37] <brainwash> it should be fair and transparent
[20:37] <knome> in what sense fair?
[20:37] <knome> if the target is to fix a bug, it isn't fair for people who only have artistic talent
[20:37] <brainwash> people should not abuse the system
[20:38] <knome> which is why i said the bounty and target should be clearly specified
[20:38] <ochosi> i think that elementary are using a third party site
[20:38] <knome> i don't understand what kind of "system" we need here
[20:38] <knome> just list things we want to be fixed, set bounties, and go
[20:38] <ochosi> so i think there it is up to  the users that can pledge bounties
[20:39] <knome> right...
[20:39] <elfy> ochosi: like a "I want this fixed - here's x £'s" ?
[20:39] <knome> social bounty then?
[20:39] <ochosi> elfy: pretty much
[20:39] <ochosi> knome: nope, $$$
[20:39] <knome> i mean,
[20:39] <elfy> mmm 
[20:39] <knome> social in the way that the xubuntu team isn't participating in paying the bounty
[20:40] <ochosi> yea
[20:40] <knome> i'd imagine there to be sites that allow doing that
[20:40] <ochosi> yeah, i can find the elementary site...
[20:40] <knome> just pick one that seems to work well, create a xubuntu tag or sth and announce it being "official", as far as there is anything official...
[20:40] <ochosi> yeah, that could already be sufficient
[20:40] <ochosi> and we can still advertise it as a team
[20:40] <knome> that would be much better than getting involved with the system itself really
[20:41] <ochosi> i mean "advertise"...
[20:41] <ochosi> exactly
[20:41] <knome> yeah, as much as we advertise other social media outlets etc
[20:41] <elfy> one downside being - with a finite amount of people looking at bugs - the emphasis could shift from xfpm to some random thing 
[20:41] <ochosi> sure
[20:41] <ochosi> it's very democratic
[20:41] <knome> if people want silly things.. who cares?
[20:41] <knome> as long as it doesn't involve "by default in xubuntu"
[20:41] <ochosi> but generally speaking it could also be that we lose interest in the fix and just give up on it :)
[20:42] <knome> which i guess is something we should make a statement about
[20:42] <elfy> hang on
[20:42] <elfy> that's a bit premature 
[20:42] <knome> what is?
[20:43] <elfy> knome> which i guess is something we should make a statement about
[20:43] <knome> well, i obviously meant if we set something up
[20:43] <elfy> that just assumes that ochosi> on a more serious note, is anyone here (apart from me) interested in setting up some sort of bug-bounty programme for xubuntu? is going to happen
[20:43] <ochosi> https://www.bountysource.com/issues/357765-load-foreground-tab-from-cache-when-restoring-session
[20:43] <knome> to state that there is no guarantee that pledges like "please install libreoffice by default in xubuntu" are not really valid...
[20:43] <ochosi> this is an example ^
[20:44] <brainwash> so we stop fixing bugs until this bug bounty program goes live :)
[20:44] <knome> one option is a system where the team can approve/decline any possible pledge
[20:44] <elfy> I think we should install libreoffice-calc and -writer by default
[20:44] <ochosi> and this is how they do it in launchpad: https://bugs.launchpad.net/elementary/+bugs?field.tag=bounty
[20:44] <ochosi> brainwash: hehe, or we pledge team funds instead of fixing annoying bugs ourselves ;)
[20:45] <ochosi> i guess we need to vote on me registering the xubuntu project on that page
[20:46] <brainwash> however, most/many bugs are Xfce upstream ones
[20:46] <ochosi> oh, we can actually use "our" facebook account (in case we have one) for logging in
[20:46] <knome> i think we should have a broader discussion before that :)
[20:46] <ochosi> brainwash: yeah, sure, but we can always push them upstream
[20:47] <brainwash> maybe get the Xfce devs and maintainers involved too?
[20:48] <ochosi> https://www.bountysource.com/teams/midori/issues
[20:48] <ochosi> as another example
[20:48] <ochosi> brainwash: which xfce devs? :D
[20:48] <knome> ochosi, https://lists.ubuntu.com/mailman/listinfo/community-announce
[20:48] <knome> ochosi, ^ subscribe PLZ, it's a *very* low-traffic list
[20:48] <knome> ochosi, last email in february
[20:48] <brainwash> all of them.. show them some $$$ and they will start working again :P
[20:48] <ochosi> knome: what for then?
[20:48] <knome> ochosi, before that, november
[20:49] <knome> ochosi, uds announcements and such
[20:49] <ochosi> brainwash: unfortunately i doubt that...
[20:50] <brainwash> but these people are usually the ones who can "easily" fix bugs in their software
[20:52] <brainwash> we'll see, maybe they'll notice the bug bounty program and start fixing some bugs
[20:52] <ali1234> the thing about bugs is that bugs are easy to fix
[20:52] <ali1234> figuring out how to reproduce them is hard
[20:53] <ali1234> and getting upstream to commit a patch is hard
[20:53] <ali1234> so i think that a bug bounty site should roll over at each of these steps
[20:53] <ochosi> ali1234: well the most effective way is becoming an upstream contributor
[20:53] <brainwash> or fork
[20:53] <ochosi> or talking to upstream devs directly somehow
[20:53] <ochosi> meh, forking is meh
[20:54] <brainwash> but it works.. sometimes
[20:54] <ali1234> so for a new bug, the bounty would go up as people donate. once it can be 100% reproduced, whoever figured that step out gets the current bounty
[20:54] <ali1234> then the counter starts again at zero until someone submits a patch
[20:54] <ali1234> then it starts again at zero, whoever commits the patch upstream gets that bounty
[20:54] <ochosi> right, i'm not sure users get that...
[20:54] <brainwash> mmh
[20:55] <ochosi> most ppl have no idea how these processes work
[20:55] <brainwash> keep it simple
[20:55] <ali1234> well you know what they say about fools and money
[20:55] <ochosi> and they'd be frustrated to see their money go away without a fix
[20:55] <ochosi> ali1234: there's a lot of both? :p
[20:55]  * ochosi actually doesn't know what they say about them...
[20:55] <ali1234> they are soon parted
[20:56] <ali1234> anyway the point is that this system rewards the actually hard part
[20:57] <ali1234> if a bug is hard to reproduce and easy to fix, then whoever reproduced it gets the most reward
[20:57] <ali1234> if it's easy to reproduce and hard to fix, the counter will go higher during the fixing stage
[20:58] <ali1234> it's also intended that this is a system where anyone can donate to any bug at any time
[20:59] <ochosi> yeah, but why wouldnt the person doing the hard part also do the simple part of fixing the bug?
[20:59] <ochosi> that's a sort of logic that is over my head...
[20:59] <knome> unable to?
[20:59] <ali1234> maybe, but in that case they won't get any donations for the fix
[21:00] <ali1234> only for reproducing it
[21:00] <knome> ali1234, wouldn't *that* open room for playing the system?
[21:00] <ali1234> if they try to game it by posting the reproduction steps and not the fix, then someone else can snipe them
[21:00] <knome> "i reproduced it, now i'll wait until more pledges land until i fix it"
[21:00] <knome> ali1234, except that the fixer "wouldn't get any donations for the fix"
[21:00] <knome> as you said
[21:01] <knome> so why would somebody *else* fix it? immediately?
[21:01] <knome> -?
[21:01] <knome> this sounds like things are going to slow down
[21:01] <ochosi> ali1234: i dunno what bugs you have in mind specifically, but those you were working on lately are *technically* so hard to reproduce that i agree, that was the hardest part...
[21:01] <ali1234> that will always be a problem with bounties
[21:01] <knome> while it's not always fair, there should be just one bounty, for landing the final fix
[21:02] <ali1234> that will result in many bounties never being paid
[21:02] <knome> people who are experiencing the issue are most probably also willing to help debug/reproduce
[21:02] <knome> well, too bad...
[21:02] <ochosi> yeah, i guess that's okayish
[21:02] <knome> it's not like people *want* to part with their money
[21:03] <ochosi> anyway, i think that in the bountysource.com programme you can't set such finegrain control
[21:03] <ochosi> but i can ask kalikiana, he has obviously used it
[21:04] <ali1234> the problem with requiring landing the fix is what happens when someone posts a bounty that the upstream project will never accept?
[21:04] <ochosi> well that's where xubuntu comes in imo
[21:04] <ali1234> those bounties will just clog up the system
[21:05] <knome> that's why i said something about the team accepting/rejecting new pledges
[21:05] <ochosi> if it's a distro patch that gets applied in xubuntu and the money was pledged in the xubuntu project...
[21:06] <ali1234> and if landing the fix gets the bounty, then project owners can game the system, by rejecting patches from others and fixing it themselves
[21:07] <ochosi> i'd suggest we ask ppl who have used this system
[21:07] <ochosi> or: one of these systems
[21:07] <ochosi> also, note that the bounties mostly have symbolic value
[21:07] <ochosi> xubuntu will never draw so much attention that we get substantial bounties (i guess)
[21:08] <ochosi> getting 50$ for a fix is not a great incentive to "play the system"
[21:08] <ochosi> also, you'll know as a maintainer that you'll probably never get a patch again from that person if you trick them out of their bounty
[21:08] <ochosi> (it's like falsely attributing a patch to yourself in vcs)
[21:08] <Unit193> What about bugs with no bounty?  Won't those get ignored?
[21:09] <knome> ali1234, err, are you suggesting we will create a system to be able to play it?
[21:10] <knome> if anybody in the team did that, they should kicked hard in the lower back
[21:10] <ali1234> money does weird things to people :(
[21:10] <knome> like we are all here to make money :P
[21:10] <brainwash> soon
[21:10] <ali1234> just look at bitcoin
[21:11] <knome> yes... but that hardly changed people who were working on things *already*
[21:11] <knome> i don't really understand the argument
[21:11] <knome> if xubuntu developers just wanted to make money out of xubuntu, they would have found a way already
[21:11] <knome> or got lost
[21:16] <Unit193> Some of us are very lost...
[21:20] <ochosi> Unit193: they won't get ignored more than they do now i think
[23:22] <ochosi> bluesabre: so let me summarize again...
[23:22] <ochosi> what happens is this (as far as we know)
[23:22] <ochosi> 1) user closes the lid
[23:22] <ochosi> 2) xfpm notices the event and handles it
[23:22] <ochosi> 3) it fires off xflock4, which calls light-locker
[23:23] <ochosi> 4) light-locker initiates a VT switch by locking
[23:23] <ochosi> 4) system goes to suspend
[23:23] <ochosi> so as you can see, there are two 4)s
[23:23] <ochosi> that is not accidental, but actually the problem
[23:23] <knome> lol
[23:24] <ochosi> these two things aren't handled well by a "stupid" bash script as xflock is one
[23:24] <ochosi> logind always seems to handle the VT switch + suspending correclt
[23:24] <ochosi> y
[23:25] <bluesabre> ok, so that's part of the story, now for the patch
[23:25] <bluesabre> it introduces a new xfconf-setting inhibit-logind
[23:25] <bluesabre> which does what, exactly?
[23:26] <ochosi> so, we can mitigate this problem by *not* inhibiting logind in terms of handling the lid-close event (but only if 1) lid-close > lock settings is true in xfpm and 2) light-locker is in use)
[23:26] <ochosi> the patch introduces a BIG logind-inhibit killswitch. so you can only decide whether logind handles all or none of these events: power-button, suspend-button, hibernate-button, lid-event
[23:27] <ochosi> so we only want to make it take effect on the lid-event
[23:27] <ochosi> the rest should be controlled by xfpm, because there's at least a settings UI for it (which there isn't for logind)
[23:28] <ochosi> and last but not least, xscreensaver...
[23:28] <ochosi> xscreensaver *needs* the xflock4 call from xfpm before suspending on lid-close, it doesn't listen to logind's lock signal (which light-locker does, if it's started with --lock-on-suspend)
[23:30] <bluesabre> yeah
[23:30] <ochosi> all "clear"? :)
[23:30] <ochosi> it's really quite the kerfuffle...
[23:30] <bluesabre> which is why I feel like light-locker should in fact be a bit smarter and toggle the setting itself
[23:31] <ochosi> i only hope that we don't create a new problem with this
[23:31] <ochosi> because:
[23:31] <ochosi> 1) light-locker is set to lock the session on suspend
[23:31] <Unit193> And for all purposes, gnome-screensaver == xscreensaver?
[23:32] <ochosi> 2) xfpm is set to lock the session on suspend/lid-close
[23:32] <ochosi> so if the lid-close event is inhibited i guess xfpm should also *not* actively lock the session
[23:33] <ochosi> Unit193: no, i think gnome-screensaver actually *does* listen to the logind lock signal
[23:33] <ochosi> (btw, don't hit me with the rod if it's not logind sending the dbus lock signal but something else)
[23:33] <Unit193> Ah.  I take it newer xscreensaver still doesn't?
[23:34] <ochosi> yup
[23:35] <ochosi> xscreensaver only does something if you call it specifically (or the timeout runs out)
[23:35] <bluesabre> I'd be in favor of the string option
[23:35] <bluesabre> or multiple bools
[23:35] <ochosi> yeah, i think the string option is the sanest
[23:35] <bluesabre> xfce4-power-manager/logind/
[23:35] <ochosi> multiple bools have the advantage of not having to evaluate the string...
[23:35] <bluesabre> and then each of the possible settings there
[23:36] <ochosi> yup
[23:36] <bluesabre> this seems more painful than ripping mate's display dialog out of mate
[23:37] <ochosi> yeah, mostly because there are so many actors that need to react to one another
[23:37] <ochosi> if only light-locker wouldn't have to switch VT
[23:37] <ochosi> i wonder though
[23:37] <knome> actors like hugh grant?
[23:37] <bluesabre> is eric around?
[23:37] <ochosi> would it all be solved by using late-locking?
[23:37]  * knome hides and laughs
[23:37] <bluesabre> nope
[23:38] <bluesabre> late-locking still locks on lid-close I believe
[23:38] <ochosi> yeah, true, it doesn't apply in this case
[23:38] <ochosi> silly ochosi
[23:38] <ochosi> eric is only around at very specific times of day, much like yourself ;)
[23:39] <bluesabre> :)
[23:39] <ochosi> around 3-5PM UTC
[23:39] <bluesabre> so, how would you like to proceed, or knome/Unit193, thoughts?
[23:39] <knome> well, fix it..? :)
[23:40] <bluesabre> :D
[23:40] <ochosi> super-constructive as always :)
[23:40] <knome> well, what do you expect from a non-technical guy at almost 3am? 
[23:40] <knome> bools sound sane to me
[23:41] <knome> but i'm unable judge if there are drawbacks or not
[23:41] <Unit193> kI think he's tired, he asked me too.
[23:41] <knome> and whether they are bad enough to make the option not viable
[23:42] <ochosi> bluesabre: the bools are easier to handle in settings-editor
[23:42] <bluesabre> yes
[23:42] <ochosi> for those that need to re-enable logind-inhibition for xscreensaver
[23:42] <ochosi> or actually
[23:42] <knome> and easier to understand on the code level as well.
[23:42] <knome> and no wondering what the possible options are
[23:43] <ochosi> logind can still be switched to ON in xfpm with xscreensaver
[23:43] <knome> or syntax, in some cases
[23:43] <ochosi> it just needs to call xflock in this case
[23:43] <ochosi> hah
[23:43] <ochosi> i got it
[23:43] <bluesabre> finally
[23:43] <ochosi> ok, listen up
[23:43] <bluesabre> :P
[23:43] <knome> yes sir!
[23:43]  * ochosi hopes he'll make sense now...
[23:43]  * ochosi feels his hands are getting sweaty
[23:43] <knome> probably not sir
[23:44] <ochosi> ok, so the problem is not logind in a way
[23:44] <ochosi> it's the lock signal
[23:44] <ochosi> light-locker -> logind
[23:44] <ochosi> xscreen-saver -> xflock4
[23:44] <ochosi> but, for xscreensaver it doesn#t matter whether logind sends the lock signal
[23:44] <ochosi> it doesnt listen
[23:45]  * knome faints with "xscreen-saver"
[23:45] <ochosi> so we can *always* uninhibit logind if the lid-close event is set to suspend and lock on suspend is on
[23:45] <ochosi> in xubuntu, that is
[23:45] <ochosi> upstream it'll be a different story
[23:46] <ochosi> but i'll think about that tomorrow after multiple hours of sleep
[23:46] <bluesabre> sounds promising
[23:47] <ochosi> well it should make things less compley
[23:47] <ochosi> complex
[23:47] <bluesabre> less compley would be good
[23:47] <knome> hehe
[23:49] <ochosi> bluesabre: so, we need xfpm patched that if (lid-close-event=suspend && lock-on-suspend=TRUE) { !inhibit_logind }
[23:49] <ochosi> and we need to re-enable --lock-on-suspend in light-locker(-settings)
[23:49] <bluesabre> fun
[23:50] <ochosi> well the latter you've already done, no?
[23:50] <bluesabre> I think yes
[23:50] <bluesabre> this whole thing has been very confusing for me
[23:50] <ochosi> i know, i'm sorry. it *is* confusing.
[23:50] <ochosi> for me too
[23:51] <ochosi> i guess you'd want me to point you to the portions of code that are relevant?
[23:51] <bluesabre> that would be helpful
[23:53] <ochosi> http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-manager.c#n318
[23:53] <ochosi> that is the part that handles the lid
[23:53] <ochosi> i'd add a check there for those two variables i mentioned above
[23:54] <ochosi> s/variables/settings/
[23:54] <ochosi> (gah, i'm really a bit tired ...)
[23:54] <ochosi> this is the code for inhibiting systemd: http://git.xfce.org/xfce/xfce4-power-manager/tree/src/xfpm-main.c#n198
[23:55] <ochosi> it'd be best to replace the const "handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch" with just "handle-power-key:handle-suspend-key:handle-hibernate-key" i guess
[23:56] <bluesabre> ok, I'll try to get started with that tonight
[23:56] <ochosi> this is eric's concept patch: https://github.com/EricKoegel/xfce4-power-manager/commit/21b8e5abf4e5f93c28cb964b4618b9b509780951
[23:56] <ochosi> this fixes things with light-locker ^
[23:56] <ochosi> but breaks it with xscreensaver obviously, cause it relies on logind sending the lock signal
[23:57] <bluesabre> right
[23:57] <ochosi> well, "breaks"... it just doesnt lock the session on suspend