[09:50] <slickymaster> good morning all
[09:51] <ochosi> morning
[09:52] <slickymaster> morning ochosi. Good to have you here because I noticed that there's a correction that has to be made to the formatting of http://docs.xfce.org/apps/parole/usage
[09:53] <slickymaster> ochosi: right now the audio section isn't formatted as a title, it's in the continuation of the last paragraph of the DVD section
[09:53] <ochosi> brainwash: i know that currently the screen gets blanked twice, it even gets blanked twice on every display. kinda busy atm so i don't know when i'll really get to looking at the background-setting you mentioned ...
[09:55] <ochosi> slickymaster: thanks, good catch! fixed
[09:55] <slickymaster> ochosi: ^^^^
[09:55] <slickymaster> ochosi: np
[09:55] <slickymaster> knome: ping
[09:56] <ochosi> slickymaster: i just realised now, but we'll have to add a "playback" section to the keyboard shortcuts
[09:57] <ochosi> "Right arrow" > skip ahead 10secs
[09:57] <ochosi> etc
[09:58] <slickymaster> ochosi: you mean another table named playback to that section?
[09:58] <ochosi> yeah, i'm currently working on it
[09:58] <ochosi> thought i'd just quickly chuck it in, it's rather easy to do
[09:58] <slickymaster> ochosi, if you feel like there's already plenty in your hands to deal with, I'll be glad to do it for you
[10:00] <ochosi> slickymaster: actually, yeah, if you can/want... :)
[10:01] <ochosi> i'll have to link you to the section of parole's code though that explains that
[10:01] <slickymaster> ochosi: No worries, I'll do it
[10:01] <slickymaster>  I would appreciate the link
[10:03] <ochosi> they start here: http://git.xfce.org/apps/parole/tree/src/parole-player.c#n2441
[10:04] <ochosi> and: seek_short = 10, seek_medium = 60, seek_long = 600
[10:04] <ochosi> (seconds)
[10:04] <ochosi> as you can see there are more shortcuts that aren't in the docs right now
[10:04] <ochosi> (f for fullscreen)
[10:04] <ochosi> (p for playpause)
[10:05] <slickymaster> ochosi: I'll add those to the already existing tables
[10:07] <slickymaster> ochosi: I'll need just another thing though, the link to bluesabre's dokuwiki. I've lost it :(
[10:09] <ochosi> hehe, no worries
[10:10] <ochosi> slickymaster: http://smdavis.us/doku/doku.php?id=usage&#keyboard_shortcuts
[10:11] <slickymaster> ochosi: thks
[11:30] <brainwash> ochosi: mmh, simply move the first set_background call and use it as fallback if there is no user background set via accountsservice?
[11:31] <brainwash> ochosi: well, currently I simply commented the first call :D
[11:31] <brainwash> out
[11:32] <brainwash> but you will have to fix this, because it does cause the strange unblank behavior on two different systems
[11:33] <brainwash> bug report required?
[11:40] <brainwash> looks familiar -> http://ubuntuforums.org/showthread.php?t=2188790
[11:55] <knome> slickymaster, pong
[11:56] <slickymaster> knome, good morning
[11:56] <knome> g'day
[11:56] <ochosi> brainwash: ok, i'll try to check it a bit later today then ;)
[11:57] <slickymaster> so I've speak with balloons regarding https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1251332 and his opinion is that he should go with 
[11:57] <slickymaster> sudo -i to get to a root prompt and there launch whatever graphical application
[11:58] <slickymaster> knome: so, if there's no objections from you I'll go ahead with that to re-write the documentation
[11:58] <knome> slickymaster, ok
[11:59] <slickymaster> knome: I'll do it then and later on I'll propose a merge
[12:04] <knome> slickymaster, ok, thanks
[12:06] <slickymaster> knome: np
[12:57] <ochosi> brainwash: wanna show me the patch that worked for you?
[13:24] <brainwash> ochosi: there is none yet, I simply commented out the first set_background call
[13:24] <ochosi> that one was actually added to help with nouveau drivers when setting the background...
[13:24] <brainwash> that's obviously not the best solution
[13:25] <ochosi> it's a bit of a tricky situation, not everything seems to work with all drivers
[13:25] <brainwash> I mean the part in the main function
[13:25] <brainwash> to set the background which is specified in the config file
[13:26] <ochosi> which is why i'm a bit hesitant to touch this stuff, i only have one laptop to test things on
[13:27] <brainwash> well, create an extra branch :)
[13:27] <brainwash> I can test it
[13:28] <ochosi> hmpf yeah, all rather time-consuming and much tapping in the dark
[13:34] <ali1234> what's this bug about backgrounds?
[13:38] <ochosi> ali1234: well it's an issue in lightdm-gtk-greeter
[13:38] <ali1234> lightdm always faded nicely from the default background to the user specified one for me
[13:38] <ali1234> i thought it was supposed to do that
[13:38] <ochosi> what greeter are you using?
[13:38] <ochosi> i guess unity-greeter, right?
[13:38] <ali1234> yeah
[13:38] <ochosi> (lightdm-gtk-greeter doesn't fade)
[13:38] <ali1234> what's the difference?
[13:39] <ali1234> i thought unity used lightdm
[13:41] <ochosi> lightdm is the display server
[13:41] <ochosi> the rest are greeters
[13:41] <ali1234> so the greeter is like a modular component?
[13:41] <ochosi> yeah
[13:41] <ali1234> ok, got it
[13:41] <ochosi> the visual component
[13:41] <ochosi> so the lightdm-gtk-greeter was written by ligthdm's author as a reference greeter
[13:41] <ali1234> so who else uses the gtk one?
[13:42] <ochosi> bluesabre and me picked it up and started improving it bit by bit
[13:42] <ochosi> lubuntu i think
[13:42] <ochosi> and maybe even distros outside ubuntu
[13:42] <ochosi> (i think lunar linux, not sure anymore)
[13:43] <ali1234> any reason why we don't use unity-greeter?
[13:43] <ali1234> it's pretty nice...
[13:43] <ochosi> well, firstly it depends on indicators
[13:44] <ochosi> which we couldn't use for ages now
[13:44] <ochosi> basically since they were ported to gtk3
[13:44] <knome> i think -gtk-greeter fits better with our style anyway, at least now that we've worked with it
[13:45] <ochosi> the other thing is that the gtk-greeter is a component we control, so we can also introduce changes that make sense for xubuntu
[13:45] <ochosi> e.g. introducing screen-blanking in case it's used as a lockscreen would be somewhat harder to get into unity-greeter
[13:45] <ali1234> random: if the greeter can read the user's background, can it also read their theme?
[13:46] <ochosi> it can read whatever accountsservice allows
[13:47] <ali1234> accountsservice documentation isn't online except in source form
[13:47] <ochosi> yeah, it's indeed not very well documented (it's been a while since i dealt with it)
[13:48] <ali1234> and the package doesn't include the built docs
[13:48] <ochosi> oh, and the user-wallpaper isn't in accountsservice upstream
[13:48] <ali1234> so pretty much no chance then
[13:48] <ochosi> that's an ubuntu-specific patch that never made it upstream (for whatever reason
[13:48] <ochosi> )
[13:49] <ali1234> so anyway... if we can't fix the double background bug, how about implementing the fade/transition instead?
[13:50] <brainwash> why can't we fix it? o.o
[13:50] <ali1234> well, it sounds like the code is a bit fragile with all different drivers
[13:55] <brainwash> so we should disable the accountsservice part?
[13:57] <ochosi> i'm not sure why we should disable the accountsservice part
[13:57] <ochosi> it's not fragile at all
[13:57] <ali1234> fix it then :)
[13:57] <ochosi> yeah, i said i'll try to do so once i have more time
[13:57] <ochosi> and testing resources are quite limited for me also
[13:58] <ochosi> i already added a patch recently that should improve things, but it seems it doesn't work for everybody
[13:58] <brainwash> I can write a patch (the way I like it to be fixed)
[13:58] <ochosi> sure, go ahead
[13:58] <ochosi> we can do it in a branch and try to get some testing
[13:58] <ochosi> i'm all for fixing things
[13:59] <ochosi> ali1234: fwiw, transitions and fades tend to produce lots of code. be my guest if you wanna submit a patch ;) (you could even use parts of thunar-desktop i guess)
[14:01] <ali1234> is this thing really only 2000 lines of C code?
[14:02] <ochosi> hehe
[14:02] <ochosi> well personally i think if we wanna do fancy stuff like that, we should switch to the html engine
[14:03] <ochosi> or even just fork unity-greeter and make it behave/look the way we want...
[14:03] <ali1234> so every time you change the user selection it changes the background too
[14:04] <ochosi> yup
[14:05] <ali1234> making it do a fade would probably add like 5 lines of code
[14:06] <ochosi> i'm totally happy to test and merge patches ;)
[14:08] <ali1234> i am confused what this is supposed to achieve: http://bazaar.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/trunk/view/head:/src/lightdm-gtk-greeter.c#L1310
[14:10] <ochosi> what do you mean specifically?
[14:10] <ali1234> the if(!matched) part
[14:10] <ochosi> (just as a note in advance: as i mentioned before, we're not the authors of the greeter, we're just maintaining it as it was dropped by robert_ancell a longer while ago)
[14:10] <ali1234> if you type a wrong username, it uses the first user's background?
[14:11] <ochosi> well
[14:11] <ochosi> the thing is: in xubuntu we use the user-list (in e.g. debian they don't they use the user-entry)
[14:12] <ochosi> with the user-list, you could only type a wrong username when using "other"
[14:12] <ochosi> as a few of the last patches by our debian maintainer have shown, we didn't really take care of the user-entry enough
[14:12] <ali1234> actually, i understand it
[14:12] <ochosi> oh, ok
[14:12] <ali1234> it's the initially selected user
[14:14] <ali1234> what if there are no users though?
[14:15] <ali1234> something to test: install in a vm, usermod your UID to <1000, see if greeter crashes
[14:19] <ali1234> is there some kind of testing harness for this?
[14:20] <ali1234> "lightdm --test-mode --debug" apparently
[14:21] <ali1234> indeed, it shows the bug
[14:23] <ochosi> hm
[14:25] <ali1234> so where do you maintain it if upstream dropped it?
[14:25] <ochosi> in the same place, bzr
[14:25] <ochosi> (i meant launchpad)
[14:25] <ali1234> ok
[14:26] <ochosi> lp:lightdm-gtk-greeter
[14:31] <ali1234> what do all the files in /etc/lightdm/*.conf do?
[14:34] <ochosi> you can use them to select the greeter / configure lightdm / configure the greeter/s
[14:34] <ali1234> so how do i make it load ~/Source/lightdm-gtk-greeter/src/lightdm-gtk-greeter
[14:34] <ochosi> so e.g. in /etc/lightdm/lightdm.conf you can select the greeter
[14:35] <ochosi> did you install the greeter?
[14:35] <ochosi> or what setting do you want to change specifically?
[14:35] <ali1234> i want to use the greeter i just built without installing it
[14:36] <ali1234> ah... it needs a .desktop file specially named
[14:38] <ali1234> hmm that's interesting
[14:39] <ali1234> it looks very different with default settings
[14:39] <ochosi> yeah
[14:39] <ochosi> it does
[14:39] <ochosi> lack of icon-theme, gtk-theme etc are the usual issues
[14:40] <ochosi> i considered providing a good fallback gtk-theme
[14:40] <ali1234> it looks ok
[14:40] <ochosi> yeah, could be better though
[14:40] <ali1234> just different
[14:40] <ochosi> and also some fallback icons, to be sure
[14:40] <ochosi> otoh so far no-one has complained about it ;)
[14:41] <ali1234> to be honest i think i prefer the defaults to the way xubuntu configures it
[14:45] <ochosi> fine by me
[14:45] <ochosi> we considered letting greeter-themes even change the UI file
[14:46] <ochosi> in general, it wouldn't be hard to ship multiple configuration files and let the user choose
[14:46] <ali1234> so why does it look different even after make install?
[14:47] <ochosi> because the xubuntu config file isn't in the bzr repo
[14:47] <ali1234> but it is still in my filesystem
[14:47] <ochosi> not sure i get it
[14:47] <ochosi> if you install the greeter, it overwrites the lightdm-gtk-greeter.conf file
[14:48] <ochosi> as in: the one that was shipped with xubuntu-default-settings
[14:48] <ali1234> it didn't
[14:48] <ochosi> then you didn't add prefix=/usr maybe?
[14:48] <ali1234> /etc/lightdm/lightdm-gtk-greeter.conf is unchanged
[14:48] <ochosi> maybe wrong prefix, it should change that file
[14:49] <ali1234> oh i see
[14:49] <ali1234> so it's really reading the config from somewhere completely different because i built it with the wrong prefix
[14:50] <ochosi> yeah, i'd say so
[14:50] <ali1234> yeah, fixed
[14:51] <ochosi> good
[17:11] <skellat> I'm going to have to look at LP Bug 1252800 later today
[17:12] <knome> skellat, new doc package isn't uploaded to trusty yet.
[17:18] <slickymaster> knome: I'm not 100% sure, but apparently no
[17:54] <ali1234> ok, so what exactly is so terrible about simply not making the first call to draw the background?
[17:55] <ali1234> if it fixes some driver bug, what about if we draw a black background here instead
[17:55] <ali1234> and then draw the user or default background later
[17:56] <ochosi> tbh i think the call didn't really help with nouveau
[17:56] <ochosi> so i think we can also look into restructuring that
[17:57] <ali1234> i can't see a reason why just skipping that draw will hurt anything
[17:57] <ali1234> but drivers are weird so who knows
[17:57] <ochosi> yeah, they are...
[17:57] <ochosi> well i'd suggest we work in a branch and then do testing with all drivers we can
[18:00] <ochosi> it's important though to keep in mind that the greeter shall not fail
[18:00] <ochosi> it's too important
[18:01] <ali1234> well the easiest way to guarantee that is to not functionally change it
[18:01] <ali1234> ie by drawing a black pixmap on that first call, and only the first call
[18:01] <ochosi> which is what bluesabre and me have done mostly
[18:04] <ochosi> i can also imagine doing functional changes, as long as there's someone at work who feels confident with that (i don't)
[18:09] <ali1234> @2000 lines of code there's a limit to how many bugs there can possibly be
[18:09] <meetingology> ali1234: Error: "2000" is not a valid command.
[18:09] <ochosi> indeed
[18:10] <ochosi> depending though on what kind of other stuff you involve
[18:10] <ochosi> many of our bugs have been lightdm bugs
[20:03] <elfy> hi sergiobenrocha2 
[20:03] <elfy> knome: sergiobenrocha2 is looking to get more involved with us :) 
[20:03] <knome> hey sergiobenrocha2 
[20:03] <elfy> I've been moving him about freenode ... we've come here now 
[20:04] <knome> welcome
[20:04] <Unit193> Hah.
[20:04] <Unit193> Welcome to another channel!
[20:04] <elfy> quick line from another channel - which sums it up 
[20:04] <knome> why didn't i get that tour?
 elfy: ok, is possible that I create an wishlist in launchpad, and appears in this page, if the feature is good?
[20:04] <elfy> knome: please join #ubuntu+1
[20:05] <elfy> then when you've done that - can you come here :p
[20:06] <knome> lol
[20:06] <sergiobenrocha2> thanks everyone
[20:06] <knome> done
[20:06] <elfy> :)
[20:06] <knome> *that* was all of freenode?
[20:07] <elfy> no - just the bits I dragged sergiobenrocha2 around to 
[20:07] <elfy> he started in #xubuntu 
[20:09] <knome> sergiobenrocha2, we basically just finished creating roadmap
[20:09] <knome> sergiobenrocha2, was there something specific you had in your mind for the wishlist?
[20:09] <sergiobenrocha2> humm, yes, a thing or 2... or more
[20:10] <sergiobenrocha2> to make xubuntu more friendly
[20:10] <knome> would you like to share them with us here or want to keep secrets?
[20:10] <elfy> :)
[20:10] <sergiobenrocha2> haha
[20:11] <sergiobenrocha2> so:
[20:14] <sergiobenrocha2> 1 - create launchers in panel would be more friendly in right-click, it is better to pop-up a configuration window that create a complete launcher, and not only an empty gray icon
[20:14] <knome> sergiobenrocha2, did you know you can drag-and-drop launchers from the menu to the panl?
[20:14] <knome> *panel too
[20:14] <sergiobenrocha2> sorry for english... portuguese is my language
[20:14] <Unit193> Translator standing there ^ ;)
[20:15] <sergiobenrocha2> knome: but it possible to drag-and-drop from whiskermenu? I'm using it
[20:15]  * knome shrugs
[20:15] <knome> i don't use a menu at all, so i don't know
[20:16] <knome> maybe somebody who uses whiskermenu knows
[20:16] <knome> possibly
[20:16] <knome> maybe you should try. :)
[20:17] <sergiobenrocha2> I can drag-and-drop only favorites apps from whiskermenu, like terminal and thunar. Others, in sub-categories, it not possible
[20:17] <knome> you should file a wishlist bug against whiskermenu for that
[20:17] <knome> because it works with the regular xfce menu
[20:18] <sergiobenrocha2> ok
[20:18] <sergiobenrocha2> but whiskermenu is from ppa, how can ubuntu-bug will report that?
[20:19] <knome> i don't think it can... you have to report manually
[20:19] <elfy> do it manually - if you can 
[20:19] <knome> https://github.com/gottcode/xfce4-whiskermenu-plugin/issues?labels=bug&state=open
[20:19] <knome> file a new issue.
[20:20] <sergiobenrocha2> humm, ok
[20:20] <knome> probably tag it with "feature"
[20:24] <ali1234> ochosi: as usual, when i start looking closely at some code, i start to notice it's kinda funky
[20:25] <ali1234> i have a feeling this thing leaks a display-sized xlib surface every time it changes the background
[20:25] <ali1234> the set_background code also does a bunch of surface setup, before which things may not work properly
[20:32] <sergiobenrocha2> I created the issue
[20:33] <sergiobenrocha2> but I can not see, if i click in "Issues" tab
[20:33] <sergiobenrocha2> it's the number 37
[20:34] <sergiobenrocha2> oh, ok, not worry
[20:40] <ali1234> confirmed, lightdm-gtk-greeter leaks memory like crazy.
[20:43] <brainwash> ali1234: surprise? :)
[20:43] <ali1234> never :(
[20:43] <brainwash> so you plan to fix the background part?
[20:43] <ali1234> i'm not sure i want to touch this code
[20:44] <ali1234> all this background stuff is related
[20:44] <ali1234> the only easy fix is to replace that first sat_background() with something like clear_background() which will just clear it to black but otherwise do the exact same as set_background
[20:45] <ali1234> ie all the memory leaking and stuff
[20:45] <ali1234> the alternative is to rewrite it so that allocation and drawing are separate
[20:45] <ali1234> this would fix both problems
[20:45] <ali1234> but it's a quite big refactoring
[20:46] <brainwash> allocation of the background image?
[20:46] <ali1234> and i'm not sure if i really care for something i see for 10 seconds twice a month
[20:46] <ali1234> so, when the greeter starts up it makes a pixmap which is the background
[20:46] <ali1234> actually, set_background() does this
[20:47] <ali1234> it creates a xlib pixmap, then draws the background into it with cairo
[20:47] <ali1234> but the problem is that the next time you call it, it makes another new pixmap and does not free the old one
[20:47] <brainwash> yes, but the greeter does it twice, if accountsservice provides an user background
[20:47] <sergiobenrocha2> I accidentally created a duplicate, but I changed it to an another issue, it is Issue #37. Can someone take the duplicate label?
[20:47] <ali1234> yes, it does it every time you select a different user from the list
[20:48] <brainwash> right
[20:48] <ali1234> if you sit and click different users you can make it leak hundreds of mb if you are patient
[20:48] <brainwash> no one does that
[20:48] <knome> ali1234, we would be grateful if you fixed that
[20:49] <ali1234> brainwash: could be a security vuln, i dunno...
[20:49] <ali1234> who knows what happens if the display is locked and you crash lightdm...
[20:49] <ali1234> anyway the thing is, it has to allocate and leave allocated that pixmap
[20:49] <ali1234> it might even be necessary that the pixmap exists before you start doing gtk stuff
[20:50] <brainwash> the background won't change if the screen is locked via greeter
[20:50] <ali1234> this might be the nouveau bug that was mentioned
[20:50] <ali1234> so this means you can't just defer drawing the background, because it also *creates* the background
[20:51] <brainwash> I simply want this bug to be fixed -> bug 1251431
[20:51] <brainwash> this also fixes the light-locker issue for me
[20:51] <ali1234> what does?
[20:52] <brainwash> ochosi made a change, so that light-locker blanks the screen after locking it
[20:52] <brainwash> it only works for me, if the background is set only once
[20:53] <ali1234> right yeah, that makes sense
[20:53] <ali1234> you know what i said about those pixmaps getting leaked?
[20:53] <brainwash> uhm, it's bad
[20:53] <ali1234> well, i bet the patch he made expects there to be only one
[20:53] <ali1234> so it hides the top one
[20:53] <ali1234> but there's still a stack of leaked ones behind it
[20:53] <ali1234> so to fix *that*
[20:54] <ali1234> requires the "proper" (but harder) fix of refactoring this thing
[20:54] <brainwash> I mean this here "XForceScreenSaver(display,ScreenSaverActive);"
[20:55] <brainwash> called twice unblanks the screen
[20:56] <brainwash> at least for me
[20:56] <brainwash> on two different systems
[20:56] <ali1234> yeah
[20:56] <brainwash> not this particular line, but the code part
[20:56] <ali1234> hmm
[20:56] <ali1234> no sure what you mean really
[20:56] <brainwash> the communication with X
[20:57] <ali1234> the thing is that all those leaked background pixmaps persist after the greeter exits
[20:57] <brainwash> yes, but that's not related to the blanking issue :)
[20:57] <ali1234> well, why did you mention it then?
[20:58] <brainwash> it's related to bug 1251431
[20:58] <ali1234> ok. i don't understand how it is related...
[20:58] <brainwash> so we really need to cleanup the code
[20:59] <ali1234> unless you mean it's related in a general sense of "this code sucks and has lots of problems"
[20:59] <ali1234> which is fair enough
[20:59] <brainwash> take a look at the create_root_surface function
[21:00] <brainwash> this function contains the line to blank the screen (after locking it)
[21:00] <brainwash> so it behaves like xscreensaver
[21:00] <ali1234> yeah
[21:00] <brainwash> if you call set_background, you also call create_root_surface
[21:01] <ali1234> ok...
[21:02] <brainwash> and this is bad, because my screen does not remain blanked
[21:02] <ali1234> ok, see that's where you lost me
[21:02] <brainwash> if I call set_background only once, it works
[21:02] <brainwash> screen stays blanked
[21:02] <ali1234> ok, so on startup you mean
[21:02] <brainwash> right
[21:03] <ali1234> startup after yu pressed "lock screen" that is
[21:03] <brainwash> yes
[21:03] <brainwash> the normal screen lock does no allow user switching anyway
[21:03] <ali1234> yeah but that's irrelevant
[21:04] <ali1234> the problem is it sets the background to default, then creates a bunch of widgets, then sets background to the user one
[21:04] <brainwash> so... we can fix many problems with a code cleanup :D
[21:04] <ali1234> but it can't get the user background until after it did all that widget stuff
[21:05] <brainwash> can't we set the background to default only as fallback option, if the user background is not available?
[21:05] <ali1234> yes
[21:05] <ali1234> but that means defering it
[21:05] <ali1234> until after the point where we usually load the user background
[21:05] <brainwash> yes, won't hurt or?
[21:06] <ali1234> well, it might do, because there's no root pixmap until after set_background
[21:06] <brainwash> currently I've simply commented the default background call out
[21:06] <ali1234> yes
[21:06] <ali1234> actually what you need to do is move the set_background to...
[21:07] <brainwash> yeah
[21:07] <ali1234>     if (lightdm_greeter_get_hide_users_hint (greeter))
[21:07] <ali1234> which is much further down the functions
[21:07] <ali1234> around 1890
[21:08] <brainwash> the solution is quite easy
[21:09] <ali1234> go on...
[21:09] <brainwash> looks like you are very interested in fixing this :D
[21:09] <ali1234> it's fairly simple to fix, just a lot of refactoring
[21:10] <brainwash> you are more skilled, I would mess up and break the code :/
[21:10] <ali1234> that's the problem with refactoring things
[21:11] <ali1234> that's why nobody ever wants to do it
[21:11] <brainwash> usually you have some tests to verify the functionality
[21:13] <brainwash> but I'll try to write a patch later (to at least provide a fix for my bug report)
[21:13] <ali1234> part of the problem is that it doesn't just use one pixmap
[21:13] <ali1234> it makes one per screen
[21:13] <ali1234> so then you have to have an array to keep track of them
[21:14] <ali1234> and you have to handle screens getting added and removed
[21:14] <brainwash> ouch
[21:14] <ali1234> currently it does none of this, it just blasts all over whatvever exists "right now" and then leaks it
[21:15] <brainwash> what about the unity-greeter? is it more mature?
[21:15] <ali1234> dunno. it's vala, and huge
[21:15] <brainwash> it's written in vala 
[21:15] <brainwash> yes
[21:15] <ali1234> i'd rather fix this code i think
[21:15] <ali1234> i bet unity-greeter has just as many problems
[21:19] <ali1234> actually it's even worse than i thought, because it disconnects from the xserver after dumping the pixmap on it
[21:19] <ali1234> so if you keep a reference to it, it can go invalid without warning
[21:20] <ali1234> this is really hairy...
[21:20] <knome> elfy, ping
[21:21] <brainwash> you should ge a cup of coffee
[21:21] <brainwash> get
[21:21]  * genii readies the coffeepot
[21:21] <ali1234> i just realised this while i was brewing some tea
[21:21] <elfy> s'up knome 
[21:21] <knome> elfy, you worked with the community wiki i assume?
[21:21] <knome> elfy, the community *help* wiki
[21:21] <elfy> once or twice
[21:22] <knome> elfy, aha, okay
[21:22] <knome> elfy, i still might need your opinion..
[21:22] <elfy> well - that was a figure of speech :) quite a bit :)
[21:22] <knome> but i'll get back to you later on that
[21:22] <knome> lol
[21:22] <knome> haha, in that case
[21:22] <knome> i'll get to you now :)
[21:22] <elfy> lol
[21:22] <knome> noticed i took a work item on refreshing the frontpage?
[21:23] <knome> https://help.ubuntu.com/community/FrontPageRefresh
[21:23] <knome> that's a brief start
[21:23] <knome> i'm starting with trying to see what kind of stuff would be best grouped together
[21:23] <elfy> ok 
[21:24] <knome> how up-to-date is the NewDocs page?
[21:25] <elfy> pretty much worked on constantly 
[21:25] <knome> and why that name and not MostPopular or sth
[21:25] <elfy> god only knows 
[21:25] <knome> lol
[21:25] <knome> also,
[21:25] <knome> do you think the alphabet-pages could have some kind of shared banner
[21:25] <elfy> last post in the thread a bunch of people working on newdocs was 4 days ago 
[21:25] <knome> to link back to the frontpage (NewDocs) and the rest of the alphabets
[21:26] <knome> gtg, brb
[21:26] <elfy> talk to slickymaster about that newdocs thingy - he'll have an idea
[21:41] <knome> okay
[21:42] <elfy> he's done a lot of work with those doing that page
[21:42] <elfy> but what was it you wanted from me?
[21:45] <knome> well, comments about my page
[21:45] <knome> and if you had other ideas and insight what would be useful on the front page, and if there is something you think could be dropped
[21:45] <elfy> ok 
 do you think the alphabet-pages could have some kind of shared banner
[21:46] <knome> i'm definitely not forcing any layout or changes that people who are familiar with the wiki do not think are useful, and open to all suggestions
[21:46] <elfy> what did that refer to? the newdocs thing?
[21:46] <knome> yep
[21:47] <knome> all the pages could have a banner that said "Popular posts" and then list all the alphabets
[21:47] <elfy> I'd imagine the only reason it hasn't is that no-one has either not bothered yet - or can't 
[21:48] <knome> lol
[21:51] <elfy> I've bookmarked your new page - I'll look tomorrow afternoon when I get back 
[21:52] <elfy> but - the current page definitely needs a revamp :)
[21:54] <ochosi> ali1234: there is another greeter based on lightdm-gtk-greeter
[21:54] <ali1234> elfy: on the subject of the wiki and specifically that triage page - i think the descriptions of what bug statuses mean should be removed from that page and merged into Bugs/Status (which is linked near the bottom)
[21:54] <ochosi> it might have some of those issues fixed
[21:55] <knome> eewh, surge protection
[21:55] <ali1234> ochosi: oh? where is it?
[21:55] <ochosi> ali1234: here https://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CDIQFjAA&url=https%3A%2F%2Fgithub.com%2Fkalgasnik%2Flightdm-another-gtk-greeter&ei=TN6LUo0WjNfsBoibgegI&usg=AFQjCNHD3XUgYZOkNz9mE_foxPUMSomhlg&sig2=L2mGPe5-4j1kK_ohW2SGaQ&bvm=bv.56643336,d.ZGU
[21:55] <ochosi> gah
[21:55] <ochosi> sory
[21:55] <knome> ochosi, well done
[21:55] <ochosi> yeah :(
[21:55] <ochosi> ali1234: https://github.com/kalgasnik/lightdm-another-gtk-greeter
[21:56] <ochosi> ali1234: i've also gotten in touch with the author, because the changes seemed quite vast and i'm not sure we'd want all of that
[21:56] <ali1234> hmm yes looks like it has some changes with how screen backgrounds work
[21:56] <ochosi> he replied he might help but he was busy and haven't heard back since
[21:56] <ali1234> well, i can try to port his fixes
[21:57] <ali1234> did you read all my ranting?
[21:58] <ali1234> do you happen to know what revision he forked from?
[21:59] <ali1234> https://github.com/kalgasnik/lightdm-another-gtk-greeter/commit/a21a7e15e77d54fc36042f3589a34193c7d65841#diff-803c5170888b8642f2a97e5e9423d399L129
[21:59] <ali1234> typing in wrong window is bad...
[22:01] <ali1234> wait, is this even a fork?
[22:02] <ochosi> yeah, i read all your rants
[22:02] <ali1234> this code has no resemblance to lightdm-gtk-greeter at all
[22:02] <ochosi> but as i said, i'm not the author and didn't feel comfortable with fiddling with the bits and pieces too much
[22:03] <ochosi> (or at least with the larger bits and pieces)
[22:03] <ali1234> yeah i can't blame you for not wanting to change anything in this code
[22:03] <ali1234> *i* don't want to either
[22:03] <ochosi> it mostly worked so far
[22:03] <knome> elfy, the wiki is impossible to edit!
[22:03] <ali1234> the way it works is a nasty brutal hack
[22:03] <ali1234> it works... no more, no less
[22:03] <ochosi> so we started ironing out some stuff
[22:03] <ochosi> and improved the looks
[22:03] <ochosi> that's pretty much where it is now
[22:03] <elfy> knome: why do you think I said once or twice
[22:04] <knome> ;)
[22:04] <elfy> I hate the wiki :)
[22:04] <ochosi> +1
[22:04] <knome> ochosi, i'm talking about a different wiki!
[22:04] <ochosi> i've started to consider making small previews of the background-submissions just to make the page-loading more bearable
[22:04] <elfy> and don't whatever you do logout of it - it takes a week of sundays to log back in ... 
[22:04] <knome> ochosi, i considered the same thing actually
[22:05] <knome> ochosi, and maybe we simply should do Incoming and Accepted
[22:05] <ochosi> wouldn't take very long to do it
[22:05] <ochosi> yeah, as i suggested once...
[22:05] <knome> no, not really
[22:05] <ochosi> ok, how then?
[22:05] <knome> and i said go ahead if you think that's what we need
[22:05] <knome> and then you were "meh"
[22:05] <ochosi> yeah, but i wanted to wait for pleia2 actually
[22:05] <knome> "wouldn't take very long to do it" -- "no, not really" 
[22:06] <elfy> knome: can you at some point soon - check the LTS pending blog, fiddle with it if necessary and get it published :)
[22:06] <elfy> not too worried about the other one
[22:06] <ochosi> knome: the good part of that distinction would be that the not-yet-accepted ones would be more visible
[22:06] <knome> ochosi, yes
[22:06] <elfy> right - I'm off now - back tomorrow
[22:07] <ochosi> ali1234: fwiw, i never got around to really testing that other greeter, feature-full as it might be
[22:07] <knome> ochosi, and we could have a naming scheme for the files that makes it easier to handle them
[22:07] <ochosi> ok, i'll start setting up an accepted-page
[22:10] <ochosi> knome: ok, so are there any submissions you wouldn't accept so far for some reason? (apart from the ones with license-issues)
[22:10] <knome> i don't think there is any reason to decline any other at this point
[22:10] <ochosi> yeah, i agree
[22:10] <ochosi> so, naming-scheme
[22:11] <ochosi> easiest is title. but title_author would also work
[22:12] <knome> could even be author_title
[22:12] <ochosi> yeah
[22:12] <ochosi> true, there are many that submitted more than one
[22:12] <knome> titles are just arbitrary... titles
[22:17] <knome> ochosi, i would also make a note to the accepted page that those wallpapers are accepted *submissions*, and that there is no promises of them getting into the release, and that people shouldn't edit that page directly
[22:18] <ochosi> yeah
[22:20] <ochosi> knome: feel like doing a few thumbnails? ;)
[22:21] <knome> send me all the files and i'll batch-convert them.
[22:21] <ochosi> that'll take ages with my connection
[22:22] <ali1234> ochosi: did you add all the "is_locked" stuff?
[22:22] <ochosi> ali1234: yeah, in the last commit (or the one before that)
[22:22] <knome> ochosi, heh.
[22:22] <ali1234> is it's only purpose to trigger the XForceScreenSaver in create_root?
[22:23] <knome> ochosi, what do you want me to do then?
[22:23] <ochosi> ali1234: yeah. the main issue was that i didn't want to write another function to cycle through all displays...
[22:23] <ochosi> knome: download the pics yourself, man! :)
[22:24] <ali1234> ochosi: well my concern is it can only ever be called on gdk_display_get_default() anyway
[22:24] <ali1234> which should always be the same thing
[22:24] <ali1234> so why not just call it once, from main()?
[22:24] <ochosi> sounds quite plausible :)
[22:24] <ali1234> then every instance of is_locked can be removed
[22:25] <knome> ochosi, all of them?
[22:25] <ochosi> knome: all of the accepted ones
[22:25] <knome> uh
[22:25] <knome> what have you done so far?
[22:25] <ochosi> knome: i'm still in process of moving/renaming them
[22:25] <knome> okay
[22:25] <knome> so do you want me to do that once you've moved?
[22:26] <ochosi> as you wish, i mean basically you already know which ones i'm gonna move
[22:26] <knome> well if the moving is fine for you, it's easiest for me to just grab * from one page
[22:27] <ochosi> that's also ok
[22:27] <knome> ok, good
[22:27] <knome> let me know when you're done
[22:27] <ochosi> basically the renaming is the more annoying part
[22:27] <ochosi> sure
[22:31] <ali1234> ok does someone want to try lp:~a-j-buxton/lightdm-gtk-greeter/experimental
[22:31] <ali1234> i think this will fix the locking thing, but not the double drawing background
[22:31] <ali1234> i might be totally wrong though
[22:31] <ochosi> sure, i'll do that as soon as i've finished the monkey job in the wiki...
[22:32] <ali1234> hmm... want a script for that?
[22:33] <ochosi> hm, if you can include creating thumbnails, sure! :)
[22:33] <ali1234> not a problem. what exactly do you need to do? download all submitted images and thumbnail them?
[22:34] <ochosi> that's the one part, the more annoying part is moving some of the submissions to the accepted-page
[22:34] <ochosi> and rename them to author_title
[22:34] <ochosi> so that's hard to script
[22:35] <knome> probably best to suffer of it once
[22:36] <knome> after that it's one or two per time
[22:37] <ochosi> yeah, i mean the script for downloading images and creating thumbs might still be handy
[22:38] <knome> well blah :)
[22:38] <ochosi> i also hate the plaintext links
[22:38] <ochosi> might fix that later
[22:49] <ali1234> did you just delete a bunch of stuff from the page?
[22:49] <pleia2> ochosi is destroying my inbox
[22:51] <ochosi> pleia2: sorry ;)
[22:51] <ochosi> maybe it's time to set up some filter-rules? 
[22:51] <ali1234> why is there an application_octet-stream attached to the page?
[22:51] <ochosi> ali1234: yeah, not sure, it's just now getting easier to see all the attachments
[22:51] <ochosi> knome: i think i'm done
[22:52] <knome> ochosi, i'll get to that soon. i need to fix something else first ;)
[22:52] <pleia2> ochosi: normally I want to see :) I just keep getting notifications, whee
[22:52] <ochosi> pleia2: sorry, but the cleanup was direly needed...
[22:53] <pleia2> I know, I kid anyway
[22:55] <ochosi> ali1234: hehe, that octet stream looks like a debian wallpaper
[22:55] <ochosi> http://www.zimagez.com/zimage/screenshot-11192013-115531pm.php
[22:56] <knome> pleia2, i'm the next one to spam your inbox
[22:56] <ali1234> i like it
[22:58] <ochosi> yeah
[22:58] <ochosi> nice'n'spacey
[22:58] <ochosi> pity that there's no author etc
[23:00] <knome> pleia2, ready for another round of spam?
[23:00] <knome> pleia2, ready or not, here it comes
[23:01] <pleia2> si
[23:04] <ochosi> ali1234: ok, locking and blanking still works
[23:04] <ochosi> so far so good
[23:07] <ochosi> ali1234: the fun thing is i wanted to implement it like that in the beginning, but then i somehow thought i have to force the screensaver for each display separately
[23:08] <ali1234> display/screen confusion
[23:08] <ali1234> easily done
[23:08] <ochosi> yeah
[23:08] <ochosi> :/
[23:08] <ochosi> well, thanks!
[23:08] <ochosi> if you could submit it as a merge-request, i can merge it in
[23:09] <ali1234> though i'm not sure why you get away with calling it multiple times for each screen, but calling the whole loop more than once breaks
[23:09] <ali1234> unless of course you never tested on multiscreen :)
[23:09] <ali1234> yeah i can mr it
[23:09] <ochosi> i have a dualhead setup here
[23:10] <ochosi> so that might fix blanking for brainwash hopefully
[23:10] <ali1234> http://paste.ubuntu.com/6445334/
[23:10] <ochosi> knome: ^
[23:11] <knome> they are already uploaded
[23:11] <ali1234> this only downloads and thumbnails them anyway :)
[23:11] <knome> i'm just laying out the page
[23:12] <ochosi> i think i'll keep the download-part of that script around, we could attach a tarball with all backgrounds for convenience
[23:13] <bluesabre> ah
[23:13] <bluesabre> good ol BeautifulSoup
[23:13] <ochosi> hey there bluesabre 
[23:13] <ali1234> it will probably crash if there's anything "not an image" attached to the page
[23:13] <bluesabre> when it works, it works well
[23:14] <ali1234> or if someone uploads an image named "do=view&.jpg"
[23:14] <ali1234> actually probably not since it would be escaped
[23:14] <bluesabre> that would be only slightly evil
[23:14] <ochosi> in what package would i find that beautiful soup?
[23:15] <ali1234> python-beautifulsoup
[23:15] <ochosi> gah, i was looking in libpython
[23:15] <ochosi> i'll start testing the wallpapers then
[23:16] <ochosi> just have to add a rm *_250.jpg
[23:17] <ochosi> ali1234: you wouldn't know anything about using the X11 dpms extension?
[23:17] <knome> ochosi, https://wiki.ubuntu.com/Xubuntu/Roadmap/Specifications/Trusty/CommunityWallpapers/Accepted
[23:18] <ochosi> knome: fail: juergendonauer_walkingfishermaninthesunset.jpg_250
[23:18] <knome> fixed already you stupid
[23:18] <knome> :P
[23:18] <bluesabre> lol
[23:18] <ochosi> oh sure, pin it on me! :D
[23:19]  * knome pins
[23:19] <ochosi> damn
[23:22] <ali1234> ochosi: i didn't know anything about any of these things before i started digging :)
[23:23] <ochosi> ali1234: hehe, well same here ;) anyway, thing is that that would be the preferred blanking of the screen, the standby of the display
[23:24] <ali1234> so you want the screen to turn off when it does XForceScreenSaver?
[23:24] <ochosi> yeah
[23:24] <ochosi> cause the VT-switch cause the screen to switch off for a second
[23:24] <ochosi> so ideally it would stay that way
[23:24] <ochosi> instead of "waking up" only to stay blank
[23:26] <ali1234> DPMSForceLevel?
[23:26] <ali1234> http://ftp.x.org/pub/X11R6.9.0/doc/html/DPMSForceLevel.3.html
[23:27] <ochosi> knome: set xfdesktop to change the wallpaper to one of the submissions ;)
[23:27] <ochosi> ali1234: yeah, i'd try DPMSForceLevel(display, DPMSModeOff);
[23:27] <knome> ochosi, huh:P
[23:27] <ochosi> but from what i heard, there are multiple dpms extensions for X11
[23:27] <ali1234> i have no idea how to test this stuff - screensaver/locking is horribly broken here, i had to remove all of it
[23:27] <ochosi> so i started to be a bit doubtful of what would work, it also adds an extra dependency
[23:28] <ochosi> what are you using now?
[23:28] <ali1234> the monitor power switch
[23:28] <ochosi> the proposed solution for xubuntu is light-locker
[23:28] <ochosi> haha
[23:28] <ochosi> that one also wouldnt need the dpms patch i guess
[23:29] <ali1234> for some reason the display still goes blank after a time, but does not turn off
[23:29] <ochosi> well those are different things afaik
[23:29] <ochosi> blanking and standby
[23:29] <ochosi> with potentially different timeouts
[23:29] <ochosi> check "xset q" for your local settings
[23:29] <ali1234> they're all disabled in the control panels
[23:30] <ali1234>   Standby: 0    Suspend: 0    Off: 0
[23:30] <ochosi> not sure what those control panels you're referring to control
[23:30] <ochosi> and in the screensaver part?
[23:30] <ali1234> me either
[23:30] <ali1234> there is no screensaver part
[23:30] <ochosi> rly?
[23:30] <ochosi> funny
[23:30] <ali1234> oh wait
[23:30] <ali1234> timeout: 600
[23:30] <ochosi> that's it
[23:30] <ochosi> 10min
[23:31] <ochosi> a bit short for my taste, but ok
[23:31] <ochosi> so if you enable standby, it'll shut off the backlight of the monitor
[23:31] <knome> bbl
[23:31] <ochosi> (or was it suspend that did that, i'm always confused by those two namings...)
[23:34] <ochosi> bluesabre: btw, i noticed that the parole-docs don't cover the "hidden" playback-shortcuts yet (arrow-keys etc), slickymaster agreed to add them
[23:34] <bluesabre> oh yeah
[23:34] <bluesabre> :D
[23:35] <ochosi> cause those are actually quite important in the docs, as they're not easily discoverable
[23:35] <bluesabre> right
[23:53] <ochosi> ali1234: because you mentioned cross-fading would be only 5 lines, what method would you use exactly?
[23:53] <ali1234> set a timer, draw the background multiple times
[23:53] <ali1234> that was before i really looked at the code though
[23:53] <ali1234> doing this would be a terrible idea since each time you draw the background it leaks a pixmap
[23:56] <ochosi> that just means we have to make our default wallpapers lean ;)
[23:56] <ali1234> no
[23:56] <ali1234> the pixmap is monitor sized
[23:56] <ali1234> contents don't matter, it's not compressed
[23:56] <ali1234> this is what create_root does
[23:57] <ochosi> true (i was kinda kidding there)
[23:57] <ali1234> specifically the pixmap it creates doesn't get freed - by design
[23:57] <ali1234> i'm reading all about RetainPermanent at the moment
[23:57] <ochosi> yeah, that might've been robert_ancell's idea then
[23:57] <ali1234> i can see why it's done
[23:58] <ali1234> if you only set the background once it makes perfect sense
[23:58] <ochosi> yeah, which originally was the case
[23:58] <ali1234> because it stays around after the greeter exits
[23:58] <ochosi> the background-switching was introduced by us (mr_pouit)
[23:58] <ali1234> but if you change the background, you're making a new one each time, and they all stay
[23:58] <ochosi> maybe best to check what unity-greeter does
[23:59] <ochosi> as it also shows user-wallpapers
[23:59] <ali1234> change the background 100 times and you leak 1GB
[23:59] <ali1234> maybe it would be better to only do this RetainPermanent thing once when the greeter exits