[03:31] <Unit193> micahg, mr_pouit: https://code.launchpad.net/~xubuntu-dev/xubuntu-default-settings/trunk/+activereviews
[07:53] <elfy> Noskcaj: hi :) 
[07:53] <elfy> is your ppa good to go now?
[09:56] <ochosi> elfy: as far as i followed that discussion between brainwash and ali1234 there are some new problems with gtk3 indicators in trusty
[09:57] <ochosi> i don't know whether they have to (or will) be tackled upstream or in the xfce-plugin
[09:57] <ochosi> i hope the other two can shed some light on this (was pretty absent over the weekend)
[10:26] <slickymaster> morning all
[10:31] <knome> morning slickymaster 
[10:31] <slickymaster> hi, knome 
[10:33] <knome> slickymaster, you're not joining #ubuntu-doc by default?
[10:34] <slickymaster> knome, at work no. As I'm behind a proxy I can't use IRC clients, just by web browser and I have to join individually each of the channels 
[10:35] <slickymaster> at home yes, it's by default
[10:35] <knome> slickymaster, aha :)
[10:35] <knome> slickymaster, if you join, i could use some of your insight
[10:35] <slickymaster> I'm there
[14:21] <elfy> ochosi: ok - thanks for letting me know :)
[14:22] <brainwash> elfy: the PPA is ready for testing, but there seems to be something wrong with the launch mechanics of indicators in trusty, dbus activation has been removed partially which might result in a race condition
[14:23] <elfy> not much point in testing something that isn't what we'll actually end up with imo
[14:23] <brainwash> you will need to set the env var INDICATOR_ALLOW_NO_WATCHERS=yes
[14:23] <ali1234> yeah there is: you can still test that the indicators actually work
[14:23] <brainwash> and the sound indicator icon is sometimes missing/invisible
[14:23] <ali1234> the whole thing is still actively changing btw
[14:23] <elfy> brainwash: what I am actually after is a position in which I can tell people install this PPA and you can check the gtk3 inds
[14:24] <elfy> not something that is half here, half there and not the same as yesterdya or tomorrow
[14:24] <brainwash> well, it should work in saucy just fine I guess
[14:24] <brainwash> or you mean testing in trusty?
[14:24] <elfy> once it's ready for testing - properly - then we can do something
[14:24] <elfy> brainwash: I have no interest in saucy 
[14:25] <ali1234> complain at tedg in #ubuntu-desktop
[14:25] <elfy> not run it for a couple/few weeks now - I'm interested in getting testing sorted for trusty
[14:25] <elfy> ali1234: IU'm not complaining at all 
[14:25] <brainwash> but still it would help to test this stuff now instead of waiting
[14:26] <elfy> in trusty yes 
[14:26] <ali1234> test it in trusty -> find out it doesn't work properly -> complain to tedg until he fixes it
[14:26] <elfy> anyway - off now - anything else to say can you tell forestpiskie and I'll catch it later
[14:26] <elfy> probably shouldn't have gone to work but I did ... 
[14:26] <ali1234> it's curently broken in unity too
[14:27] <brainwash> really? did not notice that
[14:27] <ali1234> same race conditions are present
[14:27] <ali1234> also broken in ubiquity
[14:28] <brainwash> how does unity even launch the indicator services? I think the autostart files state that they should not be run in the unity session
[14:28] <ali1234> upstart
[14:28] <ali1234> that's the whole point
[14:28] <ali1234> unity emits a signal, upstart catches it and runs all the indicators
[14:28] <ali1234> then they quit because there's no watchers
[14:28] <brainwash> oh
[14:29] <brainwash> should xubuntu do the same?
[14:29] <brainwash> via upstart I mean
[14:29] <ali1234> it can do, but currently that just makes them get run twice
[14:29] <ali1234> it's easy to emit the signal, i coded it
[14:29] <brainwash> right, such a mess =S
[14:29] <ali1234> but there's no point, it does not fix the problem
[14:29] <ali1234> yes
[14:30] <brainwash> any ideas how to debug the missing sound indicator icon?
[14:30] <ali1234> no
[14:30] <ali1234> other than the usual add printfs everywhere until you find something that is wrong
[14:30] <brainwash> yeah, maybe I'll do that
[15:06] <jjfrv8> ochosi, can you check out the Preferences section of the xfdesktop docs when you get a chance?
[15:08] <jjfrv8> ochosi, and can you explain how the "transparent" option is supposed to work? It doesn't have any controls and I don't understand what can be behind the desktop to show through.
[15:09] <knome> hey jjfrv8 :)
[15:09] <jjfrv8> hi, kno
[15:09] <jjfrv8> *knome
[15:09] <knome> me me
[15:09] <knome> jjfrv8, just cheking, are you subscribed to the ubuntu-doc@ mailing list?
[15:10] <knome> (i don't think you necessarily need to be, or asking you to subscribe, just want to know if you are)
[15:10] <jjfrv8> negative. I just looked over there at your discussion this morning, though.
[15:10] <knome> oki
[15:10] <knome> it seems to be quite high traffic list
[15:11] <jjfrv8> I should probably look in on it
[15:11] <knome> we've mainly worked on the community help wiki lately
[15:12] <jjfrv8> knome, I also saw that you were working with slickymaster on the 13.10 slideshow bug...
[15:12] <jjfrv8> and that you assigned bug 1213933 to the -doc team
[15:13] <jjfrv8> I'd like to try to fix it but don't know how to do the slideshows
[15:13] <knome> jjfrv8, i did. that's the most appropriate team :)
[15:13] <knome> ok, do you have time now, and i can guide you through it?
[15:13] <jjfrv8> yup
[15:13] <knome> ok, let me finish this email and i'll get back to you in 5
[15:14] <jjfrv8> ok
[15:14] <brainwash> jjfrv8: maybe the transparency of the label below the desktop icon?
[15:15] <jjfrv8> brainwash, still not sure, which label?
[15:15] <brainwash> it's 100% transparent since I'm using xfdesktop 4.11
[15:15] <brainwash> the label containing the name
[15:15] <brainwash> like "Tash"
[15:15] <brainwash> "Trash"
[15:16] <jjfrv8> I can see where they are transparent, but my understanding was that the desktop color itself was supposed to be transparent to things behind *it*
[15:17] <jjfrv8> that's kind of the way the 4.10 docs explained it
[15:17] <brainwash> does that make sense?
[15:17] <brainwash> so it's basically a setting like saturation of the wallpaper
[15:19] <knome> jjfrv8, ping me when you're done with this discussion
[15:20] <jjfrv8> brainwash,"when you use a colored background without backdrop image, allows you to see the windows that are under the transparent desktop window."
[15:20] <jjfrv8> that's the 4.10 explanation
[15:20] <brainwash> feel free to end it, I have no clue anyway :)
[15:20] <jjfrv8> thanks.
[15:20] <jjfrv8> ok, knome
[15:20] <knome> jjfrv8, ok
[15:21] <knome> so, the project that has the slideshows is https://launchpad.net/ubiquity-slideshow-ubuntu
[15:21] <knome> the branch itself is naturally: lp:ubiquity-slideshow-ubuntu
[15:21] <knome> 'bzr branch lp:ubiquity-slideshow-ubuntu' to fetch that
[15:21] <knome> you're familiar with this, right?
[15:21] <jjfrv8> yes
[15:22] <knome> in the branch, you basically only want to touch files inside slideshows/xubuntu/slides/
[15:22] <knome> those are the 8 (9) html files that are shown for the user during installation
[15:23] <knome> in this case, we'd want to modify this file: http://bazaar.launchpad.net/~ubiquity-slideshow/ubiquity-slideshow-ubuntu/html/view/head:/slideshows/xubuntu/slides/00_welcome.html
[15:23] <jjfrv8> well it happened. I finally got bit by the lp name change :(
[15:23] <knome> hmm?
[15:23] <jjfrv8> permission denied. no such lp account jjfrv8-gmail
[15:24] <knome> ah
[15:24] <knome> that's fixable
[15:24] <knome> just a sec and i'll find the necessary info
[15:24] <knome> edit ~/.bazaar/bazaar.conf
[15:24] <knome> basically just update launchpad_username
[15:24] <knome> then try again
[15:25] <jjfrv8> just a sec
[15:25] <knome> good day elfy :)
[15:26] <elfy> on and off - on at the moment :)
[15:26] <elfy> managed to get to work today and the meds have started working now 
[15:27] <knome> good, hope they work for you
[15:28] <jjfrv8> ok, had to do authentication.conf as well. fetching now
[15:28] <knome> cool
[15:28] <jjfrv8> ls
[15:29] <jjfrv8> oops
[15:29] <knome> hehe
[15:29] <jjfrv8> got it
[15:29] <knome> ok, so look at /slideshows/xubuntu/slides
[15:30] <jjfrv8> ok
[15:30] <knome> 17:22  knome: those are the 8 (9) html files that are shown for the user during  installation
[15:31] <knome> (sorry for rushing...)
[15:31] <knome> those files are pure html
[15:31] <jjfrv8> ok, I see the welcome one that has the offending version number
[15:31] <knome> there's already a merge proposal for that
[15:31] <jjfrv8> oh yeah, we're not working on that :)
[15:32] <knome> but yes, simply edit the file
[15:32] <knome> you are usually fine editing stuff that's insde the div with the class "content"
[15:32] <knome> now, as a test, udpate the version number
[15:32] <knome> and save the file
[15:33] <jjfrv8> yup
[15:33] <knome> then open a terminal for the root for that branch
[15:33] <knome> and type: ./test-slideshow.sh xubuntu
[15:33] <knome> (you can tabcomplete with ./te[tab] ...)
[15:34] <knome> this will basically allow you to preview the changes
[15:34] <jjfrv8> might have to do this on another machine? ./Slideshow.py: /usr/bin/python3: bad interpreter: No such file or directory
[15:34] <knome> hmm.
[15:34] <knome> you'll have to install stuff.
[15:34] <knome> let me figure out what
[15:36] <knome> what xubuntu version are you running on that machine?
[15:37] <jjfrv8> P
[15:37] <knome> is the package "python3" available?
[15:37] <knome> i guess it should
[15:38] <knome> installing that should fix your problem
[15:38] <knome> because using the parameter on the script directly should avoid the need of zenity
[15:38] <jjfrv8> yes, that pkg is available
[15:40] <jjfrv8> File "./Slideshow.py", line 4, in <module> from gi.repository import GLib, Gdk, Gtk, WebKit
[15:40] <jjfrv8> ImportError: No module named gi.repository
[15:40] <knome> humpf
[15:41] <knome> try apt-get build-dep ubiquity-slideshow-ubuntu
[15:41] <knome> not sure if that helps..
[15:41] <knome> but i can't check because obivously i have all the packages
[15:43] <jjfrv8> nope, same error
[15:44] <knome> bah.
[15:45] <slickymaster> knome: by the way and regarding https://launchpad.net/bugs/1213933 I didn't manage to find the slide that contains the text mentioned in the bug description
[15:45] <knome> try installing python3-gi
[15:46] <jjfrv8> k
[15:46] <knome> slickymaster, that's in 00_welcome.html, last paragraph
[15:46] <jjfrv8> woohoo
[15:47] <knome> slickymaster, at the moment, there is no way to probe if the user is on the live mode, or the direct install mode
[15:47] <jjfrv8> you da man
[15:47] <knome> jjfrv8, cool, so it works? :)
[15:47] <jjfrv8> yup
[15:47] <knome> slickymaster, you could poke lderan about that though...
[15:47] <knome> jjfrv8, ok, so that's what you have locally
[15:47] <slickymaster> knome: i'll annoy him on that 
[15:48] <knome> jjfrv8, you basically just want to check things do not overlap, or look too tight (we have translations as well, and it's hard to predict how much (more) space they will use)
[15:48] <knome> jjfrv8, after you're happy with your changes, just follow the normal merge request process
[15:48] <slickymaster> knome: I could had fix that yesterday with my https://code.launchpad.net/~slickymaster/ubiquity-slideshow-ubuntu/ubiquity-slideshow-ubuntu/+merge/198184 proposal
[15:48] <knome> jjfrv8, and you can mark me as the reviewer.
[15:48] <jjfrv8> ok
[15:49] <slickymaster> knome, jjfrv8, do you want me to re-propose or is jjfrv8 doing it?
[15:50] <jjfrv8> up to knome, might be easier to just have one MP
[15:50] <knome> slickymaster, no need to, i'll handle that
[15:50] <slickymaster> ok
[15:53] <jjfrv8> knome, do you have time for a couple more questions on the BP?
[15:56] <knome> jjfrv8, sure
[15:57] <jjfrv8> ok, a couple of the items require a discussion with either -doc or -team. do you have a suggestion on how to convene such a thing?
[15:58] <knome> jjfrv8, either the -devel mailing list or the irc meeting
[15:59] <knome> jjfrv8, starting the discussion in the mailing list is probably a good idea, then add an item in the meeting agenda (preferably for a meeting you can attend) to discuss it further
[15:59] <knome> and ideally, leave a week or so time in between so people have time to read and reply
[15:59] <jjfrv8> alrighty
[16:00] <jjfrv8> and what about these reports we're supposed to be doing
[16:01] <knome> jjfrv8, pleia2 did them for last month, https://wiki.ubuntu.com/Xubuntu/TeamReports/13/November for that
[16:01] <knome> and https://wiki.ubuntu.com/Xubuntu/TeamReports for the current report
[16:01] <knome> they are mostly gathered from the meeting minute "team updates"
[16:02] <elfy> hi jjfrv8 
[16:03] <jjfrv8> hey, elfy. glad you're feeling a little better
[16:03] <elfy> thanks :)
[16:03] <jjfrv8> knome, oh, I thought each subteam was supposed to be doing reports
[16:03] <knome> jjfrv8, well yeah... during the meetings :)
[16:04] <jjfrv8> i misunderstood. happens a lot :)
[16:06] <elfy> jjfrv8 can join my special team then :)
[16:13] <knome> elfy, hah ;)
[17:08] <slickymaster> Gotta go. Be back after dinner
[21:23] <slickymaster> night all
[21:31] <slickymaster> lderan, presently, when installing, there is no way to probe if the user is on the live mode or the in direct install mode
[21:31] <slickymaster> lderan, do you think that something could be done to circumvent this?
[21:33] <lderan> its a possibility, to what end tho?
[21:34] <Unit193> https://launchpad.net/bugs/1213933
[21:34] <slickymaster> exactly
[21:34] <slickymaster> thanks Unit193 
[21:35] <lderan> ah i see
[21:35] <Unit193> *Technically* all you'd have to do is check /proc/cmdline for only-ubiquity, right?
[21:35] <Unit193> Not saying that's the best way though.
[21:36] <lderan> shall look into it :)
[21:39] <slickymaster> afk
[21:43] <Unit193> ochosi: Action required for bug 1223808
[22:34] <ali1234> oh wooooow
[22:35] <ali1234> see this bug: https://bugzilla.xfce.org/show_bug.cgi?id=10384
[22:35] <ali1234> it's actually this bug (in gtk) https://mail.gnome.org/archives/commits-list/2013-November/msg02758.html
[22:35] <knome> ali1234, have you got a patch for it? ;)
[22:35] <ali1234> no patch needed
[22:35] <ali1234> gtk already fixed it
[22:36] <knome> heh, ok
[22:36] <knome> good then
[22:36] <ali1234> although to be honest xfwm4 could be smarter about it
[22:36] <ali1234> basically it boils down to there's one hint that says "never give me focus" and another one that says "give me exclusive focus"
[22:37] <ali1234> and gtk was stupid enough to set them both at the same time
[22:37] <knome> :P
[22:38] <knome> bah, i should take down my second monitor tomorrow
[22:38] <knome> oh oops, -devel
[22:41] <ochosi> hey ali1234 
[22:44] <ali1234> hi
[22:45] <ochosi> how's it going?
[22:45] <ochosi> i read a lot of stuff in the backlog over the weekend
[22:46] <ochosi> is the indicator-stuff going to be fixed in the stack or will there be more changes in the xfce plugin?
[22:47] <ochosi> i also read something in -desktop that indicators will now optionally be launchable via upstart *and* dbus
[23:14] <ali1234> the indicators should get fixed in the stack
[23:14] <ali1234> how is not yet decided
[23:14] <ochosi> ok, well that's at least partly good news
[23:15] <ochosi> so the xfce plugin will remain as it is for now?
[23:17] <ali1234> yeah
[23:18] <ochosi> ok, that sounds nice
[23:18] <ochosi> i also read you were considering to work on the xfwm4 compositor wrt syncing
[23:20] <ali1234> yeah
[23:20] <ali1234> i'm trying to fix this focus bug at the moment though
[23:20] <ali1234> it looks like xfwm4 is actually behaving totally correctly and it really is a pure gtk bug
[23:20] <ochosi> that sounds really nice, i tried the vblank stuff with nvidia and here it's terrible
[23:20] <ali1234> heh, vsync
[23:20] <ochosi> oh, but will gtk2 bugs still get fixed/patches merged
[23:20] <ali1234> i don't know
[23:20] <ochosi> oops, yeah sync to vblank or whatever nvidia called it
[23:23] <ochosi> so wait, the same bug exists in gtk2 that was just fixed in gtk3.10?
[23:25] <ali1234> i guess so
[23:25] <ali1234> the xfce-notifyd sets accept focus false, ans xfwm4 sees it as a TAKE_FOCUS window
[23:25] <ali1234> which means the window will manage it's own focus
[23:25] <ochosi> wow, quite the long standing issue...
[23:25] <ali1234> but it doesn't
[23:25] <ochosi> wonder why no-one ever noticed it
[23:25] <ali1234> maybe xfwm4 really is at fault here
[23:26] <ali1234> because you need a really weird edge case to find it
[23:26] <ali1234> open two terminals, set one always on top, run "notify-send hello" in the other one
[23:26] <ali1234> focus jumps to the always on top terminal when the notification closes
[23:29] <ochosi> hm
[23:30] <ochosi> does sound like a bit of a corner case
[23:34] <ali1234> about vsync: i talked with the compton developer yesterday
[23:35] <ali1234> there's a lot of ways to implement vsync, and which ones are available depends on the driver you use
[23:35] <ali1234> nvidia doesn't support drm and this is the only vsync method in xfwm4
[23:35] <ochosi> hm, i see
[23:35] <ali1234> the only other method which is any good is to use opengl double buffering
[23:35] <ali1234> but opengl compositing is really slow with nvidia
[23:35] <ochosi> does compton do that?
[23:35] <ali1234> yes it does
[23:36] <ochosi> hm, yeah, it did feel a bit slow here
[23:36] <ali1234> but it will basically halve your framerate
[23:36] <ochosi> i never used it for long for that reason
[23:36] <ochosi> hmpf
[23:36] <ali1234> so i have a plan to fix it
[23:36] <ali1234> use xrender to composite the windows and then do the final draw with opengl
[23:36] <ochosi> that sounds more than lovely
[23:36] <ochosi> ah
[23:37] <ali1234> this is a bit complicated though
[23:37] <ochosi> and that works with "any" driver?
[23:37] <ali1234> no
[23:37] <ali1234> it will work with nvidia though
[23:37] <ali1234> on everything else you can use drm
[23:37] <ochosi> ah
[23:37] <ochosi> so xfwm4 or the user will have to figure out what driver is in use
[23:37] <ochosi> is nouveau any better with all of this?
[23:38] <ali1234> it supports drm
[23:38] <ali1234> but i can't use it
[23:39] <ochosi> me neither
[23:39] <ochosi> power management is totally out of control with it, it seems
[23:41] <ali1234> my card just freezes after about 30 minutes
[23:42] <ali1234> maybe it overheats
[23:42] <ali1234> i dunno, but it is unusable
[23:42] <ochosi> also have problems with suspending
[23:43] <ochosi> with nvidia it seems fine, with nouveau, not so much
[23:45] <andrzejr> ali1234, I hope RENDER <0.11 is good enough for that, or at least this feature is going to be optional.
[23:45] <ali1234> RENDER isn't involved directly
[23:45] <ali1234> andrzejr: btw, what did you find for XRenderCreateSolidFill?
[23:47] <andrzejr> just like #cairo guys suspected the culprit was RENDER <0.11, haven't filed a bug report yet, though.
[23:48] <andrzejr> I was referring to "use xrender to composite the windows and then do the final draw with opengl"
[23:48] <ali1234> yeah i know
[23:49] <ali1234> and i was refering to whether your RHEL machine has XRenderCreateSolidFill, which i just added to xfwm4...
[23:50] <andrzejr> ah, OK. I wasn't aware of it. I will check you version when I have some time.
[23:50] <ali1234> also, do you know anything about the focus mechanics inside xfwm4?
[23:50] <ali1234> i'm pretty sure this is Wrong, but i don't know how to fix it
[23:50] <andrzejr> nope, sorry
[23:52] <andrzejr> I have a long list of issues with xfwm4, mostly things like handling multiple monitors, newly added tiling, some weirdness with windows moving/shrinking when changing themes etc.
[23:52] <andrzejr> If you are going to give xfwm4 some time that would be much appreciated.
[23:54] <ochosi> +1
[23:57] <ali1234> i wish i knew what this "pending_focus" var was actually supposed to mean
[23:58] <ali1234> it's the key to all of this, because the notify window gets set in pending_focus, but never takes focus (because it is given control of whether to take it or not)
[23:58] <ali1234> but then when it closes, because it is pending, xfwm4 acts as if it actually was the focused window