[00:06] <knome> why?
[00:17] <Unit193> And, indicator-sound pulls in a nasty "dep" now. :/
[00:18] <ochosi> Unit193: which one?
[00:18] <fibz_> knome, because the xubuntu MSRq is a very common support question.
[00:19] <knome> the channel shouldn't be full of factoid triggering though
[00:19] <knome> i haven't seen it asked that often really...
[00:20] <Unit193> ochosi: unity-greeter-session-broadcast -> url-dispatcher-tools -> url-dispatcher -> click (the stack.)
[00:20] <knome> "1gb" is three letters, "!requirements" is 13, even "!sysreq" is 7
[00:20] <ochosi> Unit193: meh, that's annoying, can you file a bugreport about it? i can talk to larsu tomorrow
[00:22] <ochosi> Unit193: ideally just ping me with the bug-link and i'll bring it up, gotta go to bed now
[00:22] <ochosi> night!
[00:23] <knome> nighty
[00:31] <Unit193> ochosi: I didn't even have to: https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034
[00:31] <Unit193> Hahaha!  Unity user too!
[00:39] <slickymaster> knome: "Update Wikipedia with up-to-date information" -> you are referring to http://en.wikipedia.org/wiki/Xubuntu#Xubuntu_14.04_LTS and http://en.wikipedia.org/wiki/Xubuntu#Applications only, right?
[00:40] <slickymaster> and probably same changes in http://en.wikipedia.org/wiki/Xubuntu#Goals ought to be done
[00:41] <slickymaster> mirroring the new recommended system resources -specs
[02:11] <bluesabre0> micahg: if you happen to be around, we've got the ack to upload light-locker-1.4.0
[02:11] <bluesabre0> https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1296456
[02:12] <bluesabre0> I will follow that with a light-locker-settings release tomorrow (will need another sets of approvals)
[02:48] <Noskcaj_school> Can someone with triage rights have a look at all the thunar crashed with SIGSEGV in g_slice_free1()  bugs?
[02:51] <micahg> bluesabre0: why not land them together?
[02:51] <bluesabre0> micahg, working on the release now
[03:33] <bluesabre0> knome, micahg, ochosi, lderan: https://bugs.launchpad.net/ubuntu/+source/light-locker-settings/+bug/1297058
[03:34] <micahg> bluesabre0: make sure you get lubuntu sign-off as well since it's seeded by them
[03:34] <bluesabre0> ok, will do, micahg
[03:34] <bluesabre0> #join #lubuntu-devel
[03:34] <bluesabre0> woops
[03:35] <micahg> do they have a dev channel now?
[03:38] <bluesabre0> nope
[03:38] <bluesabre0> :)
[03:39] <bluesabre0> sent a ping out at #lubuntu
[03:40] <bluesabre0> heading to bed now, let me know if you need me to change/update anything
[03:44] <fibz_> i can confirm the wallpaper switching bug: https://bugs.launchpad.net/ubuntu/+source/xfdesktop4/+bug/1295614
[04:01] <Unit193> bluesabre0: gilir isn't on IRC right now, and doesn't generally idle.
[04:03] <bluesabre0> Unit193: do you have a suggestion, or should I subscribe him to that bug?
[04:16] <Unit193> Sub+mail?
[05:53] <Noskcaj> ali1234, You were looking at thunar crashes weren't you?
[05:54] <Noskcaj> Because there's around 10 different "thunar crashed with SIGSEGV in g_slice_free1()" bugs, all set to private. all are from since the 13.10 release
[07:20] <elfy> ochosi: it'd take more than some random guy on a random channel in freenode randomly agreeing with a bug I reported to make me happy :)
[07:24] <elfy> pleia2 knome - can someone socialise the final beta test call please
[07:25] <elfy> tia
[09:32] <elfy> knome: I started draft for final beta release notes 
[09:34] <elfy> !team
[09:35] <elfy> I would appreciate as many of you as possible to test the Final Beta before it's too late - thanks :)
[09:57] <elfy> first new bug for beta ... bug 1297170
[10:03] <bluesabre0> thats an improvement
[10:03] <bluesabre0> we had the debian wp for a bit
[10:03] <bluesabre0> I'll test the beta tonight
[10:04] <elfy> cheers
[10:04] <elfy> still get Debian swirl under the try and install buttons too
[10:05] <elfy> bluesabre0: this new one is the desktop wallpaper once it boots the livesession
[10:05] <bluesabre0> ah, gotcha
[10:13] <elfy> and once installed - same wallpaper
[10:13] <bluesabre0> lovely!
[10:14] <bluesabre0> ochosi... didn't you commit a fix for the wallpaper?
[10:48] <elfy> hi brainwash 
[10:51] <brainwash> hey elfy
[10:51] <slickymasterWork> hey brainwash 
[10:51] <brainwash> saw your wallpaper report
[10:51] <brainwash> hello slickymasterWork 
[10:52] <brainwash> so we are ready for the final beta... and the xubuntu wallpaper is not being displayed (xfce one instead)
[10:52] <brainwash> :)
[10:55] <elfy> yep
[10:55] <elfy> brainwash: atm we get both wallpaper bugs - debian at the Try/Install stage - then XFCE on live session and after install
[10:55] <elfy> and the ibus one ... ;)
[10:56] <brainwash> the user will be confused
[10:56] <elfy> I also got this today - couldn't be bothered to file a new one - cub says he's going to do that 
[10:56] <elfy> bug 1201762
[10:56] <elfy> which could well be tied up with the other issue I guess
[10:57] <brainwash> possibly
[11:00] <elfy> ok so that's seriously bizarre 
[11:01] <elfy> install - get xfce wallpaper - install to test resize - get xubuntu wallpaper
[11:01] <brainwash> elfy: want to mark bug 1294209 as incomplete? we got basically not information other than the desktop did freeze at some point
[11:01] <brainwash> maybe due to the user configuration, hardware setup, driver malfunction
[11:02] <elfy> I just commented 
[11:02] <elfy> brainwash: if it is something like that then I'd wonder why I don't see the same behaviour elsewhere
[11:02] <brainwash> ok, so it's the same user account?
[11:02] <elfy> yep
[11:03] <brainwash> can you test with a different user please
[11:03] <elfy> anyway - bbl 
[11:03] <brainwash> bye
[11:03] <elfy> not today I can't - I am smack bang in the middle of testing beta's 
[11:04] <elfy> oh - forget the bizarre behaviour now the desktop is up it is XFCE - but I did see xubuntu before desktop loads
[11:14] <ochosi> bluesabre0: no, haven't looked at the wallpaper bug at all. waiting for knome to finish the wallpaper...
[11:15] <ochosi> Unit193: hey, did you eventually report a bug about indicator-sound's changed depends?
[11:27] <ochosi> knome, micahg: (1) ubuntu uses/installs ibus by default
[11:27] <ochosi> knome, micahg: (2) they use indicator-keyboard, which relies on unity-settings-daemon to apply all settings (i.e. we can't/don't want to use that)
[11:29] <ochosi> knome, micahg: (3) i think we should a) debug that problem better and get to the bottom of it and b) hide the trayicon by default, as that was also the case previously and it's only needed for ppl with >1 kb-layout/input-lang (and they have to set those up via ibus-prefs, where they can activate the trayicon if they want)
[11:30] <ochosi> elfy: would you be available (or: when?) for helping with (3) a) ? ^
[11:34] <brainwash> ochosi: will hiding the trayicon solve the problem? the daemon is still running in the background
[11:43] <ochosi> brainwash: no, that's why it's only b)
[11:43] <ochosi> at least i presume it won't solve the problem, but then again, how would i know, i've never experienced the bug
[11:44] <elfy> ochosi: when? 
[11:44] <ochosi> elfy: whenever we're both available i guess
[11:45] <elfy> will be a bit later on - painting and testing atm
[11:45] <ochosi> sounds good
[11:45] <ochosi> just ping me, i *should* be available for some debugging
[11:46] <ochosi> or can you already judge about when that'd be?
[11:48] <elfy> well I was hoping to get away with 2 coats ... but it's not looking good lol
[11:48] <elfy> ochosi: are you about this evening ?
[11:48] <ochosi> hm, evenings are a mixed bag
[11:48] <ochosi> can't really say
[11:49] <elfy> ok - well I'm holiday all week so ... 
[11:58] <brainwash> ochosi: simply create a new user and select en_GB on the login screen
[11:58] <brainwash> log in and see what the try icon says
[11:59] <ochosi> what happens for you when you do that?
[12:00] <brainwash> the tray icon lists en_US
[12:00] <brainwash> oh ****
[12:00] <brainwash> desktop icon are not sized properly
[12:01] <brainwash> config window says 48px, but it only changes to a bigger size after adjusting the icon size manually
[12:02] <brainwash> so it's ~32px on a fresh login
[12:02] <brainwash> + new account
[12:02] <ochosi> but the greeter doesn't mess with ibus or the kb-layout at all, it only sets the locale
[12:03] <ochosi> so if you don't set en_GB as keyboard layout during installation time, how should it be shown by ibus?
[12:04] <brainwash> what about new user accounts?
[12:04] <ochosi> those will use the system settings by default i guess
[12:04] <ochosi> we don't have a special dialogue where you're asked about keyboard-layout after you selected it in ubiquity
[12:05] <elfy> brainwash: delete from desktop works ok for a new user
[12:05] <brainwash> elfy: thanks for testing
[12:06] <brainwash> ochosi: so switching the language to en_GB does not alter the kb layout to en_GB, or ibus is simply not able to map it this way
[12:07] <ochosi> brainwash: that's only the language in the greeter, as i said. that has no effect on the kb-layout
[12:08] <brainwash> yes, that's what I said
[12:08] <ochosi> there's even a patch for adding a greeter-native kb-layout-switcher, but we simply haven't had the time to review/include that
[12:08] <ochosi> yup, that's it
[12:08] <ochosi> so i'm wondering whether this is not a misunderstanding maybe instead of a bug
[12:08] <ochosi> at least i don't know how to reproduce it here now
[12:09] <ochosi> and my connection is too bad to dl an iso-file
[12:09] <brainwash> maybe
[12:09] <ochosi> which is why i wanted someone to test this from the start
[12:09] <brainwash> so we need to know what happens if ibus is not present and new user account is created
[12:09] <elfy> a misunderstanding?
[12:12] <elfy> brainwash: I can test that 
[12:13] <ochosi> brainwash: well we'd want to test again starting from the installer
[12:14] <ochosi> elfy: yeah, in the sense that you could have forgotten to define the kb-layout to en_GB in the installer and hence the default en_US is used by ibus
[12:14] <ochosi> and since the greeter's language menu could be mistaken for a kb-layout-switcher, you thought you could change it there
[12:15] <elfy> ochosi: not the case - I tried more than once, and in lubuntu and studio and ubuntu and kubuntu and 5 beta tests today
[12:15] <ochosi> ok
[12:15] <ochosi> just wanting to make sure
[12:15] <elfy> you set keyboard during install and it ignores it :)
[12:15] <elfy> yep - that's ok 
[12:15] <ochosi> well i dunno, i set it to DE and that works fine
[12:15] <elfy> and I've had numerous people with UK keyboards all confirm it :)
[12:16] <brainwash> en_AU too, or?
[12:16] <brainwash> basically all the variants I think
[12:17] <elfy> brainwash: nope - just UK 
[12:17] <ochosi> that's weird
[12:17] <brainwash> ok
[12:19] <elfy> you can add UK to ibus and that works - or purge ibus and that works - but the issue is that we didn't get this when ibus wasn't in the panel
[12:20] <elfy> and you shouldn't have to do either of those things 
[12:20] <elfy> bbl
[12:20] <ochosi> elfy: so when you disable the trayicon and restart your session that works?
[12:29] <brainwash> ochosi: bug 1272057
[12:32] <brainwash> icons should be now 48px, but they are smaller when you create a new account
[12:32] <brainwash> could be related to the recent style change problem
[12:38] <elfy> ochosi: checking
[12:43] <elfy> ochosi: so - setting ibus to not show in panel then logout/in makes no difference 
[13:16] <ochosi> elfy: yeah, thought so.
[13:18] <ochosi> elfy: what does localectl say about your Layout?
[13:38] <knome> hey elfy 
[13:38] <knome> ochosi, 
[13:38] <knome> comments: http://xubuntu.org/about/
[13:40] <ochosi> knome: sounds good to me!
[13:41] <knome> sounds?
[13:41] <elfy> and me 
[13:41] <knome> do you use text-to-speech?
[13:41] <knome> you too?!
[13:41] <elfy> sounds like the allman brothers atm
[13:41] <knome> ok, i'll mark the work item for that "DONE", we can improve later
[13:41] <elfy> knome: wait
[13:42] <knome> it's DONE, but feel free to comment :P
[13:42] <elfy> ochosi: I'll do that as soon as this one has installed
[13:42] <elfy> comments are \o/ 
[13:42] <knome> heh
[13:42] <elfy> looking at sentences and spelling now ... 
[13:42] <knome> sure
[13:42] <knome> i'll release the edit lock
[13:42] <knome> so if you feel like it, just go and fix
[13:42] <elfy> oh d'oh - can do it myself lol
[13:43] <knome> yep
[13:44] <elfy>  The community infrastructure and communication should be made as good as possible to enable 
[13:45] <elfy> not sure what to do with that sentence though ... 
[13:45] <elfy> I added a 'be' is all :)
[13:45] <knome> hehe
[13:45] <knome> well could be just "should be as good ..."
[13:46] <elfy> mmm - it's the as possible as well 
[13:46] <elfy> how about "The community infrastructure and communication should be robust enough to enable the contributors to direct their efforts into making Xubuntu better and not resolve irrelevant issues.
[13:47] <elfy> knome: ^^
[13:48] <knome> yeah worksforme
[13:49] <elfy> all done then :)
[13:50]  * elfy likes recommended system resources by the way 
[13:51] <knome> goodie
[13:53] <elfy> ochosi: nothing unexpected in locaectl http://pastebin.ubuntu.com/7151268/
[13:54] <micahg> ochosi: your plan sounds fine
[13:54] <knome> hey micahg 
[13:55] <micahg> hi knome 
[13:55] <knome> what's up?
[13:55] <knome> also, nice to see you around more
[13:56] <knome> slickymasterWork, ubiquity slideshow translation issues resolved
[13:59]  * elfy is not doing anymore tests today 
[13:59] <knome> yeah, fair ;
[13:59] <knome> ;)
[13:59]  * knome is translating the slideshow
[13:59] <elfy> I purged vbox as well :p
[13:59] <knome> haha
[13:59] <elfy> not doing any tomorrow either :D
[14:00] <elfy> good old Mr Elkins has weighed in on testing :)
[14:00] <ali1234> what do you mean "irrelevant issues"?
[14:05] <ochosi> elfy: when going to the ibus preferences (in the settings manager) in the advanced tab, is "use system keyboard layout" ticked
[14:06] <ochosi> elfy: or is "customize active input methods" ticked in the "input method" tab? or both?
[14:06] <ochosi> i'm wondering whether we just need different default settings for ibus, e.g. use the system layout by default
[14:07] <ochosi> would be nice if you could check what combination of settings resolves the issue for you
[14:08] <knome> ali1234, like fighting with skype that doesn't work...
[14:09] <knome> ali1234, or not having a bug tracker...
[14:09] <knome> ali1234, or not having the tools to track blueprints...
[14:09] <ali1234> skype works fine here
[14:09] <knome> ali1234, or not having the communication medias...
[14:09] <ali1234> but i see what you mean
[14:09] <knome> yep
[14:09] <knome> it's more behind-the-curtains
[14:10] <ali1234> yeah that's not clear from the page. "making Xubuntu better and not resolve irrelevant issues." sounds like you want to top-down dictate which bugs *in xubuntu* we fix and which ones we ignore
[14:10] <ali1234> i know that's not true, but that's how it reads
[14:10] <knome> it is... look at the context
[14:10] <ali1234> not really
[14:11] <ali1234> "enable the contributors to direct their efforts into making Xubuntu better and not resolve irrelevant issues"
[14:11] <ali1234> reads the same as
[14:11] <ali1234> "enable the contributors to direct their efforts into making Xubuntu better by resolving relevant issues"
[14:12] <ali1234> i would just end the sentence after "better."
[14:13] <knome> elfy, ^
[14:13] <ali1234> irrelevant issues are irrelevant, lol
[14:14] <ali1234> or perhaps irrelevant isn't quite the right word. perhaps "peripheral" would be better, if it weren't already overloaded in the computing world
[14:14] <knome> uah
[14:14] <knome> peripheral things *are* which we want to improve
[14:14] <knome> in a way...
[14:14] <ali1234> yes, so that contributors don't have to
[14:14] <knome> well,
[14:14] <ali1234> but people might think of "peripheral" as in their printer
[14:14] <knome> the contributors might have to do that as well :P
[14:15] <ali1234> "why u no fix my printer driver?"
[14:15] <knome> well that's not what we are talking at all in that section
[14:15] <ali1234> i know
[14:15] <knome> i guess you can *always* misunderstand
[14:15] <ochosi> ali1234: that question could go into the FAQ ;)
[14:15] <knome> there is no way to make it completly unambiguous
[14:15] <ali1234> i know exactly what you mean, now you've explained it :)
[14:16] <knome> especially since we explain more of it in the strategy document
[14:16] <knome> this is just a brief overview
[14:16] <ali1234> also grammar wise it should me "resolving" not "resolve" so that it matches "making"
[14:17] <knome> ochosi, allö
[14:17] <knome> ochosi, is there really a "Desktop Settings" -item in the settings manager?
[14:17] <knome> or isn't it just "Desktop" ?
[14:17] <ali1234> unless you mean "should be made as good as possible and not reolve irrelevant issues" - which actually makes sense... hmm
[14:18] <ochosi> knome: http://www.zimagez.com/zimage/screenshot-2014-03-25-151742.php
[14:18] <knome> ochosi, why you write "Desktop Settings" in slideshow?
[14:18] <knome> :P
[14:18] <knome> or, Y U
[14:18] <ochosi> did i?
[14:18] <knome> yeah...
[14:18] <GridCube> nice to see you are up to the current internet trends knome 
[14:19] <ochosi> if i did, i meant "Desktop settings"
[14:19] <knome> weirdly enough, it's not translated to finnish...
[14:20]  * ochosi needs coffee
[14:20] <ochosi> bbiab
[14:20]  * knome stubbornly translates
[14:20] <knome> we need more xfce translations downstream
[14:20] <knome> and i need xfce translation access
[14:21] <knome> ochosi, it's in the "app path", so it should be as the item says, not anything additional
[14:21] <elfy> ochosi: when I've gone to ibus settings in the recent past it has had 'use system keyboard layout' ticked
[14:21] <elfy> which is also set in the keyboard settings in settings-manager as US 
[14:22] <elfy> so fiddling with a default isn't going to help
[14:22] <ali1234> yeah so the problem with that sentence is it isn't clear if it means "the infrastructure should not solve irrelevant issues" or "contributors should not solve irrelevant issues"
[14:23] <elfy> ochosi: just checked one of todays installs - concurs with that 
[14:24] <elfy> ochosi: ibus would be fine where it is I suspect if the system keyboard layout was set correctly
[14:47] <slickymasterWork> knome: thanks for the heads up on ubiquity slideshow
[14:47] <slickymasterWork> after uploading it, I'll take a look at the about page
[14:48] <knome> slickymasterWork, after looking at the about page, look at the tour page ;)
[14:48] <slickymasterWork> alright. Anyway what was the problem with the ubiquity pot files?
[14:49] <knome> they were stuck in the import queue
[14:49] <knome> for some unknown reason
[14:50] <slickymasterWork> well, what it matters is that is fixed :)
[14:54] <knome> yep
[14:54] <knome> imports were forced today
[14:55] <knome> i did a few tweets on twitter, those of you who are registered, please retweet:
[14:55] <knome> https://twitter.com/Xubuntu/status/448472539128680448
[14:55] <knome> https://twitter.com/Xubuntu/status/448472851247808513
[14:58]  * slickymasterWork doesn't have twitter
[14:59] <elfy> knome: super - was just about to ask if that had been done :)
[14:59]  * elfy doesn't have twitter either
[15:07] <GridCube> knome, question, in "We'd love to hear about your experiences with Xubuntu. You can share them on the <a href="https://lists.ubuntu.com/mailman/listinfo/xubuntu-users">Xubuntu users mailing list</a>" should i add that its only in english?
[15:08] <knome> yes
[15:08] <knome> that would be fair
[15:10] <cmars> i just discovered the whisker menu. is this new in trusty or am I just a slowpoke?
[15:10] <knome> the whiskermenu is enabled by default the first time in trusty
[15:10] <cmars> perfect
[15:10] <cmars> i must have had an old profile :)
[15:11] <GridCube> :/ i've done the translations but it doesnt accept them
[15:12] <knome> are you in the spanish translation team for ubuntu?
[15:12] <GridCube> probably not
[15:12] <knome> that's why they aren't accepted
[15:13] <GridCube> right
[15:13] <GridCube> i asked to join
[15:14] <knome> yep, cool
[15:19] <slickymasterWork> knome: ubiquity pot file uploaded
[15:19] <slickymasterWork> in https://translations.launchpad.net/ubuntu/trusty/+source/ubiquity-slideshow-ubuntu/+imports its status is Needs Review
[15:20] <knome> slickymasterWork, huh?
[15:20] <knome> po file you mean?
[15:21] <knome> apparently, i can't approve that...
[15:21] <slickymasterWork> do you have any idea of who gets to review the translations? local teams? is there any automatic trigger that launches the review call?
[15:21] <slickymasterWork> yes, I meant po file :P
[15:21] <knome> i've no idea
[15:23] <slickymasterWork> my fear is that the review call might end up lying in Portuguese translators mailing list team
[15:23] <knome> lol
[15:23] <knome> well, poke them
[15:23] <slickymasterWork> and no one will do anything
[15:23] <knome> if they aren't active, apply to be an admin
[15:23]  * elfy lends slickymasterWork his sharp forum poking stick
[15:23] <knome> and approve yourself ;)
[15:23] <slickymasterWork> that team is in some sort of a limb state
[15:24] <elfy> limbo :)
[15:24] <slickymasterWork> thanks elfy ;)
[15:24] <slickymasterWork> +o
[15:24] <elfy> unless it's 'armless ... 
[15:24] <slickymasterWork> in the meanwhile, I'll think I'll copy/paste each string into rosetta
[15:24] <slickymasterWork> at least I'll get things done
[15:25] <knome> elfy, well done
[15:25] <elfy> sorry - had to be done ... 
[15:32] <knome> the pt.po is approved
[15:36] <knome> bbl
[15:37] <slickymasterWork> knome: oddly the po file status is now 'Approved'
[15:37] <slickymasterWork> who the hell approve it? 
[15:37] <elfy> [15:32] <knome> the pt.po is approved
[15:37] <elfy> [15:36] <knome> bbl
[15:38] <elfy> you'd quit 
[15:38] <slickymasterWork> yeah, it's this lousy connectivity I have here :P
[15:39] <slickymasterWork> thanks knome 
[15:39] <slickymasterWork> and thanks elfy, always a gentleman
[15:39] <elfy> welcome as always :)
[15:42] <ochosi> elfy: but the system keyboard is set correctly, you confirmed that with the localectl output
[15:42] <ochosi> and afaik xfce's keyboard-settings have "use system default" as default
[15:45] <elfy> ochosi: yes agreed
[15:45] <elfy> and it used to work fine for me :)
[15:47] <elfy> I'd sya perhaps it's ubiquity - but then wouldn't the greeter want to use US
[15:49] <pleia2> posted call for testing on fb and g+
[15:50] <ochosi> elfy: the greeter uses the system settings and you can't change the layout there
[15:51] <ochosi> but yeah, the only pointer we have so far is that removing ibus fixed things for you...
[15:51] <ochosi> (and that's not very much, tbh)
[15:53] <elfy> pleia2: ta :)
[15:53] <brainwash> not very much? :D
[15:54] <elfy> ochosi: yea :( so - from what I can observe greeter uses system settings - which at that point is GB, then once logged in system sets to US 
[15:54] <ochosi> elfy: that's misleading
[15:54] <ochosi> it doesn't use the system settings once logged
[15:54] <ochosi> in
[15:55] <ochosi> that's exactly your problem
[15:55] <ochosi> it gets overridden by en_US for some odd reason
[15:55] <ochosi> if it would use the system settings (like the greeter), everything would be dandy
[15:55] <brainwash> was the output of localectl already posted?
[15:55] <ochosi> yup
[15:55] <ochosi> http://pastebin.ubuntu.com/7151268/
[15:56] <ochosi> this is it ^
[15:56] <elfy> yes - but if you go look at gui's then once logged in system settings appear as US
[15:56] <brainwash> the xfce keyboard settings dialog?
[15:56] <elfy> yep
[15:57] <brainwash> but xfce is told to use the system default
[15:59] <brainwash> so my system kb layout is DE, but if I create a new user account the user layout is set to en_US (ibus)
[16:03] <ochosi> brainwash: and localectl says DE?
[16:05] <brainwash> ochosi: de, nodeadkeys
[16:05] <brainwash> so yeah, a bit strange
[16:06] <ochosi> so the question is, where does ibus get that info from?
[16:06] <brainwash> accountsservice does save input_sources per user account
[16:06] <brainwash> maybe if that info is missing...
[16:06] <brainwash> like for a new user
[16:07] <elfy> aren't we looking at this the wrong way - why worry about a new user - and not just worry about what someone installing is getting
[16:08] <elfy> also - just did a vm upgrade test, so someone with a perfectly working keyboard set up in 12.04 ends up with a fubar one in 14.04
[16:08] <ochosi> elfy: well i suppose that'd be the same (new user = new install)
[16:09] <brainwash> and we should care about new users too!
[16:09] <brainwash> :D
[16:09] <elfy> mmm - possibly, but a new install is getting information input during install 
[16:11] <elfy> brainwash: I'll care about new users when ones telling the damned thing what they want are ok :p
[16:13] <brainwash> so telling ibus to use the system xkb layout does not help?
[16:14] <elfy> yes it does
[16:15] <elfy> I've said that at some point
[16:15] <elfy> but that is beside the point - as you have to go and do it :)
[16:16] <brainwash> right, we can apply this setting via xubuntu-default-settings
[16:16] <ochosi> yup
[16:16] <brainwash> until we know what is really going on
[16:16] <ochosi> that is one way to deal with it
[16:16] <elfy> ok - so who's going to check all the languages ;)
[16:16] <elfy> s/layouts
[16:17] <ochosi> why would that be necessary?
[16:17] <ochosi> i thought that works generally?
[16:17] <elfy> no idea ochosi 
[16:18] <ochosi> i thought you "said that at some point"?
[16:18] <elfy> or can we set the setting to be whatever the system layout is
[16:18] <elfy> ochosi: I did - I checked for me 
[16:19] <ochosi> nah, using the system layout is the only thing i think
[16:19] <ochosi> i'm not even sure yet how ibus stores its config
[16:19] <elfy> I did try to find something but couldn't 
[16:20] <elfy> if we can do that and it works then that's better than not having ibus
[16:21] <elfy> this whole thing is confusing me completely :)
[16:25] <brainwash> but changing the setting might mess with upgraders who configured ibus to use different input methods
[16:26] <ochosi> brainwash: no, upgraders will always keep their settings
[16:26] <ochosi> we can only set the default anyway
[16:27] <brainwash> no, we are talking about gsettings key
[16:28] <brainwash> if the change the default, it will affect all users who did not alter the key yet
[16:28] <brainwash> if we
[16:28] <ochosi> so ibus stores its settings only in gsettings?
[16:28] <brainwash> yes
[16:28] <ochosi> no rc file or anything?
[16:29] <ochosi> i mean no way to ship a default config for it?
[16:30] <brainwash> I think no, only saw the gsettings stuff
[16:30] <ochosi> :/
[17:23] <elfy> ochosi brainwash - not sure if this is of any interest, had a 12.04 vm, keyboard is set to GB, setup ibus with the chinese layouts available, upgraded to 14.04 - keyboard is now US
[17:23] <elfy> bbl
[17:36] <brainwash> ochosi: we need https://bugzilla.xfce.org/show_bug.cgi?id=9199#c2
[17:38] <ochosi> brainwash: yeah, that looks like it makes sense :)
[17:39] <brainwash> the desktop is pretty messed up right now :D
[17:39] <brainwash> smaller desktop icons, non transparent labels, wrong wallapper
[17:39] <brainwash> "final beta"
[17:43] <brainwash> and I'm not sure what to do packaging wise, wait for a new xfdesktop point release or just apply patches directly, maybe eben revert bad commits
[17:44] <ochosi> well the wallpaper is going to be fixed by the UIFe i guess
[17:46] <brainwash> why is it broken?
[17:47] <brainwash> did you change the path so it's pointing to the trusty wallpaper already?
[17:53] <brainwash> elfy: this needs to be discussed in #ubuntu-desktop and/or -devel
[17:54] <galbi> if install xubuntu 14.04 BETA now will i be able to upgrade to the official release without burning a new iso?
[17:55] <holstein> galbi: yes
[17:56] <galbi> so some day i will receive the notification that a new version is avaiable like when upgrading from previous stable versions
[17:56] <galbi> thanks
[17:56] <holstein> no
[17:56] <holstein> you are already on 14.04.. so, you should just upgrade as you want to upgrade, and get the upgrades
[17:56] <galbi> oh
[17:56] <galbi> even simpler
[17:57] <holstein> sudo apt-get update && sudo apt-get dist-upgrade is what i would be doing, while keeping track of things in..
[17:57] <holstein> !14.04
[17:57] <holstein> ^ #ubuntu+1 channel
[17:57] <holstein> and here, as well
[17:59] <elfy> brainwash: have fun then ;)
[18:50] <jhenke> hi
[18:54] <brainwash> hey jhenke 
[19:58] <brainwash> hey Noskcaj 
[19:59] <Noskcaj> morning brainwash 
[19:59] <dkessel> wow... what is the cause of these new desktop bugs? is the xubuntu-default-settings changes? or could it have been discovered with earlier daily isos?
[19:59] <brainwash> Noskcaj: can you please mark bug 1294600 as wishlist? :)
[19:59] <brainwash> dkessel: what new bugs?
[20:01] <dkessel> brainwash: I mean your message at about 18:39:25
[20:02] <brainwash> sadly we got a bit unlucky
[20:03] <brainwash> the wallpaper one is new, the label one is a recent regression and the icon size problem has not been noticed so far
[20:04] <dkessel> ok
[20:06] <brainwash> https://blueprints.launchpad.net/ubuntu/+spec/xubuntu-t-bugs
[20:24] <ochosi> brainwash: i haven't looked yet, i'll look when the new wall is ready
[20:41] <ochosi> elfy: 're you around?
[20:41] <elfy> yep
[20:42] <ochosi> i just started to talk to attente in #ubuntu-desktop about the ibus bug
[20:42] <ochosi> he hasn't replied yet
[20:42] <elfy> shall I pop in there then
[20:42] <ochosi> i just described a bit what we're seeing so far
[20:42] <ochosi> yes, that was the implication ;)
[20:43] <elfy> I thought so :p
[20:43] <ochosi> just to make sure i don't tell something that's not true :p
[20:43] <ochosi> backlog coming up via PM
[20:43] <elfy> cheers
[20:44] <elfy> ta - and who is attente?
[20:44] <elfy> something to do with a flavour? or?
[20:45] <ochosi> seb128 recommended him
[20:45] <ochosi> no, unity guy i guess 
[20:45] <elfy> ok 
[20:45] <ochosi> (haven't talked to him before)
[20:45] <brainwash> ochosi: <property name="workspace0" type="empty"> ?
[20:46] <brainwash> so you did not change the wallpaper path/filename
[20:46] <brainwash> but the xml structure
[20:47] <brainwash> I'm confused :D
[20:55] <elfy> ochosi: updated 12.04 to 14.04 has old menu still - is that expected?
[20:57] <ochosi> yup
[20:57] <ochosi> panel-layout and personal settings are never overridden by upgrades
[20:57] <elfy> ok - not a problem then :D
[20:57] <ochosi> (unless there's a migration-script, which there isn't)
[20:57] <ochosi> yup
[20:58] <elfy> good
[20:58] <brainwash> right, a script for the first start after the upgrade would be nice
[20:59] <ochosi> not sure
[20:59] <brainwash> to ask the user if the wants to keep his old panel layout or apply the new one
[20:59] <brainwash> if he
[20:59] <ochosi> possible, but not necessary
[20:59] <ochosi> staying out of the way is nice too
[20:59] <ochosi> by default
[20:59]  * elfy lols at ochosi bearing testament to elfy being a whiner :)
[20:59] <ochosi> i'd rather have ali1234's nice panel layout switcher app
[21:00] <ochosi> elfy: you're welcome ;)
[21:00] <elfy> :)
[21:00] <brainwash> ochosi: so what's the issue with the xfdesktop config file?
[21:01] <ali1234> it has completely changed
[21:01] <ali1234> but it also supports the "old" style
[21:01] <ali1234> the new format uses monitor plug names, so you can't make a "default" setup using it at all
[21:01] <ali1234> you have to use the old one, and let it convert it at first startup
[21:01] <ochosi> brainwash: i'll look into that later, still waiting to sort out ibus first...
[21:01] <brainwash> mmh
[21:02] <ali1234> this has "issues" which are quite complex and would take me a few pages of text to explain
[21:02] <ali1234> also you'd need to read the code as well
[21:02] <brainwash> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-default-settings/trusty/revision/143
[21:03] <dkessel> elfy what about the other KB layout bug from saucy that stopped when ibus was removed? don't know if it helps to mention this...
[21:03] <brainwash> it's https://code.launchpad.net/~ochosi/xubuntu-default-settings/xfdesktop_background
[21:04] <brainwash> see the diff
[21:04] <ali1234> that tear-free bug should be "opinion" or "wontfix" as appropriate :)
[21:05] <brainwash> zzzzz
[21:05] <ali1234> we already have tear-free on open source drivers, and opengl X compositing sucks on the proprietary drivers
[21:05] <brainwash> so you don't plan to improve it by implementing an opengl backend? =S
[21:05] <ali1234> hell no
[21:06] <ali1234> it won't get fixed until nvidia supports dri3 and present
[21:06] <ali1234> then we can do tear-free without opengl
[21:06] <ali1234> everything else already has tear-free afaik
[21:06] <ali1234> if you want opengl compositing use compton
[21:07] <ali1234> i think i posted that on the bug already
[21:07] <ochosi> yeah, that'd be one reason to switch to nouveau. broken suspend and broken powermanagement is the downside though :>
[21:07] <ali1234> it doesn't actually fix the problem though
[21:07] <brainwash> it's not about me, it's about improving the user experience by default
[21:07] <brainwash> for everyone
[21:07] <ali1234> opengl compositing won't improve it. it will just make it slower
[21:07] <ali1234> it doesn't actually fix tearing even
[21:08] <ochosi> +1
[21:08] <ali1234> i don't literally mean you brainwash, i mean users in general :)
[21:08] <brainwash> we could integrate compton into xfce, but that's a no-go too
[21:09] <ali1234> the only way to fix it is using present
[21:09] <ali1234> and that isn't supported anywhere yet
[21:09] <ali1234> but it will be
[21:09] <ali1234> and i already implemented it in xfwm
[21:09] <ali1234> so yeah
[21:09] <brainwash> oh, or use Xmir :D
[21:09] <ali1234> i don't think either Xmir or Xwayland support present. but it would be amazing if they did
[21:09] <ochosi> ali1234: do you have a non-nvidia graphics card or did you test it with nouveau?
[21:10] <ali1234> test what?
[21:10] <ali1234> present support?
[21:10] <ochosi> tear-free present with xfwm4
[21:10] <ochosi> yup
[21:10] <ali1234> right, X in trusty has present, but without dri3 present still tears
[21:10] <ochosi> oh
[21:10] <ali1234> so i can test that present support works (because it draws stuff) but it still tears until nvidia supports dri3
[21:10] <ochosi> so you never got to enjoy the full goodness of your patch?
[21:11] <ali1234> currently no drivers support dri3
[21:11] <ali1234> exactly
[21:11] <ali1234> probably keith packard is the only person in the world who could currently get benefit from the patch :)
[21:13] <ochosi> hehe
[21:13] <ochosi> he patched the intel driver for dri3?
[21:13] <ali1234> yes
[21:13] <ali1234> and mesa
[21:13] <ochosi> crap, will take a while to trickle down
[21:13] <ochosi> i remember the present-presentation now
[21:13] <ali1234> yeah
[21:13] <ochosi> i saw it when it was linked on phoronix
[21:13] <ochosi> and he said that he can't look at normal X sessions with tearing anymore now 
[21:14] <ochosi> that made me very very sad
[21:14] <ochosi> :)
[21:14] <ali1234> tearing is annoying but awful slow opengl compositing is worse
[21:14] <ali1234> that's why i stopped using compiz
[21:14] <ochosi> yeah, i never managed to use compton for more than 10mins
[21:15] <ali1234> did i tell you, i got the compton dev to implement hybrid compositing?
[21:16] <ali1234> it uses xrander to compose all the windows, then draws the final result with opengl
[21:16] <ali1234> it actually works pretty well
[21:16] <ali1234> much less tearing, and smaller performance hit
[21:16] <ali1234> but it is kind of a crazy hack
[21:16] <ochosi> oh, what does that to
[21:16] <ochosi> do
[21:16] <ochosi> ah i remember
[21:16] <ochosi> that was your idea from a while ago
[21:16] <ochosi> before the present presentation
[21:17] <ali1234> yeah
[21:17] <ochosi> well crazy hack my ass if it works :)
[21:17] <ali1234> give it a try :)
[21:17] <ochosi> is it released already?
[21:17] <ali1234> it's on the git repo
[21:17] <ochosi> ah
[21:17]  * ochosi checks
[21:18] <ali1234> it's not a perfect solution
[21:18] <ali1234> i'd rather wait for present/dri3 to become available, before i start rewriting huge parts of the compositor
[21:19] <ochosi> it's this one, right?
[21:19] <ochosi> https://github.com/chjj/compton
[21:19] <ochosi> yeah, i understand
[21:19] <ochosi> seems to be the same guy who works on skippy-xd
[21:19] <ochosi> i have never read the code, only heard that it's very hacky
[21:19] <ali1234> yeah, here is the commit: https://github.com/chjj/compton/commit/fbd70e146c6fa46250dc2b435afb347c3cf54539
[21:19] <ochosi> but it would be nice if it were available in xubuntu for installing at least
[21:20] <ali1234> compton is almost identical to xfwm's compositor, except with opengl support added in
[21:21] <ali1234> they're both based on xcompmgr, and so is metacity
[21:21] <ali1234> which is why i could easily implement present: keithp already patched metacity (and he wrote xcompmgr in the first place too)
[21:21] <ochosi> any special build stuff?
[21:21] <ochosi> (for the compton hybrid support)
[21:22] <ali1234> no don't think so, you just need the right runtime options of which there are many
[21:22] <ochosi> hmm ok
[21:22] <ochosi> you wouldn't happen to have a config file?
[21:23] <ali1234> never needed one
[21:23] <ali1234> check compton --help
[21:24] <ochosi> ok
[21:24] <ochosi> ty
[21:25] <brainwash> wow, really feels faster
[21:25] <ali1234> it has about 5 different ways of compositing, you should try them all
[21:25] <ali1234> different ones work better on different cards
[21:25] <brainwash> I like this hybrid one
[21:26] <ali1234> hybrid gives the best experience for me, but it also uses the most CPU by far
[21:26] <brainwash> already switching between workspaces for like a whole minute :D
[21:26] <ochosi> gah, what's the libGL package name in ubuntu again?
[21:26] <ali1234> "sudo apt-get build-dep compton"
[21:26] <ochosi> libgl1-mesa-dev?
[21:27] <ochosi> oh, i didnt realize it was in the 14.04 repos :)
[21:27] <ali1234> apparently it is. probably an old version thugh
[21:28] <brainwash> 2013-11-04 
[21:29] <ali1234> doesn't appear to have it
[21:30] <ochosi> ali1234: you should get the zoom-patch in compton too ;)
[21:30] <ali1234> well the problem is how to tell it to zoom
[21:30] <ochosi> i already miss that one
[21:30] <ali1234> xfwm catches the keyboard shortcuts
[21:31] <ali1234> we discussed adding a dbus interface so that xfwm can request the compositor to zoom in
[21:32] <ochosi> right
[21:32] <ochosi> i forgot about that
[21:32] <ochosi> humm, the hybrid backend still has quite a bit of tearing
[21:32] <ochosi> with e.g. resizing windows
[21:32] <ochosi> will try video-playback next
[21:32] <ochosi> (didn't use any options apart from the backend xr_glx_hybrid)
[21:33] <brainwash> it feels like I'm using a new laptop
[21:33] <ali1234> there are a few options which might affect it
[21:34] <ali1234> but i don't remember all of them
[21:34] <ali1234> i think the stencil buffer was one
[21:34] <brainwash> https://github.com/chjj/compton/wiki/perf-guide
[21:36] <ali1234> yeah that pretty much covers it :)
[21:36] <ochosi> seems like the fullscreen playback is a bit smoother with it
[21:36] <ali1234> for me it moves the tear to very near the top of the screen
[21:36] <ali1234> so it's less noticable
[21:36] <brainwash> http://www.youtube.com/watch?v=ceX18O9pvLs
[21:37] <ali1234> there are better ways to test tearing
[21:37] <ali1234> (and framerate) - ideally you need a 60fps video
[21:38] <ochosi> very high cpu usage is what i get
[21:39] <brainwash> you have to pay the price
[21:39] <ochosi> yeah, but it's so high that even windows move less smoothly than with xfwm4
[21:40] <brainwash> I usually don't move windows
[21:40] <brainwash> but website scrolling is super smooth now too
[21:42] <ochosi> it's worse for me :)
[21:42] <ali1234> /usr/lib/xscreensaver/lcdscrub -no-hb -no-hw -no-vw -no-dw -no-db -no-w -no-b -spread 5 -fps -delay 16000
[21:42] <ali1234> try that
[21:42] <ali1234> it's in xscreensaver-data-extra
[21:43] <ali1234> stuttering and tearing will be *very* obvious
[21:44]  * ochosi installs
[21:44] <ali1234> adjust delay to make it run as close to your refresh rate as possible
[21:44] <ochosi> not sure i have the nerves to tweak compton so much that it works nicely
[21:44] <brainwash> I don't care that much about minimal tearing, rendering just has to be quick
[21:46] <ochosi> yeah, much better with compton
[21:46] <ochosi> ali1234: ^
[21:46] <ochosi> without any compositor i get crazy tearing there
[21:46] <brainwash> it's so funny, I'm used to the slowness of firefox, but now it feels like I'm using chromium with a firefox skin
[21:46] <ochosi> if only it wouldn't swallow my cpu, i guess i could use it
[21:47] <brainwash> the difference is huge
[21:47] <ali1234> you sure it's not just placebo effect?
[21:47] <ali1234> these things can be very subjective
[21:48] <ali1234> it's not really possible to say one is "better" than another in my experience
[21:48] <brainwash> yes, maybe I'm a bit too hyped
[21:48] <ali1234> unless one is perfect and the other isn't
[21:48] <ali1234> and as of yet i haven't seen any perfect compositor
[21:48] <ochosi> i guess part of my problem is that i'm using the external monitor
[21:49] <ochosi> with the internal laptop screen it'd be faster, cause it has less resolution :)
[21:49] <ali1234> (but i have seen fullscreen video playback when it's perfect)
[21:49] <ali1234> external monitor will always tear without present
[21:49] <ali1234> because monitors don't have exactly the same refresh rate. they're not all perfect 60Hz synced
[21:50] <ali1234> but opengl vsync can only be synced to one display
[21:51] <ochosi> it's not a dualhead setup though, laptop monitor is disabled
[21:54] <Unit193> ochosi: No, I never did, saw that someone else had filed one 32 seconds before I checked the bug lists.
[22:00] <knome> slickymaster, magic, my son, magic.. ;)
[22:02] <ochosi> Unit193: link?
[22:02] <elfy> as if by magic, the shokeeper appeared
[22:02] <elfy> s/shopkeeper
[22:02] <Unit193> https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034
[22:03] <Unit193> (Core dev complained about it too.)
[22:03] <elfy> read something about that somewhere
[22:04] <ochosi> Unit193: right, already inprogress, that'll get fixed till release
[22:08] <knome> elfy... is there something you think needs further discussion on the QA cycle thread?
[22:08] <elfy> don't think so 
[22:09] <elfy> pretty sure that nothing has been said since I last read and answered stuff on that
[22:09] <elfy> the spinoff I want libreoffice one is floundering I see
[22:11] <knome> i'm not talking about that
[22:11] <knome> :P
[22:12] <knome> elfy, yeah, nothing has been said since you answered stuff, but i was thinking if you had something you wanted more comments on
[22:12] <elfy> then you're going to have to be specific then - I've been breathing paint solvent all day 
[22:12] <Unit193> ochosi: Not sure at all what you mean, but: https://launchpad.net/ubuntu/+source/indicator-sound/12.10.2+14.04.20140324.is.12.10.2+14.04.20140320-0ubuntu1
[22:12] <ochosi> god, they have to stop with those version numbers...
[22:12] <elfy> knome: oic - I'm not sure, will look at it tomorrow and see if I can pick anything out
[22:12] <knome> elfy, ok, thanks :)
[22:13] <elfy> I'm not pursuing exploratory anymore though - had a chat with Nick 
[22:13] <elfy> well - an e-mail chat :p
[22:13] <knome> lol
[22:13] <knome> and what's with that?
[22:14] <elfy> as I sort of suspected - they went exploratory as they have autopilot ;)
[22:14] <Unit193> ochosi: Yes.
[22:14] <elfy> and everything gets tested regardless
[22:19] <elfy> knome: if I don't do anything else I will try and summarise that thread and the points I think we can move on
[22:21] <elfy> ochosi: so that went quiet in -dekstop
[23:24] <brainwash> ochosi: bug 1297144
[23:25] <ochosi> brainwash: you keep pinging me with bug-numbers, why is that?
[23:26] <brainwash> because you are the one who could/should tell something about these bugs :)
[23:26] <brainwash> it is possible that light-locker gets called twice in this case?
[23:26] <brainwash> on suspend
[23:26] <ochosi> weird bug
[23:27] <ochosi> called twice?
[23:27] <brainwash> 1x via dbus and 1x via xfce4-session
[23:27] <brainwash> if both settings are enabled
[23:28] <ochosi> ah, i wasn't aware
[23:28] <ochosi> uncool
[23:28] <brainwash> light-locker hides the cursor for the current screen
[23:29] <brainwash> just a theory
[23:29] <ochosi> hm, well the problem with the session lock setting is a problem...
[23:29] <ochosi> is this confirmed behavior?
[23:29] <ochosi> (i frankly ignored that setting like forever and never had it ticked)
[23:30] <brainwash> no, I did not test it
[23:30] <brainwash> just trying to find an explanation for the reported bug
[23:30] <brainwash> or some hint
[23:31] <ochosi> tbh i dunno what xfce4-session does on that setting
[23:31] <brainwash> it calls xflock4
[23:31] <brainwash> which calls light-locker-command
[23:31] <ochosi> if it calls xflock then it's possible that light-locker gets called twice
[23:32] <ochosi> meh, i hate that all these options and settings are spread all over the place
[23:32] <ochosi> xfce4-session, xfce4-power-manager
[23:34] <bluesabre0> yeah, its a mess
[23:34] <ochosi> o hai bluesabre0 
[23:34] <bluesabre0> good news though, I think I have solved the parole dvd issues
[23:34] <bluesabre0> testing some stuff now
[23:34] <ochosi> weeee
[23:34] <ochosi> very nice
[23:34] <ochosi> (not that i ever play dvds ;))
[23:34] <bluesabre0> and cooking, so I am kind-of around
[23:35] <ochosi> meh, i got hit by the mkv "can't turn subtitles off" bug today
[23:35] <ochosi> kinda annoying
[23:36] <bluesabre0> indeed
[23:36] <bluesabre0> is there anything else I should be focusing more energy on (besides parole)?
[23:37] <ochosi> good good question
[23:37] <ochosi> bluesabre0: does the lock on suspend thing work for you already?
[23:37] <ochosi> and did you read brainwash's comment above about the setting in xfce4-session?
[23:37] <ochosi> (i'm wondering whether we should patch it out for 14.04 in the sense that we set the checkbox to hide itself)
[23:37] <bluesabre0> ochosi: so here's the thing
[23:38] <ochosi> could be that you were hit exactly by that
[23:38] <bluesabre0> lock-on-suspend on/off does work
[23:38] <bluesabre0> but xfce4-power-manager locks your screen (xflock) when laptop lid is closed
[23:38] <ochosi> meh
[23:38] <bluesabre0> (its an optional item)
[23:38] <ochosi> so many options everywhere...
[23:38] <bluesabre0> but if I suspend from the power dialog, it works as expected
[23:39] <bluesabre0> btw, late-locking is fantastic
[23:39] <ochosi> lock on lid-close is optional in the powerman?
[23:39] <bluesabre0> yeah
[23:39] <slickymaster> knome: in the 'Key Applications' item of http://xubuntu.org/tour/, Abiword is mentioned and Gnumeric doesn't
[23:39] <ochosi> oh yeah, optional
[23:39] <ochosi> found it
[23:39] <ochosi> what a cluttered dialog :)
[23:39] <knome> slickymaster, we probably want to rewrite the tour page completely
[23:40] <slickymaster> within the same structure
[23:40] <slickymaster> ?
[23:40] <bluesabre0> oh yeah, saw another xubuntu install at work today :]
[23:40] <knome> slickymaster, or any
[23:40] <knome> slickymaster, remember we can (and should) use the highlighted sections
[23:40] <ochosi> bluesabre0: would be nice to resolve the mess with the three "lock on suspend" options somehow. we could theoretically keep at least two of them in sync (e.g. powerman and light-locker-settings)
[23:40] <slickymaster> yes
[23:41] <slickymaster> liked the about page
[23:41] <ochosi> bluesabre0: there's already a patch that does that for the screensaver timeouts, theoretically we could incorporate both
[23:41] <bluesabre0> right
[23:41] <bluesabre0> we might consider doing that in the next few days
[23:42] <ochosi> so at least when you open light-locker-settings and powerman, they look the same
[23:42] <ochosi> and then hide the checkbox in xfce4-session-settings
[23:42] <ochosi> and then we'd be "good"
[23:42] <bluesabre0> which checkbox?
[23:42] <brainwash> hiding by default is a bad idea
[23:42] <ochosi> the lock on suspend checkbox
[23:43] <bluesabre0> agreed with brainwash
[23:43] <bluesabre0> works for xubuntu, nowhere else
[23:43] <ochosi> http://www.zimagez.com/zimage/screenshot-2014-03-26-004302.php
[23:43] <ochosi> dunno, it's always a duplication of xfce4-powerman
[23:43] <ochosi> even in u-studio
[23:44] <ochosi> afaik they also use both
[23:45] <ochosi> we could also patch powerman to use the xfce4-session key to save its setting
[23:45] <ochosi> then those two would be in sync always
[23:46] <ochosi> would "look messy" for those that use xfce4-powerman without xfce4-session, but would still work
[23:46] <brainwash> bug 1101982
[23:47] <bluesabre0> oh lovely
[23:48] <ochosi> you mean because i wasn't the first to have that messy idea? :)
[23:48] <ochosi> or because the bug was known for so long?
[23:49] <ochosi> guess we can go ahead and add light-locker-settings as soon as 1.2 is uploaded
[23:49] <brainwash> now we can add light-locker to the affects list :)
[23:49] <ochosi> not yet
[23:50] <ochosi> it hasn't been uploaded yet
[23:50] <ochosi> and it unconditionally locks on suspend atm
[23:50] <ochosi> well yeah, you can add it now if you want
[23:50] <ochosi> but there is no visual indicator of the inconsistency atm in it
[23:51] <brainwash> invisible mouse cursor? :P
[23:52] <brainwash> or do you mean a checkbox in the settings dialog?
[23:54] <brainwash> my test system does not support suspend/hibernate, so I'll just call ll-command twice and see what happens
[23:55] <ochosi> yup, either way, we can ask the tester to check his settings 
[23:56] <brainwash> yes, but first I want to do see if I can verify my theory and then ask the right questions :D
[23:56] <ochosi> sure