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