[03:58] <RAOF> smspillaz: Ping, re your -intel driver problems.
[04:00] <ssj6akshat> !logs
[04:06] <smspillaz> RAOF: pong
[04:07] <RAOF> smspillaz: Just pinging again to check whether (a) your drivers are still broken, and (b) when you'd like to debug this.  Pre alpha-1 would be nice for me :)
[04:07] <smspillaz> RAOF: let me update and check
[04:09] <RAOF> Ta.
[04:10] <smspillaz> completely unrelated but do you know if there was a recent update that broke GIO?
[04:11] <smspillaz> I'm getting these weird stack smashing bugs when using g_file_new_for_path
[04:18] <RAOF> Hm, no I was not aware of that.
[04:19] <RAOF> If we're trading bugs, do you know that compiz crashes when you enable or disable plugins? :)
[04:19]  * RAOF is currently rebuilding unity to grab debugging symbols for the backtrace.
[04:20] <smspillaz> RAOF: is this with unityshell enabled?
[04:20] <RAOF> Yes.
[04:21] <smspillaz> RAOF: maybe unityshell is doing something stupid in it's destructor
[04:21] <RAOF> Why would unityshell's destructor be called to enable an unrelated plugin?
[04:21] <smspillaz> if a plugin wants to load before another, the entire plugin stack of plugins that need to load after that plugin need to be popped (So that we can handle WRAP/UNWRAP chains without asploding)
[04:22] <RAOF> Oh, wow.  Fair enough.
[04:22] <smspillaz> and unityshell has to load last in order to get the paint order stuff right
[04:22] <RAOF> Heh.  Such as painting over the cursor when ezoom is active!
[04:22] <smspillaz> yep
[04:22] <smspillaz> I'm going to fix that at some point really
[04:23] <smspillaz> well really, the thing is that unityshell just goes ahead and reset the entire opengl context, paints, and then restores it
[04:23] <smspillaz> so naturally it wants to go on top of everything
[04:23] <smspillaz> maybe we should make ezoom load after unityshell
[04:23] <RAOF> I suspect you could also poke cnd; he's tasked at evaluating whether the input-redirection are worth pushing to Natty & upstream.
[04:23] <smspillaz> eh, not at this point
[04:24] <RAOF> Of course, he's *also* tasked with making X's input stack work, so he might be a bit busy :)
[04:24] <smspillaz> it's more of a wishlist thing, but the compiz stuff needs to be written properly
[04:24] <smspillaz> RAOF: IMO if/when we start looking at wayland in about a year (did you know that kwin is already half ported to it?) we'll get input redirection for free there and it will be much less of a hack
[04:25] <RAOF> Do we actually get input redirection for free there?  I genuinely don't know; I thought wayland's input handling was one of the more WIP places.
[04:26] <smspillaz> RAOF: compositor and server are the same thing, so we get all the input events before they got to clients
[04:26] <RAOF> Ah.  Making that a whole lot easier.
[04:26] <RAOF> Right.
[04:26] <smspillaz> RAOF: indeed. the input redirection patches right now involve a lot of roundtrips with a lot of bandwidth
[04:26] <RAOF> Yes, that's why IR was hard!
[04:27] <smspillaz> RAOF: it's like, for every paint, you need to do a round-trip and send XComposite all of your transformation maps
[04:27] <smspillaz> it well it was either one round trip per event (eg XeVIE which died very quickly) or one round trip per paint
[04:27] <RAOF> Urgh.  For every paint?  Ow.
[04:27] <smspillaz> I guess you could cache input maps and only send changed ones
[04:28] <smspillaz> one round trip per event is still more expensive though
[04:28] <smspillaz> RAOF: I actually had input redirection working on my old install - it wasn't really *that* expensive
[04:29] <smspillaz> still more expensive than it would ever be with wayland
[04:29] <smspillaz> then again, we have round trips for all kinds of stupid things
[04:30] <smspillaz> like ConfigureRequest! (shudder)
[04:30] <RAOF> Yeah.  X is totally awesome at network transparency :)
[04:31] <RAOF> Anyway, how's your graphics now?
[04:31] <smspillaz> upgrading
[04:31] <RAOF> Ah.
[04:31] <TheMuso> smspillaz: If ezoom loaded after unityshell, would that solve the problem of the launcher and top panel not being included in the magnified image on screen, i.e you can't zoom in on the panel/launcher?
[04:31] <smspillaz> this netbook is SLOW
[04:31] <chains> LOL did someone just say X is totally awesome at something and not mean it sarcastically?
[04:32] <smspillaz> TheMuso: no it wouldn't
[04:32] <TheMuso> Oh ok.
[04:33] <smspillaz> TheMuso: the problem is that we reset the entire ogl context, then paint all of our nux widgets and then restore it
[04:33] <TheMuso> Lovely.
[04:35] <RAOF> chains: No, that was sarcasm.  X loves roundtrips, which makes network latency fun!
[04:38] <smspillaz> the envthe nvidia driver love being fantastically awful ?
[04:39] <smspillaz> *why does the
[04:39]  * smspillaz growls
[04:40] <TheMuso> Its nvidia wanting to make less work for themselves by using the one binary blob for all *nix probably...
[04:40] <smspillaz> TheMuso: actually it's the same code across windows, osx and linux
[04:40] <smspillaz> yeeehaw another kernel oops
[04:40] <TheMuso> Oh wow ok.
[04:40] <TheMuso> ouch
[04:40] <smspillaz> and another one
[04:41]  * smspillaz reboots before everything asplode
[04:41]  * TheMuso is glad he switched to a card with open drivers for this cycle.
[04:41] <TheMuso> Although that won't help my laptop for the Dallas sprint.
[04:45] <RAOF> There's always nouveau :). It might even have power management support by then.
[04:46] <TheMuso> But that won't help with 3D...
[04:46] <TheMuso> Or will it?
[04:46] <TheMuso> I.e without me having to isntalle xtra bits.
[04:46] <RAOF> Well, you'll be able to install libgl1-mesa-dri-experimental, and expect it to work.
[04:47]  * smspillaz has nouveau running on arch, but uses nvidia on his ubuntu install
[04:48] <TheMuso> RAOF: Hrm ok that will be interesting.
[04:49] <smspillaz> RAOF: I assume this means that holding my laptop will also not give me third degree burns?
[04:49] <RAOF> You can do it on Maverick, too.  The main problem is lack of power management.
[04:49] <RAOF> smspillaz: Once natty switches to 2.6.38, yeah.  As long as the power-management patches make it into 2.6.38, of course.  That seems a reasonable bet, though.
[04:53] <smspillaz> RAOF: :p
[04:55] <TheMuso> How much testing has sed aptches had so far?
[04:58] <RAOF> Lots of testing on the developers' machine.
[04:58] <RAOF> Not so much elsewhere, as far as I can tell.
[05:00] <RAOF> Mmm, debugging compiz from the same machine.  Yay!
[05:02] <TheMuso> Right.
[05:05] <smspillaz> RAOF: did you get that bt?
[05:06] <RAOF> Yup.
[05:07] <smspillaz> can I haz it?
[05:07] <smspillaz> (ugh this glib bug is a stack smash, NOT FUN)
[05:07] <RAOF> bug #682550
[05:10] <smspillaz> oh wtf, this happens when the unityshell plugin is reloaded
[05:10] <smspillaz> eg in the constructor
[05:11] <smspillaz> RAOF: there's no line numbers in that bt :( could you build from source or add the -dbgsym packages?
[05:11] <smspillaz> well, no line numbers where I am interested anyways
[05:11] <RAOF> Right, in libunityshell.
[05:12] <RAOF> I think that's because cmake isn't actually generating debugging information; that was an unstripped build.
[05:12] <smspillaz> RAOF: did you build in Debug or Release mode?
[05:12]  * RAOF throws faeces at the wall of cmake
[05:12] <RAOF> Why is there a Debug mode?!
[05:13] <smspillaz> There is Debug and Release mode?
[05:13] <smspillaz> it's basically just a string you can specify which automatically passes the right options to gcc
[05:13] <smspillaz> but you can specify them too manually
[05:14] <smspillaz> hit 't' in ccmake and you can see all the flags
[05:14] <RAOF> I mean, why isn't it always built with debugging symbols?
[05:14] <smspillaz> it should be
[05:14] <smspillaz> maybe someone changed the cmake file so that it wasn't *shrug*
[05:14] <smspillaz> also this gio bug is a massive wtf
[05:14] <smspillaz> g_file_new_for_path ("/home/unity/foo"); == stack smash
[05:15] <RAOF> Funky!
[05:16] <smspillaz> ARGH wth!
[05:16] <smspillaz> like anywhere I use that function I get a stack smash
[05:16]  * smspillaz adds this to the incredibly long list of reasons he hates glib
[05:18]  * smspillaz hurls a brick at gnome
[05:24] <smspillaz> WHUT
[05:24] <smspillaz> WHU
[05:24] <smspillaz> WHUT
[05:24] <smspillaz> quit
[05:24] <smspillaz> someone mark this blocker for A1
[05:25] <smspillaz> unless I'm using glib completely incorrectly
[05:25] <smspillaz> int main (void)
[05:25] <smspillaz> { GFile *file = g_file_new_for_path ("/home/unity/Downloads");
[05:25] <smspillaz> return -1;
[05:25] <smspillaz> };
[05:25] <smspillaz> THAT should not segfault
[05:28] <RAOF> Don't you need to do the various glib init dances?
[05:29] <smspillaz> I might need to
[05:29] <smspillaz> that's what I was thinking of
[05:29]  * smspillaz shoots the person whoever's idea it was to try and do OO in C
[05:29] <smspillaz> this is just _bizzare_ since it worked perfectly beforehand
[05:29] <RAOF> I'd suspect that might be trying to call a lock function that hasn't yet been initialised by g_thread_init() ?
[05:29] <RAOF> Maybe?
[05:30] <smspillaz> it was doing something weird
[05:30] <smspillaz> like a jump to non code location
[05:30] <RAOF> That could be it.
[05:35] <smspillaz> yeah that gets me past that crash at least
[05:35] <smspillaz> argh I still hate this
[05:37] <RAOF> Gar.
[05:37] <RAOF> Ok.  I pointed you at g_thread_init, could you point me at how to get damn debugging symbols out of cmake?
[05:38] <smspillaz> RAOF: ccmake, press "t" and in CMAKE_CXX_COMPILER_FLAGS (or whatever it is) make sure that "-g" is in every single one
[05:38] <RAOF> Hm.  What, if anything, calls CMAKE_STRIP?
[05:39] <smspillaz> maybe there is something in the cmakelists.txt ?
[05:39] <smspillaz> it shouldn't do that though
[05:40] <RAOF> Hm.  Grep comes up silent.
[05:41] <smspillaz> RAOF: did you try adding "-g" to everything?
[05:42] <RAOF> Just trying again.
[05:44] <bratsche> smspillaz: What's the problem with g_file_new_for_path?
[05:44] <bratsche> It works for me.
[05:44] <smspillaz> bratsche: it was dying on a jump to non code location, but that was due to us somewhere along the line not calling g_type_init ()
[05:45] <bratsche> Yeah, you need to call g_type_init()
[05:45] <smspillaz> ;-)
[05:46]  * bratsche fears that code which is jumping around the init fu
[05:46] <smspillaz> ugh
[05:46] <smspillaz> I wonder who had the idea of writing an object system in C
[05:46] <smspillaz> now we all have to deal with it
[05:48] <bratsche> Well, I think we didn't have good C++ compilers back when the idea first came up. :)
[05:48]  * smspillaz figured
[05:48] <bratsche> And C++ kind of blows anyway.  Although so does an object system in C.
[05:48] <RAOF> Modern C++ is actually quite new.
[05:48] <RAOF> Younger than gobject :)
[05:56] <bratsche> And gobject isn't really where the C object system started.  Before that was the original GtkObject, which wasn't as advanced but was basically still an OO system in C.
[05:56] <bratsche> And I'm sure there were things before that.
[05:57] <RAOF> And C++ *still* has ABI problems.
[05:57] <bratsche> C++ is a horrible language.  I'm amazed that any new project would choose it.
[05:58] <bratsche> Except for a Qt-based app.  It would choose C++ simply because Qt is a good toolkit, and that makes sense.
[05:58] <bratsche> I kind of liked C++ for a couple years when I was using it.  But I got over it. :)
[05:59] <RAOF> There's a lot of fun stuff :)
[06:10] <RAOF> Incidentally, why can't you build unity in the source directory?
[06:11] <TheMuso> Thats a cmake thing afaik...
[06:27] <kvalo_> morning
[06:32] <RAOF> smspillaz: bug #682550 updated.  You're looking for /home/chris/Temp/unity-3.2.0/src/unity.cpp:352
[06:35] <hyperair> smspillaz: you could try using glibmm properly.
[06:38] <RAOF> Heh.  libunityshell.so probably doesn't need -Wl,-rpath,:::::::::::::::
[06:41] <hyperair> smspillaz: did you remember to call g_type_init()?
[06:42] <hyperair> http://paste.debian.net/101001/ <-- this works fine, but if you didn't do g_type_init, it segfaults
[06:42] <RAOF> Yeah, that got resolved with a quick g_type_init
[07:10] <smspillaz> RAOF: ok
[07:11] <RAOF> Also, I think I've fixed the unity build to actually generate debug symbols!  Woot!
[07:25] <RAOF> Unity's not maintained in bzr at all?
[07:25] <smspillaz> RAOF: lp:unity ?
[07:26] <RAOF> That's not the packaging though, is it?
[07:26] <smspillaz> it's the source
[07:26] <smspillaz> not sure where the packaging happens
[07:27] <RAOF> Well, I want to commit or propose a merge for the packaging, so that other people can just apt-get instal unity-dbgsym rather than futz around with cmake and local builds.
[07:27] <smspillaz> talk to didrocks about it
[07:27] <RAOF> didrocks will be here soon, so I can prod him.
[07:27] <RAOF> Heh.  Yeah.
[07:27] <smspillaz> yeah I need to poke him too
[07:27] <smspillaz> re my transition patch which doesn't crash
[07:28] <RAOF> Oh, yeah.  One of the python transitions things seems to be backtracing.  I should file that :)
[07:28] <smspillaz> I just fixed it now
[07:29] <RAOF> Yay!
[07:29] <smspillaz> that was the whole g_type_init () fail
[07:30] <smspillaz> I was only doing testing using ccsm (since ccsm uses lcc) except that I forgot that ccsm will call g_type_init () implicitly (eg gtk.main ());
[07:31] <RAOF> Ah, well.  I'm talking about a different bug then.
[07:32] <smspillaz> it's probably the same one
[07:32] <RAOF> This looks like a python traceback
[07:32] <smspillaz> oh right
[07:32] <smspillaz> that's probably because ccsm uses some deprecated gtk fun somewhere
[07:34] <RAOF> I don't think so.
[07:35] <smspillaz> what it actually crashes?
[07:35] <RAOF> http://pastebin.ca/2005504
[07:35] <smspillaz> oh that's didrocks fault
[07:35] <RAOF> Hah.
[07:36] <smspillaz> RAOF: also I hate my life because he got to write his transition module in python and due to gconfengine not having working pythong bindings I had to write it in C++ :(
[07:36] <RAOF> Oooh, harsh.
[07:36] <RAOF> How does gconfengine not have working python bindings?
[07:36] <smspillaz> yeah, now 1000 lines longer!
[07:37] <smspillaz> RAOF: I printed the object info in python and it has like one method
[07:37] <smspillaz> which tracebacks when you call it
[07:37] <smspillaz> It's just like *facepalm*
[07:37] <RAOF> That certainly *sounds* like not working bindings :)
[07:40] <smspillaz> whatever. it forced me to learn stuff so at least it was a good use of my time
[07:41] <smspillaz> like I had to learn GIO because someone decided that they hated boost and moved most of it to universe
[07:45] <RAOF> Hm.  You skillfully diverted me on to unity bugs.  What about your intel graphics? :)
[07:47] <RAOF> Yo yo didrocks!
[07:47] <didrocks> hey RAOF!
[07:48] <RAOF> Good weekend?
[07:48] <didrocks> yeah, very resting with a lot of snow here :) you?
[07:49] <RAOF> Had a board game day and a fine breakfast with my brother.
[07:49] <RAOF> And it's been plesantly mild.
[07:49] <didrocks> nice :)
[08:11] <smspillaz> didrocks: hi
[08:11] <smspillaz> didrocks: I've fixed that crash that some people were having, just going to mail the updated transition stuff to you now
[08:12] <didrocks> smspillaz: hey. oh nice! what was the cause?
[08:12] <kamstrup> smspillaz, didrocks, kvalo: morning
[08:12] <smspillaz> sometimes g_type_init wasn't called
[08:12] <didrocks> did the metadata was enough for you to debug?
[08:12] <didrocks> hum, and glib doesn't like that at all :p
[08:12] <didrocks> good morning kamstrup!
[08:13] <didrocks> kamstrup: completly fine after a week-end?
[08:13] <kamstrup> didrocks: more or less... we celebrated my daughters 5 year birthday all weekend, so it's nice with a "break" from it :-)
[08:13] <kvalo> kamstrup: good monday morning :)
[08:13] <kamstrup> didrocks: how about you?
[08:14] <kvalo> kamstrup: daddy having hangover from all that sugar? ;)
[08:14] <didrocks> kamstrup: very nice week-end there, still a lot of snow (and still snowing :))
[08:14] <kvalo> didrocks: nice!
[08:14] <didrocks> hey kvalo, how are you?
[08:14] <kamstrup> didrocks: here too
[08:15] <kvalo> didrocks: I'm good, thanks. a bit chilly though,  car showed -25 C!
[08:15] <didrocks> kvalo: ok, so having -2 C here is like the tropic for you :)
[08:15] <kvalo> didrocks: when can I move? ;)
[08:16] <didrocks> kvalo: hehe :-)
[08:16] <kvalo> didrocks: how are you?
[08:17] <didrocks> kvalo: I'm fine thanks, ready for an "alpha week" :)
[08:17] <kvalo> busy week then
[08:18] <RAOF> didrocks: Thinking of alpha week, can I point you at bug #682574 - it'd be nice to have debugging symbols available :)
[08:18] <didrocks> yeah, but now that unity is the default, it should be smoother ;)
[08:18] <RAOF> (There's a debdiff attached there)
[08:20] <didrocks> RAOF: hum, RelWithDbgSym != Release then?
[08:20]  * didrocks still hates cmake :)
[08:20] <RAOF> Release == no -g flag.
[08:20] <didrocks> ok, then, I think that the fix should be in Compiz CMake rather
[08:20] <didrocks> -DCOMPIZ_PLUGIN_INSTALL_TYPE=package
[08:20] <didrocks> -> should set the flag to RelWithDbgSym
[08:21] <didrocks> (as I guess, we have the same issue with compiz plugins)
[08:21] <smspillaz> didrocks: wouldn't you want package to have no debug syms?
[08:21] <RAOF> We do indeed.
[08:21] <RAOF> smspillaz: No, we automatically strip the debug syms out into a separate -dbgsym package
[08:21] <didrocks> smspillaz: well, in fact, there are stripped when built
[08:21] <smspillaz> yeah, but building them in the first place makes no sense
[08:22] <smspillaz> I suppose
[08:22] <RAOF> smspillaz: So normal people get unity, and people (or, say, the apport retracer) get to install the -dbgsym package and have debug symbols.
[08:22] <didrocks> depends as -DCOMPIZ_PLUGIN_INSTALL_TYPE=package is for packages and not release, I would have thought it complies with packaging requirements :)
[08:22] <didrocks> RAOF: yeah, I've already done the dbgsym discussion last Saturday :)
[08:22] <RAOF> Heh.
[08:23] <didrocks> RAOF: RelWithDebInfo -> -O2 & -g, right?
[08:24] <RAOF> didrocks: Yes.
[08:24] <RAOF> That's what it defaults to, at least.
[08:24] <didrocks> RAOF: ok, at least, I'll have a look at the compiz CMake files to make the package flags doing that
[08:24] <didrocks> as I don't want for every compiz package that we need to do it :)
[08:24] <RAOF> didrocks: That's a better idea than mine.  I see you're more familiar with CMake :)
[08:24] <didrocks> RAOF: *hem*hem*, I was ***forced*** to :)
[08:25]  * RAOF just wanted to get some debug symbols to throw at smspillaz 
[08:25] <didrocks> :)
[08:26] <dbarth> RAOF: hi Chris
[08:27] <dbarth> i just wanted to mention that i've had my first call with victorp last week
[08:27] <dbarth> to plan for you guys getting access to the unity test results we want to get from their HW lab
[08:27] <dbarth> ie, I did not forget, it's just taking some time
[08:34] <didrocks> RAOF: confirmed, patching the cmake file is working wonderfully well :) you'll soon be able to spam sam :)
[08:34] <TheMuso> 8/c
[08:34] <MacSlow> hey everybody
[08:34] <didrocks> hey MacSlow
[08:35] <MacSlow> salut didrocks :)
[08:35] <MacSlow> hey jo
[08:35] <MacSlow> no
[08:42] <RAOF> dbarth: Thanks.  We'll also get access to the test-suite itself, to run locally, right?
[08:45] <didrocks> RAOF: reporting compiz bugs against unity? :)
[08:46] <didrocks> dbarth: can you answer on bug https://bugs.launchpad.net/bugs/682499 ? I'm not quite sure what to tell about "non default" plugins + unity
[08:47] <dbarth> RAOF: yes (sorry was interrupted), that's still the plan
[08:48] <dbarth> didrocks: on it
[08:48] <didrocks> thanks :)
[09:00] <RAOF> didrocks: Oh, um... yes.  Whoops :)
[09:01] <didrocks> RAOF: can you kindly retarget? :p
[09:01] <didrocks> in any case, the apport scripts are the same, no worry :)
[09:01] <RAOF> But of courset.
[09:04] <dbarth> didrocks: so i've asked for a core, because i'm testing the plugin here, and it doesn't crash
[09:04] <didrocks> dbarth: oh, you're a cube user? :)
[09:04] <dbarth> even if we don't want to be compatible with all of them, we shouldn't crash
[09:04] <didrocks> sure
[09:05] <dbarth> nah, just tested when jcastro was mentioning the old panel was still there on the cube
[09:05] <didrocks> ok :)
[09:12] <smspillaz> didrocks: could you make a distro patch to remove the glib plugin from core too?
[09:12] <smspillaz> didrocks: also patches mailed
[09:13] <didrocks> smspillaz: right, doing the same in one upload
[09:13] <didrocks> smspillaz: thanks :)
[09:13] <didrocks> and then, rebuild every plugins to get debug info
[09:13] <smspillaz> yeah
[09:15] <didrocks> hum, can someone on natty (with latest unity) can just try to launch:
[09:15] <didrocks> gsettings get com.canonical.Unity.Launcher favorite-migration
[09:16] <htorque> 3.2.0
[09:17] <htorque> (if unity 3.2.0-0ubuntu3 is the latest one)
[09:17] <htorque> dbarth, i can reproduce the cube crash, how do i get a core dump?
[09:19] <TheMuso> didrocks: What are you expecting to get? I get ''
[09:19] <TheMuso> i.e nothing
[09:20] <njpatel> TheMuso, hey
[09:20] <njpatel> hey smspillaz
[09:23] <TheMuso> njpatel: Good morning.
[09:25] <dbarth> TheMuso: hey Luke
[09:25] <dbarth> TheMuso: good point in your email about the loader
[09:25] <TheMuso> dbarth: Good morning.
[09:26] <dbarth> sounds like we already have what it takes to have atk in compiz
[09:26] <TheMuso> Well, at least when unity is loaded.
[09:26] <smspillaz> njpatel: hi
[09:26] <smspillaz> I'll be out for 2 hours (and then back again afterwards) see you all :)
[09:26] <smspillaz> njpatel: I'm working on metacity now
[09:26] <dbarth> i've chatted a bit with smspillaz this morning btw, to clarify why the switcher was already accessible, while there is no atk/a11y code in compiz
[09:26] <njpatel> smspillaz, for the decorations right?
[09:26] <smspillaz> njpatel: yes
[09:27] <njpatel> dbarth, yep
[09:27] <dbarth> smspillaz explained that it's because the gtk decorator is helping render the switcher, and that's why orca is seeing it
[09:27] <smspillaz> I'm going to try and get a theme parser for those properties working today and then plug that into the decorator tomorrow ish
[09:27] <TheMuso> Right, that was my conclusion as well.
[09:28] <didrocks> TheMuso: yeah, bu you get something
[09:28] <didrocks> thanks htorque and TheMuso
[09:28] <dbarth> htorque: hi, er, you should get one already with apport
[09:28] <didrocks> not sure why some doesn't have gsettings CLI installed as it's part of -bin
[09:28] <dbarth> htorque: ie, it should be in /var/crash something; let me check
[09:29] <dbarth> yes. in /var/crash you should find a file that contains the compiz crash
[09:30] <dbarth> htorque: you may have to unpack it, ie use apport-unpack
[09:31] <njpatel> TheMuso, re: your email, menus opening inside windows: This is what I meant, Orca can't see the panel at all right now
[09:32] <htorque> dbarth, should it be compiz-gnome.0.crash?
[09:33] <TheMuso> njpatel: To my mind, this seems like 2 separate pieces, since using the F10 key triggers something inside GTK/Compiz's window manager to open menus. So... I suspect we need to grab that and make that happen in the panel instead.
[09:34]  * TheMuso knows what he is talking about in his head, but is finding it hard to put it into words.
[09:34] <htorque> dbarth, hm, no that's an old one. i don't get anything in /var/crash when i crash compiz/unity
[09:35] <njpatel> TheMuso, we could most likely do that
[09:36] <TheMuso> Either way, I don't see this as something needing atk work. Everything is accessible given focus, we just need to tie it together at the keyboard level.
[09:36] <TheMuso> Focus as in, once the menu has focus.
[09:38] <TheMuso> On another note, I have been looking into identifying menus like indicators via the framework. The issue is essentially that the menu is only identified with an image, and no text, so nothing gets presented as a description for that menu.
[09:38] <TheMuso> bbs, gonna grab some dinner and will be back.
[09:42] <htorque> dbarth, apport isn't yet enabled by default :-) attached CoreDump to the bug report
[09:47] <htorque> didrocks, about gsettings - should libglib2.0-bin installed by default? IIRC i manually installed it... (and when trying to remove it, only dev packages are marked for removal)
[09:49] <didrocks> htorque: I think it is, let me check
[09:50] <seb128> htorque, you can enable apport to catch crashes
[09:50] <htorque> dbarth, whew, i missed that CoreDump has 90+ MB, still want it?
[09:50] <seb128> don't add dump manually to bug
[09:50] <seb128> they can't be retraced
[09:50] <htorque> seb128, thanks, already did :-)
[09:50] <htorque> seb128, so what to do?
[09:51] <didrocks> htorque: you're right, it's not, I have to add it as a dep of unity :/
[09:52] <didrocks> or rewrite the transition plugin in C…
[09:53] <seb128> htorque, use apport to send the bug?
[09:58]  * TheMuso is back
[09:58] <htorque> seb128, there's already one. dbarth asked for a coredump. can i attach a backtrace instead of a 90+MB file? :-)
[09:59] <seb128> you can
[09:59] <seb128> you probably want to retrace it locally to get debug infos though
[10:00] <htorque> seb128, thanks, will do :-)
[10:03] <njpatel> TheMuso, (for when your back) through the panel, we are able to get a little more info about the indicators ("soundmenu", "datetime" etc, so we could even store some strings in Unity for translation for specific indicators)
[10:04] <TheMuso> njpatel: The issue is that the menus themselves are GTK, and thereby handled accessibility wise already, but since we only use images to identify the menus, there is no text for say orca to speak when moving to a new menu. I don't yet know enough about how GTK menus work to know whether we can slip in extra text for atk to present, without that text being visible.
[10:06] <njpatel> TheMuso, right, but as Unity knows that the user switched to the next/prev menu, could we announce something to orca?
[10:06] <njpatel> TheMuso, it could be done from the same gtk program (unity-panel-service) that actually shows the menus, so the same atk connection (or whatever it's called)
[10:07] <TheMuso> njpatel: I am not sure, and from what I understand so far, I don't think so.
[10:07] <TheMuso> Or...
[10:08] <TheMuso> It doesn't really help that I don't understand how much customization is possible with gtk menus + atk.
[10:11] <TheMuso> The only menus where this will be a problem is the indicators. This problem needs to be addressed for general GNOME/gnome-panel users, so I will do some digging tomorrow to see what I can discover about atk and menus.
[10:11] <njpatel> thanks
[10:17] <dbarth> htorque: a backtrace is better, yes ;)
[10:19] <dbarth> htorque: the thing is that i'd like to see if it's an easy fix or not; ie avoid crashing at least
[10:21] <dbarth> knowing that the rotating cube is probably *not* a plugin we will recommend with unity; the interface was not designed to work with it, the user experience is "different"
[10:39] <dbarth> gord: http://pastebin.ubuntu.com/537833/
[10:39] <gord> njpatel, your tests are breaking my tests again!
[10:39] <gord> njpatel, ^^
[10:40] <njpatel> dbarth, can't deal with it now, can fix after fixing what I'm working on
[10:41] <njpatel> have I said I hate CMake yet?
[10:43] <TheMuso> What code is actually responsible for creating the indicator menus and making them visible?
[10:44] <njpatel> TheMuso, the code in the indicator-* packages, which install .so files into /usr/lib/indicators/4/
[10:44] <TheMuso> njpatel: Yes but they go via dbusmenu right, so what actually does the rendering with gtk et al?
[10:45] <njpatel> TheMuso, unity-panel-service (unity/services/) is responsible for loading them
[10:45] <TheMuso> And in gnome-panel's case, indicator-applet, ok thanks.
[10:45] <njpatel> TheMuso, no, those files provide GtkMenus to the panel-service, internally they may use dbusmenu to share a menu between the .so and it's service, but we dont' see that
[10:45] <njpatel> TheMuso, yep, indicator-applet in the panels' case
[10:46] <TheMuso> njpatel: Ok so what I am interested in here is the gtk menu setup itself.
[10:46] <njpatel> gnome-panels*
[10:46] <TheMuso> Ok cool, thats enough to go on.
[10:46] <njpatel> TheMuso, that will happen in the .so's, so any indicator-* package
[10:46] <TheMuso> I *think* I may have a solution for labeling the indicators.
[10:46] <njpatel> sweet
[10:47] <TheMuso> Basically involves getting the atk object associated with the menu widget, and shoving some text into the atk object to identify it to the framework.
[10:48] <njpatel> nice
[10:48] <TheMuso> So far as I understand things anyway, hopefully I am right.
[11:09] <didrocks> smspillaz: is it wanted that libcompizconfig include CompizPlugin.cmake and not compizconfig-backend-gconf?
[11:10] <didrocks> (well, it's the ccp plugin, but that make libcompizconfig supporting COMPIZ_PLUGIN_INSTALL_TYPE=package with build type, but not compizconfig-backend-gconf)
[12:03] <njpatel> dbarth, can you try lp:~unity-team/unity/fix-panel-service-finalize please?
[12:03] <njpatel> dbarth, if it works, I'll merge-propose
[12:19] <kvalo> kamstrup: hi. what's the proper way to disgracefully check if gvariant type isn't as expected?
[12:22] <kamstrup> kvalo: g_variant_get_type_string()
[12:22] <kamstrup> kvalo:  the question is if the type string is interned so you can do == on it, ,or if you need to g_strcmp0 it
[12:23] <kvalo> kamstrup: interned?
[12:24] <njpatel> kvalo, you can do a pointer match if it's always a static string
[12:24] <kamstrup> kvalo: sorry, it's my Java background. Interned == "managed in an internal string pool so variants share the type strings"
[12:25] <njpatel> the same string*
[12:25] <kvalo> njpatel, kamstrup: ah, got it now. thanks :)
[12:26] <kamstrup> njpatel: do you get :
[12:26] <kamstrup> ERROR:valasemanticanalyzer.c:2953:vala_semantic_analyzer_get_actual_type: assertion failed: (instance_type != NULL)
[12:26] <kamstrup> on https://code.launchpad.net/~unity-team/unity/enable-vala-tests/+merge/42094 ?
[12:26] <njpatel> kamstrup, woah, no :/
[12:27] <njpatel> kamstrup, i'm on natty
[12:27] <njpatel> kamstrup, I don't think I touched the code much....
[12:27] <kamstrup> njpatel: odd, I am using valac from git master, so should be ~same
[12:28] <njpatel> ya
[12:28] <njpatel> let me do a clean compile
[12:32] <njpatel> kamstrup, builds fine with a fresh checkout of that branch
[12:32] <njpatel> kamstrup, you have gremlins in your system ;)
[12:41] <kamstrup> njpatel: what's your valac --version?
[12:43] <njpatel>  valac --version
[12:43] <njpatel> Vala 0.11.2
[12:43] <njpatel> kamstrup, ^
[12:45] <kamstrup> njpatel: hmmm, odd, I'm only a few revisions ahead of that
[13:57] <kamstrup> njpatel: !
[13:57] <kamstrup> njpatel: quick Dee API question
[13:58] <kamstrup> right now we have dee_model_get (model, iter, colN, &valN, colM, &valM, ..., -1)
[13:58] <kamstrup> this is nice because it's close to GtkTreeModel
[13:58] <kamstrup> ototh
[13:58] <kamstrup> in the new GVariant world it might be more natural to simply do:
[13:59] <kamstrup> dee_model_get (model, iter, &val1, &val2, ...) totally equivalent to g_variant_get() except we don't need the type string for the columns because the model knows that
[14:10] <kvalo> kamstrup: what about the poor programme, how can he remember that? ;)
[14:10] <kvalo> programmer*
[14:12] <kvalo> kamstrup: a question about g_simple_async_result_set_error(). I want to have my own error message in ui-proxy and was planning to use that function. but what should I use as GQuark?
[14:15] <lamalex> bon matin tout le monde
[14:16] <bratsche> Morning.
[14:16] <kvalo> good morning, lamalex and bratsche
[14:16] <njpatel> kamstrup, but dee_model_get (model, iter, 3, &val0, 6, &val9, -1); wouldn't work, right? You would only be able to get all of them or none?
[14:17] <tedg> kvalo, I don't think you need the quark, but people usually have a function to create a custom quark for their lib/process so that you can identify it.
[14:17] <njpatel> hey tedg
[14:17] <tedg> Morning njpatel
[14:18] <kvalo> tedg: good morning
[14:19] <kvalo> tedg: but I got this error: g_simple_async_result_set_error: assertion `domain != 0' failed
[14:20] <kvalo> tedg: any easy way to go around it?
[14:20] <tedg> kvalo, Ah, they must require it.  Just do this: "GQuark myquark (void) {statick GQuark quark = 0; if (quark == 0) quark = g_quark_from_static_string("myapp"); return quark; }" and then call that function to get the quark.
[14:21] <kvalo> tedg, bratsche: btw, I arrive to dallas already on saturday. if you have any tips for a good steak restaurant, I'm happy to hear them :)
[14:21] <tedg> kvalo, One? ;)
[14:22] <tedg> I think you're going to have a long week if you're only willing to eat steak once.
[14:22] <kvalo> tedg: hehe, good point :) I need several of them
[14:22] <bratsche> Too bad the best restaurant in Dallas just closed last week. :/
[14:22] <bratsche> After 10 years.
[14:23] <tedg> bratsche, Which one?
[14:23] <bratsche> York Street
[14:23] <tedg> Ah, shucks.  I hadn't been there -- it was on my TODO list :(
[14:23] <tedg> Apparently too many people had it on their TODO list as well :)
[14:23] <bratsche> No, that wasn't the issue.
[14:24] <bratsche> They had managed to maintain a good business even now.
[14:24] <kvalo> tedg: thanks for the quark tip, I'll do that
[14:24] <bratsche> There's a really good taco place in Deep Ellum, just east of downtown.
[14:25] <tedg> bratsche, Hmm, I might have to get that from you... love good tacos.
[14:25] <tedg> bratsche, Do you know if the light rail is on schedule?  The DART page still says the stop by the hotel is "opening Dec. 2010" but no more info.
[14:26] <bratsche> I have no idea at all. :/
[14:26] <bratsche> tedg: The taco place is at 2801 Commerce Street
[14:27] <tedg> bratsche, Looks like Dec. 6th is the date: http://www.dart.org/about/expansion/otherprojects.asp
[14:28] <bratsche> Weak
[14:28] <bratsche> Or maybe that's fine
[14:28] <bratsche> tedg: When is the sprint here?
[14:29] <tedg> bratsche, Should be fine, that's next week.  So they can be a month late :)
[14:29] <tedg> bratsche, Beginning of Jan
[14:29] <bratsche> Oh, awesome.
[14:29] <bratsche> Then Dec 6 works out just fine. :)
[14:29] <tedg> I'm more excited about Orange line to DFW in 2012...
[14:29] <bratsche> Yeah.
[14:29] <tedg> I'll have to see if stopping in Plano and just taking that makes sense for me or not.
[14:30] <tedg> I wish Allen and McKinney would get on board with DART :-/
[14:30] <bratsche> kvalo: I'm confused.. you're arriving to Dallas when?  This Saturday?
[14:30] <bratsche> tedg: I'm not surprised that Allen won't.
[14:31] <tedg> bratsche, I'm hoping all those retailers in the outlet malls and the other stuff there will push them into it.  Just to drive business.
[14:33] <kvalo> bratsche: sorry, I was "a bit" early. I will arrive on january
[14:33] <bratsche> kvalo: hehe.. okay cool. :)
[14:33] <kvalo> bratsche: just dreaming of a proper steak restaurant already now...
[14:34] <bratsche> kvalo: I'll help you find one.
[14:34] <kvalo> bratsche: cool! :)
[14:34] <bratsche> It won't be as good as York Street, but I'm sure we can find something good. :)
[14:34]  * kvalo expecting a different experience compared to uds at brussels
[14:49] <tedg> kvalo, No you should expect Texas is exactly the same as Brussels.  Europe in general is basically a mini-Texas.
[14:51] <kvalo> tedg: hehe :)
[14:56] <dbarth> lamalex: good morning as well
[14:57] <dbarth> lamalex: smspillaz is proposing a short call on perf. counters
[14:57] <lamalex> dbarth, sounds good tome
[14:57] <lamalex> to me, also
[14:57] <dbarth> lamalex: do you have 30 min (i can't stay longer, but feel free to continue with sam if needed)
[14:57] <dbarth> ;)
[14:58] <lamalex> yeah for sure, i have hours ;)
[14:58] <dbarth> cool
[15:04] <htorque> hello everyone, how can i set the position of a new indicator? i cloned indicator-datetime (i'll abuse it as my hello world), renamed everything and now it gets loaded as the first indicator and therefore sits left to the appmenu - not what i want.
[15:07] <lamalex> njpatel, if I remove the -DCMAKE_INSTALL_PREFIX completely, will it install to standard prefix? /usr/local?
[15:07] <tedg> htorque, The order is set in indicator-applet, there's no other control for it currently.
[15:08] <njpatel> lamalex, dude, no idea....it's cmake. I'm assuming so
[15:08] <lamalex> ill just set it :P
[15:10] <tedg> htorque, If you've got an app indicator you can set the position by setting the ordering_index
[15:10] <tedg> htorque, and njpatel has promised me all the app indicator ordering will work in Unity for Natty ;)
[15:11] <htorque> tedg, thanks, so it's always <any other indicator>, appmenu, application, sound, messaging, datetime, session?
[15:11] <njpatel> it already does!
[15:11] <njpatel> oh wait
[15:11] <njpatel> you mean for "other" indicators
[15:11] <tedg> htorque, Basically, except between datetime and session there is "me"
[15:12] <htorque> tedg, oh yeah, i uninstalled that one
[15:12] <njpatel> tedg, it would be appmenu, <foo indicator>, application, sound, message, datetime, me session, no?
[15:12] <tedg> njpatel, No for application indicators, so they end up in the right order.  In Maverick they ordering wasn't honored.
[15:12] <njpatel> tedg, oh, that's fixed (or should be)
[15:12] <njpatel> what's a good way to test?
[15:13] <tedg> njpatel, Probably should be, but we haven't really talked about what to do with other indicators -- figuring everyone would use app indicator if they wanted to extend things.
[15:13] <tedg> njpatel, Is your GNOME Power Manger next to your sound?
[15:14] <njpatel> yes! :)
[15:15] <njpatel> tedg, can we fix the indicator that prints "gtk_menu_detach()" warnings please? :)
[15:16] <tedg> njpatel, ?  Hmm, that must be indicator-appmenu... we detach them or GTK gets upset when we reattach, but I didn't think that was generating a warning...
[15:17] <njpatel> oh, there are tons of warnings from that
[15:17] <njpatel> everytime you switch windows
[15:17] <tedg> njpatel, Then stop switching windows!
[15:18] <njpatel> fine
[15:18]  * njpatel fullscreens gnome-terminal
[15:25] <jcastro> dbarth: we need a place to put API docs, who is working on that?
[15:25] <jcastro> we need like unity.ubuntu.com/API or something
[15:25] <jcastro> because the tbird guys are asking us about appmenu APIs and we have no place to put them
[15:25] <jcastro> ditto places, etc.
[15:26] <jcastro> and the appindicator api docs are living on people.canonical.com/~ted
[15:30] <jcastro> so something like api.ubuntu.com/10.04
[15:30] <jcastro> api.ubuntu.com/unstable
[15:30] <jcastro> etc.
[15:31] <jcastro> and then we import GTK docs and all that and have it generating them so they all hyperlink
[15:31] <tedg> jcastro, api.ubuntu.com/{distro release}/{source package name}/index.html
[15:31] <jcastro> ^^^
[15:31] <njpatel> gord, https://code.launchpad.net/~unity-team/unity/fix-panel-service-finalize/+merge/42124
[15:32] <njpatel> tedg, ooh, +1
[15:32] <gord> njpatel, \o/ thanks. but dbarth could you test that? as the tests were passing here anyway so it was something on your system tripping it up
[15:33] <didrocks> htorque: just looking at bugs, yeah enabling/disabling plugin in compiz crashes (when unity is enabled)
[15:33] <tedg> jcastro, What might be interesting is if we used the "natty vs. 11.04" names and changed them at release just to invalidate the Google links to the unstable docs.  i.e. Google would have to reindex.
[15:34] <jcastro> tedg: whatever works, I would be happy with "oh yeah we should do that" :)
[15:35] <htorque> didrocks, but they seem to work when starting compiz and they are enabled
[15:35] <didrocks> htorque: yeah, changing the plugin list dynamically is the issue
[15:36] <didrocks> not sure why, but can live with that for an alpha1 :)
[15:36] <htorque> sure :)
[15:42] <njpatel> didrocks, we don't like changing environments. We creatures of stability.
[15:42] <njpatel> We're*
[15:42] <didrocks> njpatel: well, you push the latest possible crack in the world and you tell "We creatures of stability", kidding? :)
[15:42]  * didrocks keeps that argument for next "one liner fix" :-)
[15:43] <njpatel> didrocks, it was a tongue-in-cheek comment :)
[15:43] <didrocks> njpatel: I know dude, kidding as well :-)
[15:43] <didrocks> njpatel: btw, there is a pending merge request of mine for this evening releas :)
[15:44] <njpatel> didrocks, okay, about to merge-propose the "show nautilus" stuff home button
[15:44] <didrocks> \o/
[15:44] <njpatel> didrocks, tomorrow morning release ;)
[15:44] <njpatel> didrocks, will review it after proposing mine
[15:44] <didrocks> what what?
[15:44] <didrocks> :)
[15:44] <didrocks> it sounds like we agree :-)
[15:44] <njpatel> didrocks, all branches will be ready by US end of day, will roll tomorrow morning first thing, sound good?
[15:45] <didrocks> njpatel: if there is no respin tomorrow, there will be no new "unity alpha1" :)
[15:45] <njpatel> didrocks, ah, nice
[15:45] <didrocks> njpatel: of course, you can argue it's time to break gnome-session or whatever to get a respin tomorrow :)
[15:45] <njpatel> didrocks, so what time today do you need it?
[15:45] <didrocks> njpatel: more seriously, sounds good :)
[15:45] <didrocks> njpatel: I think we will have some respin with maybe the indicator-nm
[15:46] <njpatel> ah, sweet
[15:46] <didrocks> njpatel: it's just fun to annoy you :)
[15:46] <njpatel> lol
[15:47] <jcastro> didrocks: njpatel I need bitesize bugs, please mark them as you see them
[15:47] <njpatel> jcastro, as soon as we're done with A1, yep
[15:47] <jcastro> njpatel: when does the milestone end for you?
[15:47] <didrocks> jcastro: ok, for alpha1 version?
[15:47] <njpatel> jcastro, tomorrow morning
[15:47] <didrocks> ok
[15:47] <jcastro> ah perfect
[15:47] <jcastro> I want announce thursdayish
[15:48] <didrocks> I have some on my list :)
[15:48] <didrocks> will get them to you
[15:48] <jcastro> along with the release so people know what to work on
[15:48] <njpatel> jcastro, then i can go through all the bugs with a massive clean up and also to start marking things out as bitesize
[15:48] <jcastro> didrocks: I am watching the lp tag, just tag them bitesize
[15:48] <njpatel> so then we're all set for thursday
[15:48] <didrocks> jcastro: ok, will maybe go with njpatel on the list
[15:48] <jcastro> nod
[15:48] <didrocks> njpatel: need for a thursday release btw? I would say no…
[15:48] <jcastro> try not to make them all boring either, nice little feature implementations would be great
[15:49] <didrocks> jcastro: oh I got this "rewrite using fluxbox", doesn't fit? :)
[15:51] <jcastro> didrocks: we need unity-xeyes
[15:51] <didrocks> jcastro: heh, awesome! the xeyes indicator :)
[15:52] <njpatel> I'm sure ted will love that
[15:52] <jcastro> it needs to be 60fps too!
[15:53] <jcastro> njpatel: I was wondering, since it's probably low priority for you ... what do you think about a an alt-f2/launcher place?
[15:53] <njpatel> So you'll be DOS-ing Unity from the panel service? :)
[15:53] <jcastro> or someone perhaps placeifying gnome do
[15:53] <njpatel> jcastro, doesn't really need to be a place, we had an idea to just show the search bar of the places for Alt+F2 and let you launch apps
[15:53] <jcastro> oh ok
[15:53] <didrocks> jcastro: it's more stripping the code from gnome-panel right now and build in an executable
[15:54] <jcastro> is that bitesizeable?
[15:54] <didrocks> I have a WI for that :)
[15:54] <jcastro> oh ok
[15:54] <jcastro> nm then
[15:54] <njpatel> didrocks, well, don't do that just yet
[15:54] <didrocks> njpatel: oh? you finally changed your plan?
[15:54] <cyphermox> hmmm placeifying gnome-do
[15:54] <jcastro> cyphermox: I know right? Brilliant
[15:54] <didrocks> njpatel: ok, no worry dude, as long as you tell me to do less work, I won't complain :)
[15:54] <njpatel> didrocks, yeah, so it looks nice. the gnome-panel one is if we cant' do anything else
[15:54] <njpatel> :)
[15:55] <didrocks> njpatel: just keep me in touch before feature freeze :)
[15:55] <njpatel> hah, sure :)
[16:00] <kvalo> kenvandine: hi. we are extending the indicator-network settings window and it's written in pygtk. as python and autotools don't work together so well, we are wondering if we should create a separate package for the settings window. what do you think?
[16:01] <kenvandine> sure
[16:02] <kenvandine> it would certainly be much simpler
[16:02] <kenvandine> but, it is extra release overhead
[16:02] <kvalo> kenvandine: how much extra work a new package will create?
[16:02] <kenvandine> since, at least for a while, you'll probably need to do releases for both at the same time
[16:02] <kvalo> kenvandine: yeah, the overhead is my worry as well.
[16:02] <kenvandine> from my side it isn't much
[16:02] <lamalex> didrocks, how do ddebs get update? the -dbgsym packages are broken as of your compiz update
[16:03] <lamalex> broken meaning conflicting with compiz
[16:04] <kvalo> kenvandine: ok, thanks for the answers. I'll try to have just one package, but I'll keep creating a separate package as plan b.
[16:04] <kenvandine> :)
[16:04] <kenvandine> kvalo, i know it is painful
[16:05] <kvalo> didrocks: do you have time tomorrow for a quick python+autotools session
[16:05] <kvalo> ?
[16:05] <kenvandine> kvalo, dobey might have some pointers
[16:07] <didrocks> lamalex: you mean, you don't have latest version?
[16:07] <lamalex> didrocks, I just tried to update and they conflict
[16:07] <didrocks> lamalex: well, did ou check what version is it?
[16:07] <didrocks> ddeb generation can take some time
[16:07] <didrocks> kvalo: sure
[16:08] <lamalex> there don't appear to be dbgsym packages for 0ubuntu2
[16:08] <kvalo> didrocks: nice. I'll ping you tomorrow and see if you have time
[16:09] <kvalo> kenvandine: thanks, all pointers are welcome :)
[16:09] <didrocks> lamalex: so, you have your answer, just wait for a couple of hours and they should be there :)
[16:09] <didrocks> kvalo: should be good once unity is released and uploaded
[16:10] <lamalex> didrocks, ok cool. i was just asking how they got updated ;)
[16:13] <kenvandine> didrocks, i am interested in how you make autotools and python play well together as well
[16:14] <didrocks> kenvandine: ok, so you're not interested :)
[16:14] <didrocks> (I read "play well" :))
[16:15] <kenvandine> haha
[16:15] <kenvandine> i briefly tried to do that years ago and gave up pretty quickly
[16:15] <didrocks> lamalex: yeah, it's automated… can take some time
[16:15] <lamalex> dbarth, did QA want to be able to pass coordinates to unity and get state of the item at those coords, or just be able to see coords in state output
[16:15] <didrocks> well, it's possible without a lot of headache, but it's not optimal
[16:16] <tedg> njpatel, DBO, you know instead of having these present hacks around, we should just have BAMF do it once.  That way when we fix Compiz we have one place to undo the crap.
[16:16] <tedg> I'm thinking perhaps more libbamf than BAMF itself.  But, we should isolate it.
[16:17] <kenvandine> didrocks, it would be nice to put the new gwibber vala client in the gwibber sources
[16:17] <kenvandine> so i have a new found interest in making it work :)
[16:17] <njpatel> Agreed, but then everything would need to link to libbamf, even things that don't need it
[16:17] <njpatel> tedg, ^
[16:17] <njpatel> tedg, i would have it once in libbamf and once in libindicate (rhythmbox never raises for me)
[16:17] <tedg> njpatel, Well, where everything is a pretty small set of things :)
[16:18] <njpatel> tedg, true, true
[16:18] <kenvandine> tedg, so for appindicator, adding gtk3 builds, do you think I need to keep the python bindings around for gtk2?
[16:18] <tedg> I'd rather have it in libbamf and then link libbamf to libindicate.
[16:18] <didrocks> kenvandine: oh, yeah, understood :)
[16:18] <tedg> kenvandine, Probably, as the GIR ones will be a slightly different API, no?
[16:18] <kenvandine> yes
[16:18] <tedg> kenvandine, Is there a way to do that conversion seamlessly?
[16:18] <kenvandine> i don't think so
[16:18] <kenvandine> however
[16:19] <kenvandine> people will just depend on the older python-appindicator...
[16:19] <kenvandine> and they won't get updated...
[16:19] <njpatel> tedg, makes sense
[16:19] <kenvandine> unless they port to the gir API
[16:19] <tedg> kenvandine, I consider that a distro question -- and I'll drop all the binding $%#$% as soon as you'll let me ;)
[16:20] <kenvandine> :)
[16:20] <kenvandine> wow.. no seb128...
[16:20] <kenvandine> didrocks, what do you think about that question?
[16:20]  * tedg 's worried about the state of space-time with no seb128
[16:21] <didrocks> hum, let me scrollback :)
[16:22] <kenvandine> tedg, do you plan to make big changes to appindicator for natty?
[16:22] <kenvandine> API that is?
[16:22] <tedg> kenvandine, We plan on adding a couple things, but it should all be backwards compatible.
[16:22] <kenvandine> just wonder if people using the python bindings will lose out much by not getting updated
[16:22] <tedg> kenvandine, I'd like to break Vala though as I think we can get it generated with the constructors correctly...
[16:23] <tedg> kenvandine, Not a lot, but some little things.
[16:23] <didrocks> kenvandine: yeah, yo uneed the python bindings
[16:23] <tedg> kenvandine, But, it'll loose out a lot if they try to bring in gtk2 and gtk3 into the same process :)
[16:23] <didrocks> kenvandine: for instance, gtkrecordmydesktop is not going to gtk3…
[16:23] <kenvandine> didrocks, yeah, but it will depend on the older python-appindicator
[16:23] <tedg> Don't know how Python protects from that stuff -- but there are some *critical* imports that should conflict.
[16:24] <didrocks> kenvandine: well, you mean removing the binding, so the python-appindicator support for gtk2?
[16:24] <kenvandine> didrocks, i mean removing the python bindings from the source and the package...
[16:24] <didrocks> I think if it's backward compatible, do not touch anything this cycle
[16:25] <didrocks> we have already enough to figure with GNOME3 without adding additional work that can be avoided :)
[16:25] <kenvandine> but apps would still be able to depend on the latest version of python-appindicator
[16:25] <kenvandine> :)
[16:25] <kenvandine> yeah
[16:25] <kenvandine> ok
[16:26] <kenvandine> tedg, lets make it a priority to get rid of that next cycle :)
[16:26] <tedg> kenvandine, k
[16:38] <kvalo> kamstrup: again a long one, but pretty simple: https://code.launchpad.net/~kvalo/indicator-network/libconnman-backend-2/+merge/42131
[16:50] <jono> didrocks, hey, is Unity now switched on by default in the natty daily ISOs?
[16:51] <didrocks> jono: yeah, it is :)
[16:52] <didrocks> jono: of course, should be check, but on upgrade or in the ISO, it should be the default
[16:52] <jono> didrocks, sweet :-)
[16:52] <jono> I can upgrade then :-)
[16:53] <didrocks> hehe, nice :)
[16:54] <jono> didrocks, is it pretty reliable?
[16:55] <didrocks> jono: I got no crash today, so I would say yeah :)
[16:55] <didrocks> jono: the migration compiz 0.8 -> 0.9 is the less tested part though
[16:55] <didrocks> so I'm interested in data there :)
[16:55] <jono> didrocks, cool :)
[17:12] <njpatel> didrocks, see, R-E-L-I-A-B-L-E. It's what we're all about.
[17:12] <didrocks> njpatel: hehe, let's see after A1 the number of bug reports :p
[17:12] <njpatel> :)
[17:23] <albyrock87> ping MacSlow
[17:23] <MacSlow> albyrock87, what's up?
[17:24] <albyrock87> MacSlow, I wrote you an email weeks ago, can you help me with one thing? Is there a way to have the subpixel antialias in an ImageSurface while drawing Pango layouts?
[17:25] <MacSlow> albyrock87, I replied to that, didn't I?
[17:25] <albyrock87> mh nope..
[17:27] <albyrock87> I didn't recive any email..
[17:28] <MacSlow> albyrock87, best example would be to check out notify-osd (bzr branch lp:notify-osd), cd notify-osd/tests, read through render_text_to_surface() at line 57 of test-scroll-text.c
[17:29] <MacSlow> albyrock87, that'll give you a nice example of a stand-alone code-sample doing what you're looking for.
[17:29] <albyrock87> MacSlow, ok thanks, I'm going to look at it right now :)
[17:29] <MacSlow> albyrock87, the "magic" line being 116 -> pango_cairo_context_set_font_options (pango_layout_get_context (layout), font_opts);
[17:30] <albyrock87> MacSlow, I already do this, using the font_opts from get_default_screen ().. But the rendering still have the GREY_ANTIALIAS
[17:30] <MacSlow> albyrock87, font-options is what you should care about
[17:31] <albyrock87> are you rendering into an ImageSurface right?
[17:31] <MacSlow> albyrock87, yup
[17:31] <MacSlow> albyrock87, maybe your system-settings don't use subpixel aa
[17:32] <MacSlow> albyrock87, you can set it explicitly by defining your own font-options... no need to take the one from the system
[17:32] <albyrock87> MacSlow, it uses subpixel, in fact, if I draw directly into the widget.window it works..
[17:32] <MacSlow> albyrock87, is your image-surface perhaps only A8?
[17:32] <dbarth> DBO: something for bamf or the launcher: http://imagebin.org/125328
[17:32] <MacSlow> albyrock87, you need a RGB24 at least
[17:33] <dbarth> DBO: may be it should say "(Unknown)" or something like that instead of an empty list
[17:33] <albyrock87> MacSlow, it's ARGB32,,
[17:33] <DBO> sorry
[17:33] <dbarth> a launcher thing actually, bamf should just report the empty string
[17:33] <MacSlow> albyrock87, hm... then I don't know
[17:33] <DBO> dbarth, will fix, thank you
[17:33] <MacSlow> albyrock87, see if the test-scroll-text.c works on your system and work from there
[17:34] <albyrock87> MacSlow, ok, now I try, thanks
[17:34] <MacSlow> albyrock87, good luck!
[17:39] <dbarth> didrocks: on natty, should i dist-upgrade today to get the latest packages, or is upgrade just fine?
[17:39] <didrocks> dbarth: upgrade should be fine
[17:48] <dbarth> k, thanks
[17:54] <dbarth> DBO: same issue, as a bug https://bugs.launchpad.net/unity/+bug/682787 (for your karma score ;)
[17:54] <DBO> dbarth, but I cant trade in Karma for music yet on Ubuntu One
[17:55] <sense> When will the menu items in the launcher's right click menu get labels again?
[17:55] <sense> proper lables
[18:17] <jcastro> tedg: can you check out bug #682786?
[18:18]  * tedg clicks
[18:19] <tedg> bratsche, Looks like an appmenu-gtk thing? ^
[19:30] <lamalex> hey guys, is it possible to manually start the panel service?
[19:32] <lamalex> tedg, ^ DBO ^
[19:32] <DBO> lib/unity/unity-panel-service
[19:39] <lamalex> oh man the order is all fucked now
[19:44] <jono> DBO, hey man, tried Unity in Natty, looking good
[19:45] <jono> any idea when the places and dash is due to land?
[19:45] <DBO> good to hear
[19:45] <jono> will it be in for A1?
[19:45] <DBO> I think design was slated to be semi-final by A1
[19:45] <DBO> so I guess that means A2
[19:45] <jono> gotcha
[19:45] <jono> cool
[20:21] <jono> cyphermox, great work on the network indicator
[20:21] <jono> I just tried it in natty, worked flawlessly :-)
[20:21] <cyphermox> jono, aha, check your memory usage anyway ;)
[20:22] <cyphermox> but thanks :)
[20:23] <jono> cyphermox, lol
[20:23] <jono> it's a great start, that's for sure :-)
[20:23] <cyphermox> hehe yeah
[20:23] <jono> unity is going to be *so* awesome in Natty :-)
[20:23] <cyphermox> it already started!
[20:23] <jono> yes indeed :-)
[20:23] <jono> brb
[20:32] <kenvandine> yay... NetworkManager in the indicator!
[20:32] <kenvandine> i am finally free to go work at the coffee shop again :-D
[20:43] <mterry> If compiz crashes, but doesn't give me a apport dialog or leave a file in /var/crash, how best should I file a bug?
[20:45] <mterry> (in natty)
[20:49] <sense> mterry: I've gathered information by running 'compiz --display :0' in tty1.
[20:50] <sense> The recent crashes often generate output there.
[20:50] <mterry> sense, will try next time
[21:57] <jamalta> sense is gone now, but i was going to ask about running compiz from tty1.. it seems to crash for me after a few seconds because of dbus
[21:57] <jamalta> does dbus create a separate user session when you login from tty1 vs logging in through gdm?