| bluesabre | Oh, right. Words. :( | 00:00 |
|---|---|---|
| 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:01 |
| 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:02 |
| saxx_ | Thanks blue :) I'll be on here a lot for sure :) | 00:03 |
| brainwash | we switch to compton in 14.10?! | 00:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| brainwash | so I don't feel like messing around with it | 00:07 |
| 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:08 |
| 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:09 |
| 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:12 |
| ochosi | hah, you wish?! :D | 00:13 |
| ochosi | just get your old computer from the drawer | 00:13 |
| ochosi | anyway, i gotta hit the sack now | 00:14 |
| 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:16 |
| bluesabre | or yeah | 00:17 |
| bluesabre | I need to stop slacking! | 00:18 |
| ochosi | hehe | 00:18 |
| knome | heh, first one to complain about desktop wallpapers on login screen ;) | 08:31 |
| 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:32 |
| 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:33 |
| knome | it's literally so *cool* | 08:34 |
| ochosi | :} | 08:34 |
| 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:35 |
| 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:36 |
| ochosi | the main issue being not breaking xscreensaver | 08:37 |
| knome | is it completely triaged now though? | 08:37 |
| 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:41 |
| 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 | 08:42 |
| === brainwash_ is now known as brainwash | ||
| ochosi | omg, i wonder how ppl can think this is a good thing... http://worldofgnome.org/running-gtk-applications-different-themes-per-app/ | 15:42 |
| elfy | ochosi: no chance of that in xfce then :p | 16:37 |
| 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:38 |
| elfy | well I'm glad I've never seen it ;) | 16:41 |
| 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:46 |
| knome | why would you implicitly want to make your system not look consistent/integrated? | 16:57 |
| 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:07 |
| GridCube | i used visually twice | 17:08 |
| ochosi | :) | 17:10 |
| ochosi | well anyway, ppl could and did always do this, i still think it's the worst | 17:11 |
| elfy | lost the sound indicator :( | 17:43 |
| GridCube | :( | 17:50 |
| ochosi | elfy: how did you lose it? | 19:27 |
| elfy | no idea ochosi | 19:28 |
| elfy | the others are there | 19:28 |
| elfy | not got around to checking updates | 19:29 |
| elfy | nothing apparent | 19:30 |
| ochosi | odd | 19:30 |
| ochosi | checked any logs yet? | 19:30 |
| 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:31 |
| elfy | I'll check I didn't cause it | 19:32 |
| === cyphermox_ is now known as cyphermox | ||
| elfy | ochosi: I guess that it did cause it :p | 19:38 |
| ochosi | so it's back nowà | 19:38 |
| elfy | current choice is vol control that works from 20% -100% or no indicator | 19:39 |
| ochosi | err, what? | 19:39 |
| elfy | I've got this again bug 1321485 | 19:40 |
| ubottu | bug 1321485 in pulseaudio (Ubuntu) "No change to volume in lowest 20% of control" [Undecided,New] https://launchpad.net/bugs/1321485 | 19:40 |
| ochosi | oh :/ | 19:40 |
| ochosi | i wasn't aware of such a bug | 19:40 |
| 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:41 |
| elfy | I have no idea what it does exactly software wise but it allows the vol keys to work properly down to mute | 19:42 |
| elfy | possibly something not matching in alsa and pulse | 19:43 |
| elfy | *shrug* | 19:43 |
| ochosi | hmyeah, shrugging would also be my reaction :) | 19:44 |
| 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:45 |
| knome | pleia2, cool, xubuntu talks | 19:57 |
| knome | well. almost | 19:57 |
| elfy | shall I remove (TODO: Link to docs for it). from the lightlocker article :p | 19:58 |
| knome | yeah... | 19:58 |
| knome | :P | 19:58 |
| 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 | 19:59 |
| elfy | done that then | 20:00 |
| elfy | lol | 20:00 |
| knome | ta elfy | 20:00 |
| ochosi | fwiw, is there a docs-link now? | 20:08 |
| knome | http://docs.xubuntu.org/1404/guide-keeping-safe.html#lock-your-screen ? | 20:14 |
| 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:19 |
| knome | mm | 20:20 |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| ochosi | i guess we need to vote on me registering the xubuntu project on that page | 20:45 |
| 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:46 |
| brainwash | maybe get the Xfce devs and maintainers involved too? | 20:47 |
| 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:48 |
| knome | ochosi, uds announcements and such | 20:49 |
| ochosi | brainwash: unfortunately i doubt that... | 20:49 |
| brainwash | but these people are usually the ones who can "easily" fix bugs in their software | 20:50 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| ali1234 | anyway the point is that this system rewards the actually hard part | 20:56 |
| 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:57 |
| ali1234 | it's also intended that this is a system where anyone can donate to any bug at any time | 20:58 |
| 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 | 20:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| knome | ali1234, err, are you suggesting we will create a system to be able to play it? | 21:09 |
| 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:10 |
| 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:11 |
| Unit193 | Some of us are very lost... | 21:16 |
| ochosi | Unit193: they won't get ignored more than they do now i think | 21:20 |
| === ubott2 is now known as ubottu | ||
| === lderan_ is now known as lderan | ||
| === dkessel_ is now known as dkessel | ||
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| ochosi | yup | 23:34 |
| 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:35 |
| ochosi | yup | 23:36 |
| bluesabre | this seems more painful than ripping mate's display dialog out of mate | 23:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| * 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:45 |
| ochosi | but i'll think about that tomorrow after multiple hours of sleep | 23:46 |
| bluesabre | sounds promising | 23:46 |
| 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:47 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| bluesabre | right | 23:57 |
| ochosi | well, "breaks"... it just doesnt lock the session on suspend | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!