[00:08] <slickymaster> cy tomorrow guys
[00:08] <Unit193> Bye.
[00:08] <slickymaster> Unit193, ;)
[00:22] <ochosi> brainwash: no worries, just let me know when you do get to it
[02:41] <bluesabre> ochosi, ali1234: thoughts? https://code.launchpad.net/~smd-seandavis/lightdm-gtk-greeter/gtk_image_background
[02:42] <bluesabre> it seems to work for me, nouveau and nvidia-proprietary
[02:42] <bluesabre> oh crap, missed a line that I needed to fix
[02:43] <bluesabre> but yes, should still work ;)
[02:44] <bluesabre> fixed
[03:05] <bluesabre> make
[03:05] <bluesabre> woops
[03:08] <pleia2> make: *** No targets specified and no makefile found.  Stop.
[03:08] <bluesabre> :D
[03:08] <pleia2> :D
[03:09] <bluesabre> that command took forever to execture
[03:09] <bluesabre> or execute
[03:09] <bluesabre> not even sure what execture is
[03:09] <pleia2> slow channel
[03:16] <micahg> so, that's it, no XMir for 14.04
[03:18] <Unit193> Yes indeedio, I saw this.  Means I'm useless again.
[03:20] <Unit193> (And I quite agree with that, no unstable and very new *display server* for a LTS.)
[03:21] <holstein> i thought it was kind of cavalier
[04:59] <micahg> Unit193: I'm sure we can find another project for you to spearhead ;)
[09:32] <ochosi> bluesabre: hihi, you pushed your config-file :D
[09:40] <ochosi> ali1234: i think on top of bluesabre's branch it'll be much easier to implement the fading in the greeter
[09:56] <slickymaster> morning all
[09:56] <ochosi> morning slickymaster 
[09:57] <slickymaster> ochosi: and a good one to you
[09:57] <ochosi> ta
[10:08] <slickymaster> knome: FYI https://code.launchpad.net/~slickymaster/xubuntu-docs/xubuntu-docs/+merge/196213
[10:43] <knome> slickymaster, ta, will get to that later
[10:43] <slickymaster> knome: tk
[10:44] <knome> elfy, ping
[10:52] <ali1234> ochosi: the RetainPermanent stuff is there for a reason
[10:52] <ali1234> it's supposed to ensure the background stays there between lightdm -> desktop transition
[10:53] <ali1234> ideally what we want to do is draw a gtk image until lightdm is going to quit, then dump the image to the root pixmap once just before exiting
[10:53] <ochosi> yeah, that sounds like a plan
[10:54] <ali1234> however this doesn't necessarily fix the crashing on nouveau
[10:54] <ali1234> otoh it isn't necessarily the cause either
[10:55] <ochosi> well bluesabre mentioned that his gtkimage branch worked with nouveau
[10:55] <ochosi> so we could hope that it really helps
[10:56] <ali1234> yeah but he removed the RetainPermanent stuff
[10:57] <ochosi> oh
[10:57] <ochosi> that has to be added back then
[10:57] <ali1234> yes, at least for a test
[11:04] <bluesabre> ah
[11:04] <bluesabre> I can add that back
[11:05] <bluesabre> but this should at least eliminate the glitches for when sitting at the login screen
[11:05] <ochosi> sounds good
[11:06] <bluesabre> (also fixes the crazy memory leak)
[11:06] <bluesabre> but, I suppose I'll be adding that back with the RetainPermanent code
[11:06] <ochosi> yeah, i think we can merge that branch pretty soon :)
[11:07] <ali1234> bluesabre: it has to be not just added back, but reworked so it only gets called once at the very end, instead of at the start
[11:07] <bluesabre> ah
[11:07] <bluesabre> I see
[11:07] <bluesabre> that makes sense
[11:07] <ochosi> yeah, so the leak would indeed be fixed
[11:08] <ali1234> not necessarily
[11:08] <ali1234> well, yes, the *leak*
[11:08] <ali1234> but not necessarily the display corruption/crashing
[11:08] <ali1234> because it leaks by design
[11:09] <bluesabre> right
[11:09] <ali1234> the entire point of that code is to leave a pixmap on the display after it exits
[11:09] <ochosi> i thought the display-corruption was helped by using the gtkimage?
[11:09] <ali1234> that may be just papering over it
[11:09] <bluesabre> the GtkImage draws with Gtk, so it eliminates the corruption at least when viewing it at the login screen
[11:10] <bluesabre> it will probably come back with drawing using cairo/x
[11:10] <ali1234> i don't think it is the way it is drawn
[11:10] <ochosi> and the leak will only be 1 image instead of all the images that were seen in the greeter by switching users
[11:10] <ali1234> i think it's the RetainPermanent followed by client disconnect
[11:10] <ali1234> but i have no way to test
[11:11] <ochosi> well i can switch to nouveau if it's just about needing a tester ;)
[11:14] <ali1234> actually... this other computer i just found has nvidia onboard graphics
[11:14] <ali1234> i can probably test on that if i update it
[11:15] <ali1234> it's also on 12.04 though
[11:21] <ochosi> fine by me, if it doesn't work for some reason and you need me as a nouveau tester after all, let me know
[11:21] <ochosi> bluesabre: i think we should probably set up a shared branch
[11:22] <ochosi> otherwise you'll always have to merge stuff back and forth
[11:22] <bluesabre> probably
[11:22] <bluesabre> I'll do that in a sec
[11:22] <ochosi> cool, ty
[11:23] <bluesabre> and that way I can leave tasks for you
[11:23] <bluesabre> :D
[11:24] <ochosi> :)
[11:24] <ochosi> i added a funny list-mode to tabwin today
[11:25] <bluesabre> https://code.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/gtk_image_background
[11:25] <ochosi> http://www.zimagez.com/zimage/screenshot-11222013-122522pm.php
[11:26] <ochosi> bluesabre: but ali1234 isn't part of the team yet so can't push, right? or is this a public branch?
[11:26] <bluesabre> adding him now :>
[11:26] <ochosi> nice
[11:26] <bluesabre> btw, do you know who Adam Jiang is?
[11:27] <ochosi> nope
[11:27] <bluesabre> https://launchpad.net/~lightdm-gtk-greeter-team/+members#proposed
[11:27] <ochosi> not the guy who wrote the another-lightdm-gtk-greeter
[11:27] <ochosi> cause that guy's name is andrew
[11:28] <bluesabre> interesting tabwin stuff
[11:28] <ochosi> i'd like to add that as an option
[11:28] <ochosi> it's actually quite a small code-change in the ochosi/tabwin branch
[11:50] <ali1234> right, computer is set up
[11:52] <ali1234> how do i set up lightdm/light-locker for testing?
[12:14] <ochosi> ali1234: i usually just build with --prefix=/usr and then install it over the existing copy
[12:14] <ochosi> if i want to revert, i just use apt-get install --reinstall
[12:14] <ochosi> for light-locker it should suffice to use the daily-PPA, no need to build from source
[12:21] <brainwash> ochosi: uhm, now I'm kinda lost, all this talk about the background issue
[12:21] <ochosi> brainwash: if you wanna test a branch, this is the one: https://code.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/gtk_image_background
[12:22] <bluesabre> wait a sec on that
[12:22] <bluesabre> :)
[12:22] <brainwash> ochosi: just tested the new xfdesktop (4.11) and it messes with the copy process of the root pixmap
[12:22] <bluesabre> I might push a nice fix in a sec
[12:22] <ochosi> brainwash: do you use xfdesktop from git or from the 4.12 ppa?
[12:22] <brainwash> ppa
[12:22] <ochosi> bluesabre: ah, yeah, i would've mentioned the caveat ;)
[12:23] <ochosi> brainwash: mainly asking cause the interaction of greeter and xfdesktop only works with the patch for accountsservice
[12:23] <ochosi> otherwise the user-wallpaper doesn't get set
[12:24] <brainwash> it does get set
[12:24] <ochosi> yeah, with the PPA version it should
[12:24] <ochosi> so what's the problem with the root pixmap exactly?
[12:25] <brainwash> xfdesktop crashes
[12:25] <brainwash> because of the compositor coyping the root pixmap
[12:26] <brainwash> tried to delay the launch of xfdesktop
[12:26] <brainwash> but it did not work, let me try again
[12:27] <brainwash> https://code.launchpad.net/~thad-fisch/lightdm-gtk-greeter/root-window
[12:28] <ali1234> nope.
[12:28] <ali1234> you can't delay xfdesktop
[12:28] <ali1234> the greeter intentionally sets resources that stay around after it exits
[12:29] <ali1234> the support for doing this seems very poor on nouveau
[12:30] <brainwash> you cannot?
[12:30] <ali1234> you can delay it
[12:30] <ali1234> but you can't delay it until those pixmaps go away, because they never go away
[12:31] <ochosi> i think the problem is xfwm4's compositor
[12:31] <ochosi> cause it draws over the root pixmap in grey
[12:31] <ali1234> i have noticed that
[12:31] <ochosi> while it'd better do nothing i guess (at least in our case, where xfdesktop is in use)
[12:31] <brainwash> yes, if xfdesktop launches while xfwm4 copies the root background, xfdesktop will crash
[12:32] <bluesabre> seems a bit buggier, try this ochosi, ali1234: https://code.launchpad.net/~lightdm-gtk-greeter-team/lightdm-gtk-greeter/gtk_image_background
[12:32] <ochosi> ali1234: so basically that grey flicker is what brainwash wants to get rid of :)
[12:32] <ochosi> bluesabre: wait, buggier in what respect? :>
[12:32] <ali1234> i've installed light-locker. how do i lock the screen?
[12:33] <bluesabre> I think the grey flicker is the GtkWindow background color
[12:33] <bluesabre> probably xfdesktop does show() before the background image is loaded I would guess
[12:33] <ochosi> ali1234: after the light-locker process has been started, run "light-locker-command -l"
[12:33] <ochosi> bluesabre: no, there really is a call in the compositor to draw the bg in that grey color
[12:33] <bluesabre> oh
[12:33] <bluesabre> thats terrible
[12:34] <ochosi> :)
[12:34] <bluesabre> btw, not buggier to where it doesn't work, but sometimes at first login the bg is just drawn as the bg-color
[12:34] <ali1234> ok that works for me, no graphics corruption
[12:34] <ochosi> well that's what you see when logging in normally
[12:34] <bluesabre> still an improvement though
[12:34] <ali1234> with the standard greeter that is
[12:34] <ochosi> standard greeter?
[12:34] <ali1234> the one from the install cd
[12:35] <bluesabre> anyway, gotta run
[12:35] <bluesabre> feel free to add any personal fixes or garnishes to that branch :)
[12:35] <ochosi> okey :)
[12:35] <ochosi> seeya later bluesabre 
[12:35] <ochosi> and hf@work
[12:36] <brainwash> bug 1232804
[12:36] <brainwash> explains the grey background
[12:37] <ali1234> if you kill xfdesktop and run some xsetroot commands, it doesn't change the root window colour, presumably because of this
[12:38] <ali1234> you just see the grey
[12:39] <ochosi> so that should probably really be fixed in xfwm4 then...
[12:40] <ali1234> the grey is #7f7f7f
[12:40] <ali1234> http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n872
[12:41] <ochosi> yup
[12:46] <brainwash> how should it be fixed in xfwm4?
[12:46] <ochosi> not sure
[12:47] <brainwash> the code for copying the root background is already there
[12:47] <brainwash> it works
[12:47] <brainwash> but xfdesktop messes up
[12:47] <brainwash> and in 4.11 xfdesktop messes up big time
[12:47] <brainwash> why does it draw a white background?
[12:47] <ali1234> so does it make any difference with any of the branches of the greeter?
[12:48] <brainwash> now we have a grey and a white background...
[12:48] <ochosi> ali1234: does what make any diff?
[12:48] <brainwash> double flicker
[12:48] <ali1234> does anything make any difference?
[12:48] <ochosi> :D
[12:48] <ali1234> because there's too many variables here
[12:48] <ali1234> what exactly are the requirements?
[12:49] <ochosi> well, i think with retaining the background in the greeter, letting xfwm4 copy the root pixmap and fixing xfdesktop to cooperate could do the trick (as far as i understood)
[12:49] <ochosi> the requirements are a flicker-free login
[12:49] <ali1234> and unlocking
[12:49] <ochosi> yeah
[12:49] <ochosi> although
[12:49] <ochosi> unlocking is somewhat impossible
[12:49] <ali1234> and also it shouldn't crash or display corrupted graphics
[12:49] <ochosi> cause unlocking includes a VT-switch
[12:50] <ochosi> so there will be a blank screen
[12:50] <ochosi> yeah, not crashing and not corrupting the screen would be nice :)
[12:52] <ali1234> nouveau just totally corrupted the display and froze the system
[12:52] <ali1234> can we just say "nouveau isn't supported because it's crap"
[12:53] <brainwash> on normal screen locking?
[12:53] <ali1234> no just while i was trying to open firefox
[12:53] <brainwash> it happened once for me after hibernate
[12:53] <brainwash> scrambled screen
[12:53] <ochosi> yeah
[12:53] <ochosi> well getting it to work on everything else first and then trying to add some workarounds for nouveau would be nice
[12:53] <ali1234> yeah
[12:54] <ochosi> but i know it's not very stable...
[12:54] <brainwash> this whole thing is somewhat messed up, we should not have started messing around with it :D
[12:55] <ali1234> if we're getting corruption with nouveau, 99% it's a nouveau bug
[12:55] <ochosi> brainwash: yeah, it's all *your* fault ;)
[12:56] <brainwash> ochosi: do you know why xfdesktop behaves differently since 4.11?
[12:56] <ochosi> no, i haven't looked at the changes
[12:57] <ochosi> but i'm in touch with eric
[12:57] <brainwash> what is the deal with the white background (overlay)?
[12:57] <ochosi> so i can discuss this issue with him when he's back from his holiday
[12:57] <ochosi> (~1-2weeks)
[12:57] <ali1234> well, tell you what... i'll concentrate on this compositor thing
[12:57] <ali1234> it's fine on nvidia...
[12:57] <ochosi> sweet
[12:58] <brainwash> so can we merge https://code.launchpad.net/~thad-fisch/lightdm-gtk-greeter/root-window ? this change alone does no harm
[12:59] <brainwash> well, but on the other side, I'm not an expert, so it could be bad
[12:59] <brainwash> :)
[13:00] <ochosi> it doesnt look very harmful, but i'd prefer if ali1234 and bluesabre also took a look at it
[13:00] <ochosi> the code is from xfwm4, right?
[13:01] <brainwash> not directly, xfwm4 queries this X window property, so I simply set it for the lightdm background
[13:02] <ochosi> yeah, that's what i meant
[13:03] <ali1234> brainwash: what's the reasoning for it?
[13:03] <brainwash> compositor.c
[13:03] <brainwash> http://git.xfce.org/xfce/xfwm4/tree/src/compositor.c#n806
[13:04] <brainwash> line 840
[13:06] <brainwash> it worked nicely with the small startup delay added to xfdesktop 4.10
[13:06] <ali1234> and this causes the crash when xfdesktop is starting?
[13:06] <ochosi> so the fact that both xfwm4 and xfdesktop want to paint the root window causes the crash?
[13:06] <ali1234> ok i see exactly what is happening
[13:06] <ali1234> nah
[13:07] <brainwash> yes, https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1232804/comments/3
[13:07] <brainwash> comment 3
[13:07] <ali1234> this might even explain the graphic corruption
[13:07] <ali1234> i need to look at xfdesktop source...
[13:09] <ochosi> oh the suspense...
[13:09] <brainwash> but these changes are only tested by me so far, or do you mean that there is a general xfdesktop issue?
[13:09] <ali1234> you have to think about how everything interacts
[13:09] <ali1234> see
[13:09] <ali1234> the greeter makes those RetainPermanent pixmaps
[13:09] <ali1234> then xfwm4 starts up and reads the pixmap address for the root image
[13:09] <ali1234> that's the RetainPermanent pixma the greeter stuffed in there
[13:09] <ali1234> then it memcpys it
[13:10] <ali1234> meanwhile xfdesktop starts up and also tries to set the root pixmap (presumably)
[13:10] <ali1234> thus, we have a race condition, an un-owned pixmap that is likely to get freed at any time, and therefore some nasty invalid pointer operations
[13:10] <brainwash> doesn't xfdesktop draw a new window?
[13:10] <ali1234> the root window is the root window
[13:10] <ali1234> who knows what it really does to it?
[13:11] <ali1234> it does draw a new window but that isn't necessarily the only thing it does
[13:11] <ali1234> so... time to look at the code
[13:11] <brainwash> yes, so an extra delay fixed this
[13:11] <brainwash> but xfdesktop 4.11 is different again
[13:12] <brainwash> and we should focus on the 4.11 stuff, right?
[13:12] <ali1234> yeah
[13:13] <ali1234> actually i would be interested to see what happens if you disable xfdesktop completely and then retry all the branches on nouveau
[13:14] <ali1234> i suspect xfdesktop is "cleaning" all the RetainPermanent pixmaps out
[13:14] <ochosi> well that in itself is not a bad idea, eh?
[13:14] <ali1234> it is
[13:14] <elfy> knome: a 30 minute pong or you'll have to ping me again 
[13:14] <ali1234> it is if xfwm4 is going to take a copy of the pointer
[13:15] <ochosi> hm, all in all it's strange no-one noticed this before
[13:15] <ali1234> yeah, i always think that
[13:15] <ochosi> guess in most cases it doesn't cause huge problems
[13:15] <ali1234> "how did this code *ever* work?"
[13:15] <ochosi> :)
[13:20] <ali1234> brainwash: so with that root properties patch, if you kill xfdesktop, do you still see your background?
[13:21] <brainwash> ali1234: all I see is a white background
[13:21] <ali1234> even with the older version?
[13:22] <ochosi> or: you deactivate/uninstall xfdesktop and try again
[13:22] <ochosi> then xfwm4 should show the wallpaper set by lightdm
[13:22] <ochosi> (or did i misunderstand something?)
[13:22] <ali1234> yes, it actually memcpy's the pixmap
[13:23] <ali1234> or at least it tries to
[13:23] <brainwash> why that?
[13:23] <ali1234> well, i guess with a compositor you never see the true root window
[13:23] <brainwash> right, thet's compositing
[13:32] <ali1234> on intel i get a black screen if light-locker is installed
[13:36] <ochosi> ali1234: you mean in the greeter? (as in: happening as it should)
[13:37] <ochosi> i mean: does it blank the screen on locking
[13:37] <ali1234> no i mean as in it boots up to a blank screen
[13:37] <ali1234> and no matter what i do the screen stays blank
[13:37] <ochosi> that's more than odd
[13:37] <ochosi> can't say i get why that would happen
[13:39] <ochosi> unless lightdm_greeter_get_lock_hint would return TRUE in any case
[13:45] <ochosi> ali1234: did you check the /var/log/lightdm/* logs?
[13:51] <ali1234> fixed it, i had to delete displays.xml
[14:09] <brainwash> odd fix
[14:27] <ali1234> hmm
[15:38] <ElderDryas> Seeing as how pleia2 likes notes here rather than -ot (iirc), http://www.dedoimedo.com/computers/xubuntu-salamander.html
[15:39] <ElderDryas> What you guys do, slip some I-Love-Xubuntu juice into his coffee?  He used to despise XFCE :)
[15:44] <ochosi> ElderDryas: hehe, jolly-good read that
[15:52] <slickymaster> ElderDryas, ochosi,  +1 on that
[16:05] <ali1234> i never really thought xfce was any good until recently
[16:05] <ali1234> 4.10 seems to have fixed many many bugs and it's actually viable now
[16:08] <ElderDryas> 4.8 started it, 4.10 took it most of the way...now I look forward to 4.12.  But that seems a ways off now :(
[16:36] <slickymaster> ochosi: ping
[16:38] <ochosi> slickymaster: pong
[16:38] <slickymaster> ochosi: looking at the code in http://git.xfce.org/apps/parole/tree/src/parole-player.c#n2441 I see that the Page Down key is for skip back 600 secs and the Page Up key is for the skip ahead 600 secs
[16:38] <ochosi> exactly
[16:38] <ochosi> 600secs = 10mins
[16:38] <ochosi> (i guess that's easier to grasp for most ppl)
[16:39] <slickymaster> ochosi: yeah, I know, but the thing is, I'm not discovering the keys for the seek medium options
[16:39] <ochosi> it's ctrl+left/right
[16:40] <ochosi> http://git.xfce.org/apps/parole/tree/src/parole-player.c#n2464
[16:40] <ochosi> GDK_CONTROL_MASK
[16:41] <slickymaster> ochosi: never mind, it was right in front of me
[16:41] <ochosi> no problem
[16:41]  * slickymaster thinks that he really needs a pair of glasses
[16:41] <ochosi> actually it's good for you to know, because the show/hide menu shortcut is also CTRL+m
[16:42] <slickymaster> yeah, that one I saw
[16:42] <ochosi> cool
[16:43] <slickymaster> i spent almost ten minutes looking at the switch block and was unable to see them, I really need glasses
[16:43] <ochosi> hehe, that happens from time to time
[16:43] <slickymaster> thanks, ochosi 
[16:43] <ochosi> main question being: didn't you *see* it or couldn't you *read* it ;)
[16:43] <ochosi> (only in the second case you *really* need glasses)
[16:44] <slickymaster> ochosi: that's the million dollar question, isn't it?
[16:44] <ochosi> hehe, i guess
[16:53] <slickymaster> ochosi: just one other thing, is there any particular reason for the fact that the arrow keys (up, down, left and right) are italic formatted?
[16:54] <slickymaster> I mean in http://smdavis.us/doku/doku.php?id=usage&#keyboard_shortcuts
[16:54] <ochosi> let me check how other xfce projects did that
[16:55] <ochosi> hm, i guess that was jjfrv8's decision
[16:55] <ochosi> tbh i didn't really notice that before
[16:55] <ochosi> i don't mind either formatting, but yeah, not sure the italics are needed
[16:56] <slickymaster> ochosi: I don't think that it's visually coherent
[16:56] <ochosi> then remove the italic formatting, i'm totally fine with that
[16:56] <slickymaster> ok
[16:56] <ochosi> jjfrv8: fyi ^
[17:10] <slickymaster> ochosi: I think I've covered them all. Anyway it's at your disposal to check and review http://smdavis.us/doku/doku.php?id=usage&#keyboard_shortcuts
[17:10] <slickymaster> please ping me in case I've skip anything or if you think that something needs to corrected
[17:10] <slickymaster> I'll bbl, after dinner
[17:11] <ochosi> slickymaster: thanks! and bon appetit
[17:11] <ochosi> i'll be away for most of the rest of the weekend
[17:11] <ochosi> returning on sunday evening
[17:12] <slickymaster> ochosi: enjoy your weekend. We'll talk then
[17:12] <ochosi> slickymaster: thanks you too! seeyq
[17:12] <ochosi> seeya
[17:12] <slickymaster> cy
[17:15] <ochosi> bluesabre: i just reviewed slickymaster's addition of the playback kb-shortcuts and changed a few small details, care to review that? http://smdavis.us/doku/doku.php?id=usage&#keyboard_shortcuts
[17:15] <ochosi> bluesabre: i think it's mostly fine and everything should be covered now, not sure about the "skip" wording (should it be "seek" instead?), i also noticed we don't have a shortcut for next/previous track
[17:25] <ali1234> ok, getting good progress on this greeter stuff
[17:25] <ochosi> ali1234: really? do tell!
[17:26] <ali1234> i've got everything set up for testing, results are as expected
[17:26] <ali1234> just testing the compositor pixmap memcpy stuff
[17:26] <ali1234> brainwash' patch doesn't actually work, but the idea is right
[17:27] <ali1234> we need to make the compositor copy the root window instead of just filling it with grey
[17:27] <ochosi> indeed
[17:27] <brainwash> why does it work for me?
[17:27] <ali1234> brainwash: i dunno. if it's because "different drivers" then i will rage
[17:28] <ali1234> i'll get to the bottom of it anyway
[17:28] <brainwash> and why shouldn't it work? it's just setting a property..
[17:28] <brainwash> =S
[17:28] <ali1234> i dunno. all i know is that even with the patch applied i still get a grey root tile
[17:29] <ali1234> i have not yet traced it to see exactly what is happening
[17:29] <brainwash> you also recompiled xfwm4, right?
[17:29] <ali1234> no, did you patch that too?
[17:29] <brainwash> amg
[17:29] <ali1234> or it needs none-default configuration options?
[17:29] <brainwash> right, it's not a default compile option
[17:29] <ali1234> well, that seems silly
[17:30] <brainwash> read my bug report =S
[17:31] <ali1234> so how do i do that? ./autogen.sh MONITOR_ROOT_PIXMAP=yes?
[17:33] <brainwash> you need to define it
[17:34] <ali1234> like, manually in the source code??
[17:36] <ali1234> ah i see
[17:36] <ali1234> this code doesn't just copy the background once
[17:36] <ali1234> it updates it continuously, so that you really can see the root window at all times
[17:36] <ali1234> we don't need that
[17:36] <ali1234> we just want to copy it once
[17:42] <ali1234> right, rebuilt it
[17:42] <ali1234> it works... but
[17:42] <ali1234> not very well
[17:44] <ali1234> i also got xfdesktop crashes... but without updating to the newest version
[17:47] <brainwash> comment 3?
[17:47] <brainwash> it worked for me if I slightly delayed the launch of xfdesktop
[17:48] <brainwash> I cannot get it to work properly, so it's not very likely that this "improvement" will make it into the final LTS release
[17:55] <ali1234> that's just a workaround
[18:07] <brainwash> yes
[18:07] <brainwash> needs to be implemented properly or not at all
[19:03] <ali1234> brainwash: xfdesktop already has a patch that makes it wait for 5 seconds after xfwm4 starts
[19:04] <brainwash> ali1234: right, does it work?
[19:05] <ali1234> well, obviously not
[19:05] <ali1234> what i do see is that xfdesktop also uses those desktop pixmap atoms atoms
[19:16] <ali1234> aaaaaaaaaaaaah
[19:18] <ali1234> https://mail.gnome.org/archives/wm-spec-list/2002-January/msg00001.html <- this thread explains a lot of things
[19:19] <ali1234> one of which is that if xfdesktop wants to set the root pixmap that way it is doing it, it is liable to get killed later on
[19:38] <ali1234> right... i think i understand the problem
[19:47] <ali1234> yeah... fixed
[19:47] <ali1234> so the thing is, if you enable MONITOR_ROOT_PIXMAP it does just that. it doesn't just copy the pixmap one time at startup
[19:47] <ali1234> it also enables a bunch of other code, and that other code is what causes the crash
[19:48] <ali1234> and it isn't really a crash, it's actually defined behaviour
[19:48] <ali1234> because now xfwm4 and xfdesktop both try to control the root pixmap, they fight eachother
[19:48] <ali1234> so the fix is to enable that first copy at startup only
[19:48] <ali1234> and not the other stuff
[19:52] <ali1234> basically the problem is they all try to manipulate the root bg pixmap, and they all use a different standard to do it
[19:52] <ali1234> they should all use the same standard, and then everything will be fine
[19:52] <ali1234> also none of them follows the standard they picked quite correctly
[19:54] <brainwash> ok, finally we (actually you) understand what is going on :)
[19:54] <ali1234> the good news is this is totally fixable
[19:55] <ali1234> it probably also explains why the corrupted graphics on nouveau
[19:55] <ali1234> it all comes down to those RetainPermanent pixmaps. that's a standard, but there's no standard way to manage them once you've created one on the root
[19:56] <ali1234> oh the other good thing about this is that fixing it will also fix the greeter memory leak
[19:57] <ali1234> without having to implement gtk images etc
[19:59] <brainwash> I will test your magical fix then :)
[19:59] <brainwash> if it's ready
[20:12] <ali1234> brainwash: basically, instead of #define MONITOR_ROOT_PIXMAP, remove the #ifdefs from root_tile() only
[20:12] <ali1234> and that's it
[20:17] <pleia2> drc: thanks :)
[20:17] <drc> pleia2: you're welcome...for what?
[20:19] <pleia2> drc: dedoimedo link, added to press page
[20:20] <drc> oh...yeah...You'll have to forgive me, that was this morning and my wife says goldfish have a longer memory than I do :)
[20:20] <pleia2> hehe
[20:26] <brainwash> bug 1254087
[20:27] <Noskcaj> brainwash, I saw that, how hard would it be to fix?
[20:28] <ali1234> i pushed the root pixmap fix to my xfwm4 zoom2 branch
[20:28] <brainwash> don't know, but why replace the xfdesktop right-click menu?!
[20:29] <brainwash> ali1234: got any prebuild packages too?
[20:29] <ali1234> no
[20:29] <ali1234> you still need to patch the greeter to set the atom too
[20:29] <brainwash> because many people need to test this stuff :)
[20:29] <ali1234> but that needs "improving"
[20:31] <brainwash> currently everything is a bit messy, branches and fixes everywhere
[20:36]  * ali1234 pokes #ubuntu-x for information
[20:40] <Noskcaj> brainwash, the bug is about right-click>Applications>
[20:42] <brainwash> mmh, so xfdesktop would need support for the whisker panel plugin
[20:45] <brainwash> reassign the report to xfdesktop?
[20:48] <ali1234> hmm... i'm going to look at what unity-greeter does wrt RetainPermanent
[20:48] <ali1234> we should support whatever they do too, if they use different atoms
[20:53] <brainwash> different? xfwm4 only checks for 2 I think
[20:54] <brainwash> oh RetainPermanent
[20:57] <ali1234> yeah there's at least 4 different ones
[20:57] <ali1234> (xfdesktop checks for 2 different ones)
[20:57] <ali1234> basically you make a RetainPermanent pixmap and then stuff it's X resource ID into an atom so you can find it again later
[20:58] <ali1234> but every desktop uses a different atom for this
[21:01] <ali1234> unity-greeter defines RetainPermanent but does not use it
[21:01] <ali1234> so now i'm really puzzled
[21:13] <ali1234> it looks like compiz just copies whatever is on the screen at startup
[21:13] <ali1234> no checking of atoms
[21:14] <ali1234> it does monitor atoms for later background changes though
[21:16] <brainwash> and gdm/mutter? :P
[21:18] <ali1234> who cares about them?
[21:24] <knome> bluesabre, pleia2: either/both of you around?
[21:24] <knome> jjfrv8, or you? :)
[21:24] <pleia2> you're supposed to say what you want first so I can figure out whether to say yes
[21:25] <knome> nah, not saying is part of my evil plan!
[21:25]  * skellat is lurking
[21:26] <knome> skellat, i don't specifically need you at the moment but if you have anything you'd like to discuss, i'm here!
[21:26] <knome> pleia2, do you have time to go through the blueprints today?
[21:26] <pleia2> maybe after work
[21:27] <knome> what UTC is that?
[21:27] <pleia2> 1
[21:27] <knome> umph
[21:27] <knome> might not be around at that time today
[21:27] <knome> but we can look at it later, no hurry
[21:27] <pleia2> sunday would be better
[21:28] <knome> (and i could have a quick stab at it myself as well)
[21:28] <pleia2> knome: lmk when you publish testing post
[21:28] <knome> ah, i could do that soonish
[21:28] <knome> are you lurking around?
[21:28] <pleia2> yeah
[21:29] <knome> i'm probably doing it in the next 30mins
[21:29] <knome> perfect, i'll ping you then :)
[21:41] <knome> heh, ok, so ~ubuntu-testcase is going to be removed ;)
[21:47] <knome> does anybody see any reason for ~xubuntu-dev to be a member of ~xubuntu-team?
[21:47] <knome> everybody in ~xubuntu-dev is explicitly a member of -team as well (except people who are in ~dev because of other team memberships)
[21:48] <knome> if we drop the membership of ~xubuntu-dev, then LP would show the real amount of -team members
[21:52] <ali1234> here's a tonne of information about this: https://github.com/mate-desktop/mate-desktop/pull/46
[22:05] <knome> pleia2, prodded out http://xubuntu.org/news/help-us-test-xubuntu-14-04-lts/
[22:05] <knome> and tweeted
[22:11] <ali1234> hmm you know what? i think this code from xfwm4 MONITOR_ROOT_PIXMAP was written by someone who was very confused, and they just got the atom names wrong
[22:25] <slickymaster> night all
[22:25] <pleia2> knome: thanks
[22:25] <knome> np
[22:25] <knome> hey slickymaster 
[22:26] <slickymaster> hi, knome 
[22:26] <knome> slickymaster, has elfy been in contact with you since yesterday yet?
[22:26] <slickymaster> knome, no
[22:27] <knome> slickymaster, ok, let him take the time then :)
[22:27] <slickymaster> knome, ok
[22:27] <slickymaster> is there any problem?
[22:27] <knome> slickymaster, not at all!
[22:27] <slickymaster> ok
[22:30] <slickymaster> ochosi, saw the changes you made on to the playback table on http://smdavis.us/doku/doku.php?id=usage#keyboard_shortcuts and I must say that you were right from the beginning
[22:30] <slickymaster> ochosi, people can understand 10 mins but probably wouldn't understand 600 secs
[22:30] <slickymaster> ochosi, good call
[22:34] <ali1234> ochosi: i summarized all my knowledge about the greeter pixmap stuff on the bug report, if you don't wanna read all the scrollback: https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/1232804/+attachment/3899352/+files/xsetroot.patch