[00:17] <ali1234> well, it doesn't crash or corrupt any more, so that's something
[00:18] <ali1234> in fact i think it's working perfectly :)
[00:19] <ali1234> or not... it's not copying the pixmap
[00:43] <Unit193> jjfrv8: Welcome back.
[00:44] <jjfrv8> I was working on my desktop and knocked the cable out of my pi :)
[01:00] <ToeTag> Hey, is anyone around that I can ask about the wallpaper submission requests?
[01:00] <ToeTag> I want to make sure that I'm reading a requirement right "No branding assest like "Xubuntu logo" or text to permit use by derivative distributions
[01:01] <ToeTag> So explicitly no text on the wallpapers?
[01:01] <pleia2> in general no text is best, since we can't really translate wallpapers ;)
[01:02] <ToeTag> makes sense
[01:02] <ToeTag> I was surprised at the "no xubuntu logo" requirement. I guess that's very considerate of them
[01:02] <pleia2> yeah, we have downstreams that use xubuntu as a base, we don't want to overbrand
[01:02] <ToeTag> There seems to be no expression of a "submission limit" - anyone see any issues with me submitting multiple cantidates?
[01:03] <pleia2> that's fine
[01:03] <pleia2> I think we might restrict it to 1 next cycle though :)
[01:03] <ToeTag> yeah makes sense
[01:03] <ToeTag> awesome, thanks a lot
[01:03] <ToeTag> really appreciate it
[01:03] <pleia2> thank you!
[01:05] <ali1234> ah! it works!
[01:05] <ali1234> it just doesn't redraw itself now
[01:10] <ali1234> cool. this code now actually works with old style SETROOT wallpapers, and also works with xfdesktop without exploding... and also doesn't have any flickering
[01:34] <ali1234> brainwash, ochosi: please test background branch on my xfwm4 repo... it should fix everything
[01:35] <ali1234> you won't even see the wallpaper flicker if xfdesktop crashes, and if you kill it (5 times) you can even set the wallpaper with hsetroot etc
[01:42] <eric_the_idiot> xfdesktop crashes?
[01:52] <ali1234> crashes/is killed :)
[01:54] <ali1234> eric_the_idiot: this whole epic thing has been about having the wallpaper stay the same from greeter startup to fully logged in... it's now possible, but i had to fix many bugs in the greeter, xfwm4, and xfdesktop :)
[01:55] <ali1234> it all boils down to each one implementing http://www.eterm.org/docs/view.php?doc=ref#trans in a slightly different and incompatible way
[01:55] <eric_the_idiot> any other patches for xfdesktop?
[01:56] <ali1234> tomorrow, yes
[01:56] <ali1234> see the post i just did on xfce-dev
[01:56] <eric_the_idiot> will do
[03:24] <winstonebook> hello
[03:25] <Unit193> Howdy.
[08:53] <ochosi> morning evryone
[08:53] <Noskcaj> evening ochosi 
[08:53] <ochosi> ali1234: that sounds great!
[09:32] <knome> hullo
[09:34] <ochosi> heya knome 
[09:35] <ochosi> updated the submissions page, as you'll have noticed
[09:35] <knome> yep
[09:36] <ochosi> also added that note with a link to the history
[10:07] <koegs> can you tell me how xfce in xubuntu provides the gtk-3.0 theme-name?
[10:07] <knome> i'm not sure i follow...
[10:07] <koegs> i am trying awesome within xubuntu, but not all gtk(3)-apps use the correct theme although i have ~/.config/gtk-3.0/settings.ini
[10:08] <koegs> when i start the xubuntu-session, all apps have the correct theme, but not in awesome
[10:08] <ochosi> koegs: how do you set your theme in awesome?
[10:09] <ochosi> oh, and, let's take this to #xubuntu
[10:09] <koegs> ochosi: with ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini
[10:09] <koegs> ok, i wasnt sure because of the awesome-thingy :)
[10:10] <knome> if it isn't suitable for #xubuntu because you have a non-default component, it isn't really suitable in #xubuntu-devel either
[10:10] <knome> i mean, the question is fine, but by your logic...
[10:12] <koegs> yeah, not the best logic :D
[15:01] <slickymaster> good afternoon all
[16:33] <brainwash> ali1234: screen corruption remains and light-locker behaves really odd (cursor jumps around occasionally)
[16:34] <brainwash> and there seems to be a brief black screen flicker when xfdesktop launches
[16:34] <ali1234> reinstall everything
[16:49] <brainwash> ali1234: the black flicker is new since I've compiled the background branch like 30min ago
[16:49] <ali1234> when does it happen?
[16:49] <brainwash> exactly when xfdesktop launches, before the icons get displayed
[16:52] <brainwash> replaced xfwm4, locked the screen and everything works, no screen corruption
[16:52] <brainwash> no cursor jumping
[16:54] <ali1234> replaced with what?
[16:55] <brainwash> mutter
[16:56] <brainwash> or even with the unpatched xfwm4 I guess
[16:58] <ali1234> so what happens if you kill xfdesktop first?
[17:01] <brainwash> it happened even if xfdesktop was not started at all
[17:02] <ochosi> ali1234: sorry, i haven't been able to test your xfwm4 branch up to now, i'll try to get to it though
[17:03] <ochosi> it's the background branch, right?
[17:03] <brainwash> yes, already did some testing
[17:04] <brainwash> but xfwm4 is somehow causing the screen corruption
[17:05] <brainwash> and I've noticed a brief black flicker when xfdesktop launches
[17:05] <ochosi> so what doesn't work for you now?
[17:05] <ochosi> and that's it?
[17:05] <brainwash> well, lets see if you can confirm this black flicker
[17:05] <ochosi> yeah, am about to reboot..
[17:05] <ochosi> brb
[17:07] <ochosi> i don't have any problems with the background branch
[17:07] <ochosi> i mean there is a flicker, but that's xfdesktop
[17:07] <ochosi> because i'm using the unpatched version from the 4.12 PPA atm
[17:07] <brainwash> :D
[17:08] <brainwash> ok, what about lightdm locking?
[17:08] <ochosi> just normal locking or suspend-locking?
[17:08] <brainwash> normal
[17:08] <ochosi> k
[17:08] <brainwash> and/or via "dm-tool lock"
[17:09] <ochosi> totally fine
[17:09] <ochosi> no problems whatsoever with that
[17:09] <brainwash> ok :(
[17:09] <ochosi> could be an amd issue
[17:09] <ochosi> or i dunno
[17:09] <brainwash> I start thinking the same
[17:10] <ochosi> alternatively, how clean is your build/test-env?
[17:10] <brainwash> no hints in any of the log files
[17:10] <ochosi> or have you tried with the open drivers?
[17:10] <brainwash> it's messed up one
[17:10] <brainwash> well, it needs to work with the restricted one
[17:11] <brainwash> but I'll test the open source one too
[17:12] <ali1234> there should not be any flicker at all with the new code
[17:13] <brainwash> and there should not be any theme issue
[17:14] <brainwash> lets wait for ochosi to test the patched xfdesktop
[17:14] <ochosi> ali1234: yeah, i have to switch back to the patched xfdesktop...
[17:14] <ali1234> i didn't patch xfdesktop yet
[17:14] <brainwash> the latest commit?
[17:14] <brainwash> git
[17:15] <ali1234> you should get one transition from the greeter wallpaper to the user wallpaper, and no flicker
[17:15] <ochosi> i'll use git master of xfdesktop now
[17:16] <ali1234> well yeah, you do need *that* patch i guess :)
[17:16] <ali1234> i forgot about that one
[17:16] <ochosi> ;)
[17:16] <ochosi> brb
[17:18] <ochosi> ok, so i do get a brief moment of corruption when xfdesktop loads the wallpaper
[17:18] <ochosi> but there is no grey/white/black flicker
[17:18] <ochosi> i'll try to log out and in again to see whether i can reproduce that
[17:19] <brainwash> corruption?
[17:19] <ochosi> could be the dualhead setup
[17:19] <ochosi> cause my internal display is disabled at the greeter
[17:19] <ochosi> so it flickers briefly when it enables the display with the session
[17:20] <ochosi> and then it seems to draw the wallpaper a bit borked for a split second and then it's there correctly on the second monitor
[17:20] <ochosi> i can try without the external monitor a bit later
[17:20] <brainwash> yeah
[17:20] <brainwash> gtg now, later
[17:22] <ali1234> ah i know what that is
[17:23] <ali1234> it's doing the operations int he wrong order - i had that problem in lightdm
[17:35] <ali1234> i assume you're both familiar with double buffering... the problem is that xfdesktop doesn't do this
[18:12] <ochosi> hmm
[18:12] <ochosi> ali1234: is that easy to implement?
[18:13] <ochosi> bbiab
[19:32] <ali1234>     XFreePixmap (dpy, pixmap);
[19:32] <ali1234> wow, how did i never see that before
[19:34] <ochosi> ali1234: what do you mean?
[19:34] <ali1234> well, i thought all this time something else was freeing the pixmap out from under xfwm4
[19:35] <ali1234> but actually, xfwm4 does it
[19:35] <ali1234> so making that copy is probably unneccesary
[19:35] <ali1234> all it needs to do is NOT free the pixmap unless it created it
[19:37] <ali1234> i'm going to push branches of xfwm4, xfdesktop, and greeter, all with syslog debugging (because order of operations is important)
[19:37] <ali1234> then we can get to the bottom of this finally
[19:39] <ochosi> sweet
[19:40] <ali1234> just tried without the copy and it works
[19:41] <ochosi> bbabl
[19:45] <ali1234> wow, that turns the fix into a one liner
[19:53] <ali1234> actually i bet that fix will fix everything... lol
[19:54] <ali1234> i dunno. maybe it's never appropriate to free the pixmap
[20:00] <ali1234> #xorg has the most users and the least amount of talk :/
[20:00] <brainwash> it fixes what? you said that everything was already working for you
[20:01] <ali1234> yeah, but my "fix" is long winded and unneccessary
[20:01] <ali1234> anyway just because it works for me doesn't mean the code is correct
[20:01] <ali1234> Q i just asked on #xorg: is it valid to create a pixmap, then create a XRender picture from it, then free the pixmap, and carry on using the picture? http://paste.ubuntu.com/6486175/
[20:02] <ali1234> the answer to this question might explain why you still get corruption
[20:03] <ali1234> apparently the answer is it's valid
[20:46] <ochosi> ali1234: hm, there seems to be lots of back and forth, so were do you stand now?
[20:47] <ali1234> well, i'm happy with xfwm4
[20:47] <elfy> lol - I got completely lost some time last week ;)
[20:47] <ali1234> i'm happy with gtk-greeter
[20:47] <ali1234> i'm not happy with xfdesktop yet
[20:49] <ali1234> the trouble is, because there is so much communication between them via atoms, a bug in one can mess up all the others
[20:49] <ali1234> so you see corruption on the xfwm4 root tile, because xfdesktop passed a bad pixmap
[20:49] <ali1234> or you see xfdesktop crash because xfwm4 called XFreePixmap()
[20:49] <ali1234> and so on, so even if 2/3 have correct code, the whole thing can still exlode
[20:50] <ochosi> right
[20:50] <ochosi> it's just strange that a pixmap has to be passed around so much
[20:52] <ali1234> it's prefectly reasonable when you understand it
[20:53] <ali1234> the pixmap has to be shared because the greeter exits before the window manager starts
[20:54] <ali1234> the mechanism that is used to share the pixmap between greeter and wm also is used by xfdesktop
[20:54] <ali1234> but none of them used it properly, so they all fight each other
[20:54] <ali1234> it's not strictly necessary to fix xfdesktop, but i don't like to leave stuff broken
[20:54] <ochosi> what's broken there atm?
[20:55] <ali1234> well it sets it sets the ESETROOT atom, which is like hanging a big sign around it's own neck which reads "Please kill me"
[20:55] <ochosi> that's quite graphic :)
[20:56] <ali1234> it keeps a reference to the pixmap it puts into the atom and reuses it later, after xfwm4 has freed it.... which is why it crashes
[20:57] <ali1234> that is a bug of xfwm4, but... programs which do this should not set ESETROOT
[20:57] <ochosi> but not messing with that atom isn't a solution?
[20:57] <ali1234> no, using the atoms for message passing is absolutely fine
[20:58] <ali1234> just as long as you do it correctly
[20:58] <ochosi> yeah, but is the atom really needed in the desktop?
[20:58] <ali1234> yes, because xfdesktop has no other way to tell the window manager what to render in the root tile
[20:59] <ali1234> now the root tile is hardly ever visible, but that isn't the point
[20:59] <ali1234> the code exists for this, but is broken
[20:59] <ali1234> it shouldn't be broken
[20:59] <ochosi> agreed
[20:59] <ali1234> as i wrote on the ML, there's three ways to use the MONITOR_ROOT_PIXMAP code
[21:00] <ali1234> not at all, all the time, or only at startup
[21:00] <ali1234> i want all three to work, even if we only use one
[21:00] <ali1234> do you know how to remove xfdesktop from the session startup?
[21:06] <ali1234> if this code still doesn't work, it might be that we need to do some server grabs to keep things from happening at the same time
[21:06] <ali1234> i already added that to the greeter, but xfwm4 might need it to
[21:12] <ochosi> not sure, i think xfce4-session starts it
[21:12] <ochosi> but you can remove it from there
[21:12] <ochosi> ali1234: settings-manager > sessions > session 
[21:13] <ali1234> it's not in there in mine...
[21:15] <ali1234> ok, bgfix2 branch, please test :)
[21:15] <ali1234> i haven't added debugging yet, just doing that now
[21:33] <ochosi> ali1234: i'm at it
[21:35] <ochosi> do i need anything apart from the bgfix2 branch?
[21:37] <ali1234> well, i;ve just done the debugging for lightdm-gtk-greeter and xfwm4, so hang on 1 second while i push it
[21:38] <ali1234> right please test these branches:
[21:38] <ochosi> ah ok
[21:39] <ali1234> lp:~a-j-buxton/lightdm-gtk-greeter/experimental-debug
[21:39] <ali1234> and bgfix2-debug for xfwm4
[21:39] <ochosi> so those two branches write some logs?
[21:39] <ochosi> or how can i check the debugging stuff
[21:39] <ali1234> yes, all logs go to /var/log/syslog
[21:40] <ochosi> right, it'd be ideal if brainwash could test these, as he's the one seeing troublesome stuff
[21:40] <ali1234> yeah, i need to add logging to xfdesktop too for that... gotta fork that on github first tho
[21:40] <ali1234> also, there might be bugs in my logging code :)
[21:40] <ali1234> that's what you're really testing at this point :)
[21:42] <ochosi> hehe, fine :)
[21:42]  * ochosi puts on the guinea-pig t-shirt
[21:42] <ali1234> so, in order to test, do this: tail -f /var/log/syslog
[21:42] <ali1234> then try killing xfdesktop one time
[21:43] <ali1234> then kill it 5 times and try "hsetroot -color \#ff00ff" - you should see the background change to purple
[21:43] <ochosi> wait, first install the branches, then restart, then kill xfdesktop?[24;2~
[21:43] <ali1234> yeah, oviously you gotta install it all :)
[21:43] <ali1234> anyway you should see stuff like "found pixmap" and so on
[21:44] <ali1234> pastebin all that so i can check it makes sense
[21:44] <ali1234> you should also see "set root pixmap" from lightdm-gtk-greeter, then when xfwm4 starts you should see it find the same pixmap XID
[21:45] <ali1234> also stuff about GrabServer
[21:47] <ochosi> ok, restarting now...
[21:47] <ochosi> brb
[21:50] <ochosi> ok, i'm back
[21:50] <ali1234> just in time for patched xfdesktop
[21:50] <ochosi> holy crap, xfdesktop won't go away
[21:50] <ochosi> i mean it says "no process found"
[21:50] <ochosi> but the wallpaper is still there
[21:51] <ochosi> ah, that's xfwm4 then
[21:51] <ochosi> the hsetroot command didn't work though
[21:52] <ali1234> yeah :)
[21:52] <ochosi> i mean the syntax doesn't work out :)
[21:52] <ali1234> the wallpaper should remain even after xfdesktop is killed - that's the *whole* point :)
[21:52] <ochosi> good, i guess that means that part is working
[21:52] <ochosi> nice
[21:52] <ali1234> oh sorry, hsetroot -solid ...
[21:52] <ochosi> yeah, works
[21:52] <ali1234> git://github.com/ali1234/xfdesktop
[21:52] <ali1234> add that in to the mix please :)
[21:53] <ochosi> and, gahh, my poor eyes!
[21:53] <ochosi> terrible color-choice
[21:53] <ochosi> back to black...
[21:53] <ali1234> \#ff7f00 is nice orange :)
[21:53] <ali1234> xfdesktop is still pushing
[21:54] <ochosi> yeah, i was wondering why i received a message about pulling an empty repo :)
[21:54] <ochosi> that's the problem with these old code-bases
[21:54] <ochosi> lotsa history
[21:54] <ochosi> and my connection is lame
[21:54] <ali1234> well if you have a clone of it already you can just add my repo, it will only fetch the changes
[21:54] <ali1234> git ftw...
[21:55] <ochosi> yeah, it's pretty clever
[21:55] <ali1234> git remote add ali1234 git://github.com/ali1234/xfdesktop && git fetch ali1234 && git checkout ali1234/master
[21:55] <ochosi> i can't understand why they had to create bzr...
[21:55] <ali1234> bzr can probably do this too, but i don't know how
[21:56] <ochosi> ping me when the pushing is done
[21:56] <ali1234> its done
[21:56] <ochosi> cool
[21:58] <ochosi> so i presume restarting xfdesktop is enough?
[21:58] <ali1234> yeah, just kill it (if you did make install)
[21:58] <ali1234> the greeter is the only one that is funny about that stuff
[21:59] <ochosi> ok, done
[21:59] <ochosi> the wallpapers are back
[21:59] <ali1234> you should see it set the pxmap, then xfwm4 will pick up the new pixmap
[21:59] <ochosi> Nov 27 22:58:46 legume xfdesktop[7665]: set root pixmap XID=0x3a00023
[21:59] <ochosi> Nov 27 22:58:46 legume xfwm4[1557]: display=:0.0, screen=0 - found pixmap 0x3a00023
[21:59] <ali1234> perfect
[21:59] <ali1234> this is what should happen. the XID should match
[22:00] <ochosi> it does indeed
[22:00] <ochosi> need more syslog output?
[22:00] <ali1234> only if you have corruption or anything like that
[22:00] <ali1234> try locking the screen :)
[22:00] <ochosi> no, eveything seems fine
[22:00] <ochosi> ok :)
[22:00] <ali1234> you should see that lightdm uses display:1.0
[22:01] <ali1234> and xfwm4 will not notice that pixmap change
[22:01] <ochosi> yeah it does
[22:01] <ochosi> yup, it doesn't
[22:01] <ali1234> as it shouldn't since it's a different display
[22:01] <ochosi> worked perfectly
[22:01] <ali1234> so now we need brainwash to test this, then maybe we see why it corrupts
[22:01] <ochosi> yup
[22:01] <ochosi> although if it is a driver issue, we probably won't
[22:02] <ali1234> perhaps not
[22:02] <ochosi> but still
[22:02] <ochosi> this is quite informative
[22:02] <ali1234> if the log looks okay it can only really be a driver issue :(
[22:02] <ochosi> fwiw, with all the messing around, the greeter doesn't seem to pick up my wallpaper anymore
[22:02] <ochosi> it always seems to display one i haven't used for a while
[22:02] <ali1234> yes, because xfdesktop and accountservice
[22:02] <ochosi> yeah
[22:03] <ochosi> but also when i switched back to the 4.12 PPA
[22:03] <ali1234> it's picking up an old setting - the new xfdesktop uses different keys
[22:03] <ochosi> oh
[22:03] <ochosi> so the patch doesn't work anymore?
[22:03] <ali1234> it's quite messed up for me, i think i need to clear out the settings
[22:03] <ali1234> i haven't aplied the account service patch
[22:03] <ali1234> never even looked at it
[22:03] <ochosi> well, would be nice if that worked again here
[22:04] <ochosi> will now revert to my tabwin branch again
[22:04] <ochosi> there's still some work to do there
[22:04] <ali1234> going to need to update it for the new xfdesktop
[22:08] <ochosi> weird, i was using xfdesktop 4.11 before and i think it worked
[22:09] <ali1234> probably picking out the old key/value
[22:10] <ochosi> probably
[22:10] <ochosi> my desktop settings seem quite oldish
[22:10] <ochosi> think i'll clear them out
[22:11] <slickymaster> night all
[22:12] <ochosi> night slickymaster 
[22:12] <slickymaster> hi ochosi 
[22:12] <ali1234> brb...
[22:16] <ali1234> i saw the corruption :(
[22:16] <ali1234> i think i know why though
[22:16] <ali1234> also got the missing gtk theme stuff
[22:16] <ali1234> no idea at all what that's about
[22:17] <ochosi> oh
[22:17] <ochosi> i didn't get that
[22:17] <Unit193> "Corruption", black and white lines by chance that go away?
[22:17] <ochosi> no, just a slightly garbled version of my wallpaper for a split-second
[22:18] <ali1234> yes, that's what i mean
[22:18] <ali1234> it's because it sets the root pixmap *before* copying in the wallpaper
[22:18] <ali1234> i had this problem in the greeter but fixed it
[22:18] <ali1234> need to fix in in xfdesktop too
[22:24] <ochosi> right, that sounds promising
[22:25] <ochosi> so it'll be really smooth in the end
[22:26] <ali1234> yeah, it's nearly there now... just needs the xfdesktop fixings now
[22:30] <ali1234> ok, that was easy
[22:31] <ali1234> https://github.com/ali1234/xfdesktop/commit/d88d5405d0b42334d1b1a14b509708f13813c434
[22:31] <ali1234> eric_the_idiot: ^
[22:33] <ali1234> brainwash: testing instructions: http://paste.ubuntu.com/6486852/
[22:34] <slickymaster> elfy, at your disposal https://code.launchpad.net/~slickymaster/ubuntu-manual-tests/ubuntu-manual-tests/+merge/196989
[22:53] <brainwash> ali1234: ok, test results tomorrow, cannot access my test machine at the moment
[22:53] <ochosi> ali1234: nice, all in all your patches really don't look like they hurt at all, they just remove the communication troubles between the components
[22:53] <ali1234> right. i think i've made the code shorter overall too
[22:54] <ali1234> got a really helpful piece of advice from #xorg: use XRenderCreateSolidFill instead of messing about with pixmaps
[22:59] <ochosi> wowza, anyone ever heard of this before? http://gmc-holle.github.io/xfdashboard/
[22:59] <ali1234> hah... no
[23:00] <ochosi> just read about it on the xfce-users ml
[23:00] <ali1234> looks like a weird cross between unity and gnome-shell... my two "favourite" desktops
[23:00] <ochosi> yeah, it's strange, the guy said he's a gnome3 refugee, but then again he seems to want gnome3...
[23:01] <ochosi> and it uses clutter
[23:01] <ali1234> lol
[23:01] <ochosi> which might be important for the stuff he does, but eh...?
[23:02] <ali1234> >.<
[23:02] <ochosi> just makes me wonder why he doesn't just use gnome3 with some xfce components instead
[23:02] <ali1234> or unity
[23:02] <ali1234> does he use a distro that isn't ubuntu?
[23:03] <Unit193> You can install Unity just fine on Arch.
[23:03] <ali1234> yeah but not anywhere else
[23:03] <ali1234> also, "just fine" is a bit of a stretch. there's one guy maintaining the whole unity stack
[23:03] <ali1234> which is about 10x bigger than all of xfce