[03:42] <smspillaz> awesome, got the transition stuff hooked up with with the compiz launcher
[03:44] <spikeb> :)
[03:56] <smspillaz> DBO: ping
[03:57] <smspillaz> DBO: I don't see this wall issue here (intel)
[03:57] <smspillaz> DBO: due to some driver bug I can't get unity running on this nvidia laptop (it's my fault, fubar'd)
[03:57] <smspillaz> DBO: could you pastebin the output of compiz in a terminal when it happens? maybe the plugins are loading a weird oorder
[03:57] <smspillaz> DBO: basically, the unityshell plugin should always come last, no matter what
[03:59] <smspillaz> erm well it should always come last in theory, but due to the way you've written it it needs to come before scale and expo (I'll need to fix that, you are initializing actiosn all wrong)
[04:00] <smspillaz> bbl 1h
[05:40] <DBO> smspillaz, you here?
[06:01] <smspillaz> DBO: pong
[06:01] <DBO> i figured out the problem
[06:01] <DBO> you are right
[06:01] <smspillaz> DBO: yeah sorry, I would have been here except that my internet went down
[06:01] <DBO> it has to do with transformed painting
[06:01] <smspillaz> DBO: yeah thought so
[06:01] <DBO> we must respect the clip mask
[06:01] <DBO> so we get multiple render passes now (annoying but okay)
[06:02] <DBO> which will... be interesting to try to make work
[06:03] <smspillaz> DBO: didn't just putting a if (doShellRepaint) paintDisplay (region); in glPaintTransformedOutput () work?
[06:03] <DBO> yes and no
[06:03] <DBO> it gets rid of the flicker
[06:03] <smspillaz> glPaintTransformedOutput can sometimes get called instead of glPaintOutput
[06:03] <DBO> however it comes at the cost of multiple rendering on top of each other
[06:03] <DBO> no
[06:03] <DBO> glPaintOutput gets called
[06:04] <smspillaz> ah right, yes you are right
[06:04] <smspillaz> my bad
[06:04] <DBO> then glPaintTransformedOutput gets called inside
[06:04] <smspillaz> I'm pretty sure there was a corner case where only one of the two would get called
[06:04] <smspillaz> DBO: in any case, I don't see the issue- try loading unityshell last
[06:04] <smspillaz> well third last
[06:04] <smspillaz> scale and expo last
[06:05] <DBO> why?
[06:05] <smspillaz> it puts it at the back of the paint queue
[06:05] <DBO> really...
[06:05] <smspillaz> yes
[06:05] <smspillaz> that's how WRAP/UNWRAP works
[06:05] <smspillaz> well, the compiz++ equavilent anyways
[06:07] <DBO> smspillaz, yeah no dice
[06:07] <DBO> still screws up
[06:08] <smspillaz> even with unityshell very last?
[06:08] <DBO> whoa
[06:08] <DBO> wait
[06:08] <DBO> you paint in transformed
[06:08] <DBO> and put unity last
[06:08] <DBO> and it works
[06:08] <DBO> fuck
[06:09] <smspillaz> wooo!
[06:09] <DBO> no wait
[06:09] <DBO> nope
[06:09] <DBO> broken
[06:09] <smspillaz> :(
[06:09] <smspillaz> you had my hopes up there DBO
[06:09] <DBO> sorry
[06:10] <smspillaz> it's weird
[06:10] <smspillaz> because it works fine her
[06:10] <smspillaz> *here
[06:10] <DBO> smspillaz, you have to open something that nux paints under
[06:10] <DBO> like a notification
[06:11] <smspillaz> if only notify send didn't segfault here
[06:11] <smspillaz> maybe an update fixed
[06:11]  * smspillaz updates
[06:12] <smspillaz> DBO: I got the settings migration working btw
[06:12] <smspillaz> DBO: what exactly is the issue when you switch with wall?
[06:12] <smspillaz> it paints twice?
[06:13] <DBO> well when I put it last
[06:13] <DBO> wall paints on top of unity
[06:13] <DBO> so you get a swipe effect
[06:13] <smspillaz> that should not happen
[06:14] <smspillaz> unityshell last = unityshell paints last
[06:15] <DBO> no
[06:15] <DBO> because the transformed paints
[06:16] <smspillaz> it should still paint last
[06:16] <smspillaz> since it's at the back of the glPaintTransformedOutput queue
[06:16] <smspillaz> unless
[06:16] <smspillaz> wait
[06:16] <smspillaz> unless some plugin is calling glPaintTransformedOutput inside of it's own glPaintOutput
[06:16] <smspillaz> and that would cause our glPaintTransformedOutput to get called
[06:17] <smspillaz> although plugins that do that are stupid
[06:17] <smspillaz> they should set PAINT_SCREEN_TRANSFORMED_OUTPUTS_MASK
[06:18] <DBO> smspillaz, thats exactly what is happening
[06:20] <smspillaz> ugh fuck me
[06:20] <smspillaz> I hate this stupid design
[06:20] <smspillaz> I'm going to send davidr a bill
[06:42] <smspillaz> DBO: what happens when you remove the paint calls in glPaintTransformedOutput ?
[06:42] <smspillaz> DBO: actually
[06:42] <DBO> it paints on top
[06:43] <smspillaz> DBO: in glPaintTransformedOutput make sure you check AFTER calling gScreen->glPaintTransformedOutput in that function
[06:43] <DBO> if we could tell when a paint transformed output was going to happen
[06:43] <smspillaz> that will paint on top
[06:44] <DBO> the problem is painting under a window (when the window test hits)
[06:44] <DBO> otherwise it works
[06:53] <kvalo> morning
[07:03] <smspillaz> DBO: yeah
[07:04] <DBO> yeah?
[07:04] <smspillaz> DBO: we should catch transformed screen and not paint under windows when that happens
[07:04] <smspillaz> that's fairly easy to do
[07:04] <DBO> it will still double paint
[07:04] <DBO> or wait...
[07:04] <smspillaz> how come
[07:04] <DBO> i dont know
[07:04] <DBO> but okay
[07:04] <DBO> it only works if we load AFTER wall
[07:05] <smspillaz> DBO: screen -> transformed -> windows
[07:05] <smspillaz> I'll look into that for you
[07:05] <smspillaz> also
[07:05] <smspillaz> go to bed
[07:05] <smspillaz> ;-)
[07:06] <DBO> hold on
[07:06] <DBO> I almost have it working
[07:06] <smspillaz> hm?
[07:06] <smspillaz> I would be working on it, except that I'm waiting for this dist upgrade to finish
[07:07] <smspillaz> argh wtf is causing this
[07:08] <smspillaz> DBO: have you noticed a weird hang when you do metacity --replace &&
[07:09] <DBO> yeah it happens
[07:09] <smspillaz> argh
[07:10] <smspillaz> since I checked with gdb
[07:10] <smspillaz> and I get this
[07:10] <smspillaz> ?? ()
[07:10] <smspillaz> ?? ()
[07:10] <smspillaz> ?? ()
[07:10] <DBO> okay I have a fix
[07:10] <smspillaz> Corrupt Stack ?
[07:10] <DBO> awesome
[07:10] <DBO> it works now
[07:10] <smspillaz> cool
[07:10] <DBO> yes thats a corrupt stack
[07:10] <smspillaz> awesome, what's your fix?
[07:11] <DBO> basically we *dont* paint in transformed
[07:11] <DBO> but if we see a transformed paint call
[07:12] <DBO> we disable the window matching paint
[07:12] <DBO> and force a paint at the end of the cycle
[07:13] <smspillaz> sure, that would work
[07:13] <DBO> yeah
[07:13] <DBO> its what you suggested
[07:13] <DBO> transform is a weird situation
[07:13] <DBO> and transient
[07:37] <lamalex> hmm I kinda think my disk is failing..
[07:37] <lamalex> my computer has been acting reallll wonky tonight
[07:37] <lamalex> fans going nuts, db access being very slow
[07:39] <lamalex> GOOD THINK IT'S ALMOST BLACK FRIDAY?
[07:42] <RAOF> And the black friday super lenovo sales? :)
[07:44] <smspillaz> (too bad I spent all my monies on muse tickets)

[07:49] <RAOF> smspillaz: Have you been to one of their live shows before?  They're pretty kickarse.
[07:49] <smspillaz> RAOF: I went in january to BDO
[07:49] <smspillaz> RAOF: mind = blown
[07:49] <smspillaz> RAOF: I was at the front
[07:49] <RAOF> And that's a pretty half-arsed Muse show :)
[07:49] <smspillaz> I knoq
[07:49] <RAOF> They can't do all their fancy lightshow stuff at the BDO :)
[07:49] <smspillaz> BUT I am going in december
[07:50] <RAOF> My brother's going up to Sydney to catch them; I presume they're also playing in Perth?
[07:50] <smspillaz> at least they have some sense to not reject perth like 99% of all other bands
[07:50] <RAOF> I don't know why bands would reject Perth - you've got an awesome music scene.
[07:50] <smspillaz> I know :(
[07:50] <smspillaz> I was going to go to BDO this year
[07:51] <smspillaz> and then crystal castles wasn't coming to perth
[07:51] <RAOF> Heh.  The Dandy Warhols came all the way down to Hobart this time :)
[07:51] <smspillaz> so I just thought "argghghghg!"
[07:51] <smspillaz> RAOF: :)
[07:51] <smspillaz> RAOF: yeah, poor hobart
[07:51] <RAOF> Well, the Cat Empire have played here at least *twice*, so it's not all bad :)
[07:51] <smspillaz> :)
[07:52] <RAOF> Now *there's* a band to see live!
[07:54] <didrocks> good morning
[07:56] <RAOF> ♪ You look good / Good morning / I'm up before the sun can breeeaaaaak ♫
[07:58] <didrocks> thanks for the musical morning RAOF :)
[07:58] <RAOF> Everyone needs Good Morning by the Dandy Warhols as their alarm music :)
[07:59] <didrocks> :)
[08:00]  * lamalex just saw them last week or so
[08:00] <didrocks> well, my alarm clock was compiz plugin main FTBFS on the buildd. Of course, it built perfectly yesterday evening here…
[08:14] <smspillaz> didrocks: I got the settings migration working ^.^
[08:14] <smspillaz> looking into this hang on --replace now
[08:14] <didrocks> smspillaz: huhu, nice!
[08:14] <didrocks> smspillaz: I didn't reproduced it with the glibmm branch now
[08:15] <didrocks> reproduce*
[08:15] <smspillaz> ah ok
[08:15] <didrocks> smspillaz: you still get it reliably?
[08:15] <smspillaz> it must be an ABI mismatch thing
[08:15] <smspillaz> didrocks: yes
[08:15] <smspillaz> didrocks: I
[08:15] <smspillaz> I'm rekompiling now
[08:15] <didrocks> smspillaz: on, in that case :)
[08:15] <didrocks> smspillaz: btw, the main plugin merger is broken
[08:15] <smspillaz> didrocks: hm?
[08:15] <didrocks> smspillaz: the git is empty
[08:15] <smspillaz> didrocks: do git submodule init git submodule update
[08:16] <didrocks> ahah :)
[08:16] <didrocks> ok, will know for next time
[08:16] <didrocks> right now, I carry those as a patch for the 3 submodules
[08:16] <didrocks> but it FTBFS on the buildd and works there: http://launchpadlibrarian.net/59575447/buildlog_ubuntu-natty-i386.compiz-fusion-plugins-main_0.9.2.1-0ubuntu3_FAILEDTOBUILD.txt.gz
[08:16] <didrocks> smspillaz: any idea? ^
[08:17] <didrocks> /build/buildd/compiz-fusion-plugins-main-0.9.2.1/wall/src/wall.cpp:591:15: error: 'class CompScreen' has no member named 'grabbed'
[08:17] <didrocks> I don't think I've a more advanced version of compiz-core itself locally
[08:18] <smspillaz> didrocks: sounds like it's picking up 0.8 headers?
[08:19] <didrocks> hum? do you think, let me check…
[08:19]  * DBO dances
[08:19] <smspillaz> didrocks: oh wait
[08:19] <smspillaz> didrocks: no your core is too old
[08:19] <didrocks> Get:84 http://ftpmaster.internal/ubuntu/ natty/main compiz-core i386 1:0.9.2.1+glibmainloop-0ubuntu3 [377 kB]
[08:19] <smspillaz> or I forgot to push something
[08:19] <didrocks> smspillaz: hum? why did it built there?
[08:20]  * didrocks puzzled
[08:20] <smspillaz> since I added ::grabbed () to CompScreen to make wall build
[08:20] <smspillaz> err
[08:20]  * DBO waves at didrocks
[08:20] <smspillaz> to make wall edges thing works
[08:20] <didrocks> hey DBO! How are you?
[08:20] <DBO> I implemented awesome, again
[08:20] <didrocks> smspillaz: ok, I should see a doctor then, I get it built locally with no issue… and I don't think I updated my local compiz-core
[08:20] <DBO> thats 2 nights in a row
[08:21] <didrocks> DBO: ahah, the next release is going to get it? :)
[08:21] <smspillaz> DBO: win
[08:21] <DBO> didrocks, when is the next release?
[08:21] <didrocks> oh crap :)
[08:21] <didrocks> smspillaz: ok
[08:21] <didrocks> smspillaz: I have the glibmm branch installed
[08:21] <didrocks> smspillaz: so, I have the new method to CompScreen…
[08:22] <didrocks> all is explained then, ok :)
[08:22] <didrocks> DBO: depends on how many beers you can promess :)
[08:22] <didrocks> DBO: more seriously, I think in 4/5 hours
[08:22] <DBO> uhm...
[08:22] <MacSlow> greetings
[08:22] <DBO> MacSlow, want to do a merge?
[08:22] <smspillaz> DBO: yeah
[08:22] <didrocks> hey MacSlow
[08:23] <DBO> MacSlow, https://code.launchpad.net/~canonical-dx-team/unity/unity.autohide-like-a-boss/+merge/41813
[08:23] <didrocks> ok, getting the gsettings things finished now that njpatel merged is branch :)
[08:23] <didrocks> his*
[08:23] <MacSlow> DBO, I've to finish something else first
[08:23] <DBO> alrighty
[08:24] <didrocks> hum, bzr pull -> nothing new in trunk
[08:24] <didrocks> I bet I saw a "merged" set manually by njpatel
[08:24] <didrocks> he lied!
[08:24] <didrocks> :)
[08:26] <didrocks> yeah, it's not in trunk (https://code.launchpad.net/~unity-team/unity/favorite-store-update/+merge/41783)
[08:27] <DBO> didrocks, can you merge that then?
[08:27] <didrocks> DBO: well, he fixed but didn't push his fix I think
[08:27] <DBO> ah
[08:27] <DBO> that liar
[08:27] <didrocks> DBO: so the old branch seems to be the one you refused
[08:27] <DBO> he lies
[08:27] <DBO> likea  rub
[08:27] <didrocks> :)
[08:27] <DBO> like a rug
[08:28] <didrocks> let me insult him on the merge :)
[08:28] <didrocks> (badly of course)
[08:29] <didrocks> smspillaz: btw, it seems you didn't store your canonical email adress to your launchpad account (there is no match on your name: https://code.launchpad.net/~unity-team/unity/trunk)
[08:30] <smspillaz> didrocks: weird
[08:30] <didrocks> smspillaz: just add your canonical email address to your launchpad page: https://launchpad.net/~smspillaz
[08:30] <didrocks> that will fix it :)
[08:34] <DBO> im so tired
[08:35] <didrocks> DBO: go to bed, easy fix :)
[08:35] <DBO> didrocks, can you test my branch
[08:35] <DBO> please
[08:35] <DBO> didrocks, just confirm it works: https://code.launchpad.net/~canonical-dx-team/unity/unity.autohide-like-a-boss/+merge/41813
[08:37] <didrocks> DBO: sure, no requirements on nux/bamf?
[08:37] <DBO> didrocks, no
[08:37] <didrocks> (still have last week version)
[08:37] <didrocks> nice
[08:37] <DBO> just make sure to fresh cmake
[08:37] <didrocks> sure
[08:38] <didrocks> smspillaz: just to confirm, local extension (in ~/.compiz-1) are preferred on system ones, right?
[08:40] <smspillaz> didrocks: yep
[08:40] <didrocks> smspillaz: thanks :)
[08:42] <DBO> i swear to god I am losing my sanity much faster than predicted
[08:42] <didrocks> DBO: well, we noticed that for you long ago… :)
[08:42]  * didrocks runs
[08:43] <didrocks> your  branch look very nice!
[08:43] <DBO> thank you
[08:43] <DBO> did you try minimizing?
[08:43] <didrocks> I like it :)
[08:43] <didrocks> oh no
[08:43] <didrocks> excellent!
[08:43] <DBO> its designed to work with the zoom animation
[08:43] <DBO> also make a window go urgent
[08:43] <DBO> that has a fun effect as well
[08:44] <didrocks> oh nice as well!
[08:44] <smspillaz> didrocks: I fixed the hang btw, pushing
[08:44] <didrocks> also, there is this "law-fitt" branch merged in it
[08:44] <didrocks> smspillaz: waow, already?
[08:44] <didrocks> \o/
[08:44] <smspillaz> yeah turns out we were freeing shit while it was being executed
[08:45] <DBO> didrocks, no that was a trunk merge
[08:45] <didrocks> DBO: it's nice in any case :)
[08:45] <DBO> :)
[08:45] <didrocks> DBO: just a note: I was seetings it hilighted the launcher background for unstarted app
[08:45] <didrocks> DBO: it doesn't make it anymore
[08:45] <DBO> what?
[08:45] <didrocks> yeah, I get some kind of "light on and off"
[08:46] <didrocks> probably just a bug, I'll file one when I can reproduce it reliably
[08:46] <DBO> oh what you are seeing is startup notification
[08:46] <DBO> so there is a "starting" animation
[08:46] <DBO> it slowly fades in and out
[08:46] <didrocks> DBO: ok, maybe it was the startup notification then
[08:47] <DBO> close evolution then start it again (takes about 2 seconds)
[08:47] <DBO> you can see it
[08:47] <spikeb> does the minimize action point to the launcher?
[08:47] <DBO> yes
[08:47] <didrocks> DBO: the launcher is polished with those effects
[08:47] <DBO> I love this shit
[08:47] <spikeb> this is great.
[08:47] <DBO> I am going to do intelihide tomorrow
[08:48] <didrocks> DBO: it's much nicer than the spinning cursor alone :)
[08:48] <didrocks> intelihide?
[08:48] <DBO> so in autohide right now
[08:48] <didrocks> because you removed the timeout?
[08:48] <DBO> it is hidden unless you move the mouse over the BFB
[08:48] <DBO> in intellihide
[08:48] <DBO> it will unhide itself whenever there is no reason for it to hide
[08:48] <DBO> like when there are no open windows
[08:49] <DBO> or when there are no windows obstructing the launcher
[08:49] <DBO> hence
[08:49] <DBO> intellihide
[08:49] <didrocks> hum, nice idea :)
[08:49] <DBO> yeah
[08:49] <DBO> i did it for docky
[08:49] <DBO> everyone loved it
[08:50] <didrocks> nice (sorry, I used cairo-dock :))
[08:50] <didrocks> when I use some dock, which was… 30 minutes of my life?
[08:50] <DBO> didrocks, I understand, you dont want to choose between me and neil
[08:50] <didrocks> well, 35 with awn and playing/spreading the icons :)
[08:50] <DBO> anyhow
[08:50] <DBO> i really feel loopy
[08:50] <DBO> so
[08:50] <DBO> goodnight
[08:50] <DBO> morning
[08:50] <DBO> whatever
[08:50] <didrocks> DBO: you hadn't this cool and unuseful efffects with icons!
[08:51] <didrocks> :)
[08:51] <didrocks> DBO: good night dude
[08:51] <didrocks> DBO: nice work!
[08:51] <DBO> cheers :)
[08:51] <DBO> oh
[08:51] <DBO> please poke johnlea about these changes if you see him
[08:51] <didrocks> MacSlow: but I have a bad announce for you: still no tooltip with this branch
[08:51] <DBO> he'll be interested to hear about it
[08:51] <didrocks> DBO: sure, will do
[08:51] <didrocks> DBO: when did you merge trunk?
[08:52] <murrayc> didrocks: What was the glibmm problem? Can I help?
[08:52] <murrayc> smspillaz too
[08:52] <didrocks> murrayc: wasn't related to glibmm, the issue was in the glibmm branch with compiz :)
[08:52] <didrocks> ok, the 24
[08:52] <didrocks> so yesterday
[08:52] <didrocks> MacSlow: so, with yesterday trunk, still no tooltip/ql
[08:53] <murrayc> didrocks: compiz is using glibmm? compiz is C++?
[08:53] <didrocks> murrayc: since 0.9, yes, smspillaz rocked this
[08:54] <smspillaz> s/me/onestone and me/
[08:54] <murrayc> Any particular reason?
[08:54] <murrayc> And what does it use from glibmm?
[08:54] <smspillaz> because C++ is awesome
[08:54] <smspillaz> oh glibmm is a lot easier to integrate into existing classes
[08:54] <murrayc> Has the compiz maintainer changed? Or was it always C++?
[08:54] <smspillaz> because you don't have all that gboolean/bool type conversion nightmare
[08:55] <murrayc> gboolean/bool is not a type conversion nightmare.
[08:55] <murrayc> (I am the glibmm maintainer)
[08:55] <smspillaz> murrayc: no, davidr stoped developing it after version 0.5, danny, dennis and (recently I) picked it up since then
[08:55] <smspillaz> murrayc: hi!
[08:55]  * hyperair still believes smspillaz debugged something wrongly and got the wrong impression. about gboolean and bool.
[08:55] <murrayc> Ah that makes sense then.
[08:56] <murrayc> Is that branch not here? http://cgit.compiz.org/
[08:56] <smspillaz> murrayc: we were hitting stack overflow issues when doing foo boost::fucntion <somefunc>.callback (); return foo
[08:56] <smspillaz> murrayc: let me grab it for you
[08:56] <hyperair> smspillaz: i still haven't seen that interesting use case where gboolean -> bool goes from false to true.
[08:56] <murrayc> smspillaz: Sounds rather strange.
[08:56] <smspillaz> hyperair: murrayc: it was a weird race  condition / stack overflow thing that only happened very rarely
[08:56] <murrayc> smspillaz: So you are using boost::signals instead of libsigc++?
[08:56] <smspillaz> murrayc: yes
[08:57] <smspillaz> murrayc: boost::function rather
[08:57]  * hyperair wonders why
[08:57] <murrayc> smspillaz: Doesn't sound like something that bool would help with much.
[08:57] <smspillaz> because boost is made of win?
[08:57] <murrayc> Boost has an unstable API/ABI.
[08:57] <hyperair> smspillaz: but boost's signals are slower than libsigc++'s
[08:57] <murrayc> hyperair: That's not necessarily true.
[08:57] <murrayc> And not very relevant.
[08:57] <smspillaz> murrayc: oh, this was a problem when moving from the C based glib (sizeof gboolean != sizeof bool)
[08:57] <hyperair> murrayc: it was benchmarked to be true.
[08:58] <smspillaz> hyperair: we don't use boost::signals
[08:58] <hyperair> smspillaz: but that really shouldn't matter. i don't see how false => nonzero int
[08:58] <smspillaz> hyperair: we used boost::function
[08:58] <murrayc> gtkmm/glibmm would use boost signals if the API/ABI was stable.
[08:58] <hyperair> hm that's interesting
[08:58] <smspillaz> murrayc: actually as soon as C++0x hits (hurry up!) you won't need boost
[08:58] <smspillaz> since C++0x is practically just libstdc++ + boost
[08:59] <murrayc> smspillaz: No, signals will _not_ be in C++0x.
[08:59] <smspillaz> well, signals wont be there
[08:59] <smspillaz> but function objects will be
[08:59] <murrayc> Is Unity still going to use compiz?
[08:59] <smspillaz> yes
[09:00] <smspillaz> problems?
[09:00] <murrayc> I'm just surprised at the rather arbitrary changes in an important project. Nevermind.
[09:00] <smspillaz> murrayc: ah ok. it was for a number of reasons
[09:01] <murrayc> And I think you'll have a world of pain with boost.
[09:01] <smspillaz> boost is quite nice
[09:01] <smspillaz> we don't use it in unity
[09:01] <smspillaz> but we do use it in compiz
[09:01] <murrayc> API and ABI.
[09:01] <smspillaz> (only the very basic bits though)
[09:01] <smspillaz> like the bits they haven't changed for years (eg boost::function)_
[09:01] <murrayc> Or can you just copy in the files for boost::function? Maybe it has no library.
[09:02] <hyperair> murrayc: how unstable is their A[PB]I anyway?
[09:02] <smspillaz> it's just templates
[09:02] <hyperair> murrayc: and at least the header-only libraries are pretty safe to use imo
[09:02] <murrayc> hyperair: Oficially: completely.
[09:02] <murrayc> hyperair: OK. Then if I was you I would copy the files into compiz to avoid the where-is-boost-now configure check dance.
[09:03] <smspillaz> murrayc: boost.cmake
[09:03] <hyperair> murrayc: i don't develop compiz. smspillaz does.
[09:03] <smspillaz> figues all that out for you
[09:03] <smspillaz> hi!
[09:03] <murrayc> s/configure/CMake/
[09:03] <hyperair> murrayc: i'm just a random *mm user
[09:03] <murrayc> What could possibly go wrong then.
[09:03] <smspillaz> hehe
[09:03] <murrayc> CMake is another recent change, right?
[09:03]  * hyperair still doesn't understand the benefits of cmake.
[09:03] <smspillaz> murrayc: when we rewrote compiz we rewrote several things
[09:04] <smspillaz> murrayc: buildsystem, rendering system, etc
[09:04] <smspillaz> murrayc: reparenting
[09:04] <hyperair> i reckon that i could write an autofoo build sys for compiz++ in less than the amount of lines used in cmake
[09:04] <smspillaz> hyperair: cmake is good because because you can have much smarter build functions
[09:04] <smspillaz> and it's also a lot faster
[09:04] <hyperair> smspillaz: how much smarter?
[09:04] <murrayc> Rather hand-wavy
[09:05] <hyperair> i get that configure is slow, but make is pretty damn fast.
[09:05] <murrayc> Anyway, I started off tying to be helpful and now I'm just being annoying. Sorry.
[09:05] <hyperair> if you don't do recursive automake.
[09:05] <smspillaz> murrayc: hehe, no worry :)
[09:05] <smspillaz> murrayc: BTW did you want to see how we are using glibmm in case I accidentally abused it?
[09:06] <murrayc> smspillaz: Sure.
[09:06] <murrayc> But if you don't take my advice about boost seriously you might not want to bother with my glibmm advice.
[09:06] <smspillaz> murrayc: http://git.compiz.org/~dbo/compiz-with-glib-mainloop/tree/src/screen.cpp?h=glibmm-experimental#n113
[09:06] <smspillaz> murrayc: oh, I'm considering it
[09:06] <smspillaz> murrayc: in fact I'm actually thinking of making the serialization stuff optional at build time
[09:07] <murrayc> At the least, using sigc::slot instead of boost::function would mean you have one less dependency and possibly a slightly smaller overall code size, but you already chose C++ so code size probably is not so important to you.
[09:07] <murrayc> (Because glibmm depends on libsigc++.)
[09:08] <smspillaz> murrayc: the code size is actually smaller with C++ when you look at the bigger picture
[09:08] <smspillaz> murrayc: yeah
[09:08] <smspillaz> murrayc: I could probably look into it
[09:08] <murrayc> smspillaz: How?
[09:08] <smspillaz> murrayc: all the plugins are about 400 lines smaller
[09:08] <murrayc> smspillaz: I suspect your code size is _still_ more, for reasons that I can rarely explain.
[09:08] <smspillaz> murrayc: core is bigger though
[09:09] <murrayc> Well, yes.
[09:09] <smspillaz> but that is because there are a whole bunch of templates in it now
[09:09] <smspillaz> murrayc: maybe I will look into using sigc though now that you say it
[09:10] <murrayc> Sorry, I don't use the IOSource stuff so I can't judge it. I see many people on the mailing list using it though.
[09:10] <smspillaz> murrayc: ah ok
[09:10] <smspillaz> murrayc: no problem :)
[09:11] <smspillaz> murrayc: yeah, if we can remove sigc then I can probably make the serialization bits optional
[09:11] <smspillaz> errr remove boost
[09:11] <smspillaz> boost::function, rather
[09:11] <smspillaz> and then we can remove the hard dep on boost
[09:13] <njpatel> morning
[09:14] <murrayc> Anyway, I guess it's nice for Openismus that you are using C++ and glibmm. We've worked on ayatana before.
[09:15] <smspillaz> murrayc: :)
[09:15] <smspillaz> murrayc: yeah I used glibmm instead of glib because glibmm is a little easier to integrate into the compiz code
[09:15] <smspillaz> the more I think of it, the more I think sigc will be a good idea
[09:15] <murrayc> Well, yes, if compiz is C++.
[09:16] <smspillaz> the only problem is that we already use boost ... a lot
[09:16] <smspillaz> so all that code needs to be updated
[09:17] <murrayc> Do you use giomm?
[09:17] <smspillaz> no not yet because we don't do any IO
[09:17] <murrayc> Watch out for this bug if you are using Glib::Source: https://bugzilla.gnome.org/show_bug.cgi?id=561885
[09:18] <smspillaz> plus I'm trying to keep the deps small, so if we can remove boost (a lot of work) that would be good
[09:18] <murrayc> smspillaz: You'd get some instant gain by just copying those boost header files in. That's what you _should_ do anyway considering the difficulty of chasing boost installed locations.
[09:19] <smspillaz> yeah
[09:19] <njpatel> murrayc, hi, a question about glibmm wrt Unity: We have a lot of underlying libs that a gobject-c and the main pain with them is g_signal_connect (having to declare static method and have that call a public non-static one), is there any magic in glibmm to make this less crazy?
[09:19] <smspillaz> although the boost header files are pretty big
[09:20] <murrayc> njpatel: Well, we use gmmproc to wrap GObject APIs. That has the same stuff underneath, but generated. It's fairly easy to make new *mm projects these days. Openismus is always happy to help with that stuff.
[09:21] <murrayc> njpatel: The conversions of the C parameters (or even return types) to C++ parameters are generally so non-generic that we can't just use a template or macro for it.
[09:21] <murrayc> njpatel: Are you speaking just about compiz or about Unity too?
[09:21] <smspillaz> didrocks: I'm mailing you the patches to do the settings transition now btw
[09:22] <smspillaz> murrayc: just about unity
[09:22] <njpatel> murrayc, Just Unity, I let smspillaz handle Compiz :)
[09:22] <murrayc> njpatel: So Unity is using C++ and glibmm too?!
[09:22] <murrayc> This is becoming a strange day for me.
[09:22] <smspillaz> (heh)
[09:22] <murrayc> At least it's not Qt, I guess.
[09:22] <njpatel> murrayc, It's using C++, yes. Lot glibmm yet, though
[09:22] <didrocks> smspillaz: thanks :)
[09:22] <murrayc> njpatel: No gtkmm?
[09:23] <njpatel> murrayc, no, we don't really use gtk so justing the c api when we do is fine
[09:23] <murrayc> cairomm?
[09:23] <njpatel> it's really only for settings + icon theme
[09:23] <dbarth> murrayc: what's the issue with boost installed locations; are build problems frequent?
[09:23] <smspillaz> murrayc: I was thinking of using cairomm in the future with compiz, although I haven't really seen a point in that yet
[09:24] <njpatel> murrayc, not yet, we're all coming from mostly C background so we've fallen into "just use c when we can" trap. I'm just investigating where we can adapt that to using *mm to make the code cleaner
[09:24] <smspillaz> dbarth: they should be mitigated by FindBoost.cmake
[09:24] <dbarth> ok, so locking down the version we want, cool
[09:24] <murrayc> dbarth: Yes. Every minor version is generally parallel-installed, and what version a distro version actuallly (still) supports is generally rather arbitrary. It has got better on some distros, but they locations tend to jump around, and they are quite different between distros. I use boost::python in Glom, and it's a pain.
[09:25] <njpatel> murrayc, I'm currently leaning towards glib/giomm, but I need to investigate how up-to-date bindings are as we're starting/will start to rely on newer glib features
[09:25] <murrayc> Findboost.cmake is just putting the pain in one place. Putting it in an .m4 macro is not much worse.
[09:25] <smspillaz> dbarth: it's really only painful though when using the actual libs which is why one day I will make serialization optional at some point (at build time)
[09:25] <njpatel> urgh, cmake
[09:25] <smspillaz> and then one day we might be able to use sigc instead of boost::function
[09:26] <dbarth> ok, thanks for the heads up
[09:26] <murrayc> njpatel: Yeah. There is lots of new stuff. We are working hard on DBus stuff, for instance, but it needs lots of examples/tests to see if it really works. Tell your bosses that Openismus would love to get paid to finish that.
[09:26] <dbarth> natty upgrade failures, i have to inspect that; wish me luck
[09:26] <njpatel> murrayc, Will do
[09:26] <smspillaz> murrayc: likea dbusmm ? let me know if that goes well :)
[09:27] <murrayc> smspillaz: Yeah, gio, wrapped by giomm, should make dbusmm and dbus-c++ and all the others unecessary.
[09:27] <smspillaz> nomnom
[09:28] <murrayc> It will always be awkward because runtime API/type discovery and conversion is fundamentally opposed to C++'s preference for static type checking, but at least we can do the best we can in one place.
[09:28] <smspillaz> yeah, that's what I was thinking
[09:30] <didrocks> njpatel: so, tried for DBO his branch (merged from trunk yesterday), there is still no tooltip/ql and the indicator menu don't appear each time and are slow
[09:32] <smspillaz> didrocks: sent
[09:32] <smspillaz> ok, lets work on this profile import thing
[09:34] <njpatel> didrocks, sorry, which branch is this?
[09:34] <didrocks> njpatel: you didn't merge https://code.launchpad.net/~unity-team/unity/favorite-store-update/+merge/41783
[09:35] <didrocks> njpatel: dbo's branch is https://code.launchpad.net/~canonical-dx-team/unity/unity.autohide-like-a-boss/+merge/41813
[09:36] <njpatel> didrocks, the push failed
[09:36]  * njpatel kicks bzr
[09:37] <njpatel> didrocks, so what's the issue with DBOs branch?
[09:37] <njpatel> didrocks, I'll merge my branch in a bit
[09:37] <didrocks> njpatel: the issue isn't DBOs branch, it's just that he merged from yesterday from trunk
[09:37] <didrocks> so, I tried the "fixed" things
[09:37] <didrocks> like the tooltip
[09:38] <didrocks> still empty tooltip there
[09:38] <didrocks> (MacSlow told me it's fixed for some days in trunk)
[09:38] <didrocks> and the indicator menu doesn't react well
[09:38] <njpatel> yes, it doesn't happen here any more
[09:38] <njpatel> didrocks, react to what?
[09:39] <didrocks> njpatel: to click. Most of the time, I got my clicks eaten
[09:39] <MacSlow> didrocks, you still get that
[09:39] <didrocks> so, as I tested that version, I prefered to warn you in advance than after the release :)
[09:39] <didrocks> MacSlow: yeah :/
[09:39] <njpatel> didrocks, "clicks eaten", the menu doesn't show up?
[09:39] <MacSlow> didrocks, I honestly don't know what could be the cause for this now... it's really fixed here
[09:40] <njpatel> didrocks, what if you click and then move down to where the menu would be?
[09:40] <MacSlow> njpatel, you also have the tooltips working, right?
[09:40] <njpatel> MacSlow, ya
[09:41] <didrocks> njpatel: nothing happens
[09:42] <njpatel> didrocks, can you be sure that you don't have anything locally installed (~/.compiz-1/plugins)
[09:43] <didrocks> njpatel: I'm more than sure and I know I use dbo's branch
[09:43] <didrocks> as I have his fix :)
[09:44] <njpatel> sweet
[09:44] <njpatel> didrocks, this is on your netbook, right?
[09:44] <njpatel> didrocks, and just to be 100% sure, tooltips aren't being cut off, there's just no text in them?
[09:45] <didrocks> njpatel: no, my laptop with a nvidia card
[09:45] <didrocks> njpatel: just no text
[09:46] <smspillaz> didrocks: hum, I don't know what I was doing, but using COMPIZ_CONFIG_PROFILE=unity with a few set keys (eg /apps/compizconfig-1/profiles/unity/general/screen0/options/active_plugins) worked fine
[09:47] <smspillaz> didrocks: my config file was in ~ though
[09:47] <smspillaz> let me try it when it is in /etc
[09:47] <smspillaz> maybe our config file is not being installed?
[09:47] <didrocks> smspillaz: that's you "few set keys", only the active_plugins?
[09:47] <smspillaz> didrocks: I just checked with active plugins and it works fine
[09:47] <didrocks> smspillaz: so, you only have this is gconf
[09:47] <smspillaz> didrocks: yes, specifying gconf, and just that one key
[09:48] <smspillaz> and it works fine
[09:48] <smspillaz> but like I said
[09:48] <smspillaz> my config file is in ~
[09:48] <smspillaz> not SYSCONFDIR
[09:48] <smspillaz> I think maybe the config file is not installing
[09:48] <smspillaz> since it would have crashed and burned if it tried to isntall in /etc without root just then
[09:48] <didrocks> smspillaz: oh, you mean, the unity.ini? :)
[09:49] <didrocks> or the config?
[09:49] <smspillaz> didrocks: yeah, we don't install it
[09:49] <smspillaz> didrocks: libcompizconfig/config/config
[09:49] <smspillaz> didrocks: ahhhhh!
[09:49] <didrocks> smspillaz: ok, but this one is picked!
[09:49] <smspillaz> AHHHH!!!!
[09:49] <smspillaz> how did we not notice that when we were looking into that yesterday
[09:49] <didrocks> smspillaz: because you remember, if I set profile=foooooo yesterday in it, it told "taking fooooooo"
[09:50] <smspillaz> didrocks: yeah, but this is because it tries to read general_foooooo from SYSCONFDIR
[09:50] <didrocks> oh
[09:50] <smspillaz> and then it fails because we don't actually have a general_foooooo in sysconfdir ;-)
[09:50] <smspillaz> since we never actually install the config file
[09:50] <smspillaz> I'm fixing it now
[09:51] <didrocks> smspillaz: hum, are you sure?
[09:51] <didrocks> smspillaz: because we tried
[09:51] <didrocks> general_unity
[09:51] <smspillaz> dead sure
[09:51] <didrocks> profile=unity
[09:51] <didrocks> and it wasn't picking the gconf profile
[09:51] <smspillaz> didrocks: yeah, but are you sure your /etc/compizconfig/config had a general_unity section?
[09:51] <smspillaz> because I just tried it by hand editing it and it works
[09:52] <didrocks> smspillaz: well, pretty damned sure, but let's have a try :)
[09:52] <didrocks> smspillaz: at least, so that we are on the same base, I can distcheck the latest compizconfig + your patch
[09:52] <didrocks> right?
[09:52] <smspillaz> yeah
[09:53] <smspillaz> well
[09:53] <didrocks> as I'm still with the version where it's compizconfig in gconf and not compizconfig-1
[09:53] <smspillaz> I need to push this fix first which actually installs that little config-file
[09:53] <smspillaz> didrocks: the master version of cc-b-gconf uses compiz-1
[09:53] <smspillaz> and compizconfig-1
[09:53] <didrocks> smspillaz: I'm installing it by hand :)
[09:53] <smspillaz> :p
[09:53] <didrocks> smspillaz: in the debian makefile
[09:53] <didrocks> so, not the issue
[09:53] <didrocks> ok, let me make dist that
[09:54] <didrocks> so that we are speaking about the same thing :)
[09:54] <smspillaz> make
[09:54] <smspillaz> ok, I'll commit this fix now
[09:54] <smspillaz> yeah, I can confirm that this is the issue
[09:54] <didrocks> smspillaz: I had this file as told
[09:54] <smspillaz> since I just removed my local config file, edited the global one to have a general_unity
[09:54] <smspillaz> with a profile = unity
[09:54] <smspillaz> and then those keys set
[09:54] <smspillaz> and it worked
[09:54] <didrocks> well, that's what I tried yesterday
[09:54] <smspillaz> *shrug* works here :)
[09:55] <didrocks> but let's see with the rename :)
[09:56] <didrocks> smspillaz: oh wait!
[09:56] <didrocks> /apps/compizconfig-1/profiles/unity/general/screen0/options/active_plugins
[09:56] <didrocks> not /apps/compizconfig-1/profiles/unity/general/screen0/active_plugins
[09:56] <smspillaz> :)
[09:56] <didrocks> all is explained now :)
[09:56] <smspillaz> it's always the simplist thing!
[09:56] <didrocks> urhg!
[09:56] <smspillaz> (and to think I stayed up that late :P)
[09:56] <didrocks> trying without rebuilding first
[09:56] <didrocks> of course, trivial things are the hardest
[09:57] <smspillaz> didrocks: it was a simple source.reset () which caused that hang on metacity --replace ;-)
[09:57] <didrocks> smspillaz: argh :)
[09:57] <didrocks> smspillaz: this line made my life sooo hard!
[09:57] <smspillaz> lol
[10:01] <didrocks> smspillaz: wayyyy better!
[10:01] <didrocks> smspillaz: when the key is a valid gconf key
[10:01]  * didrocks hates himself now :)
[10:07] <smspillaz> didrocks: \o/
[10:09] <smspillaz> didrocks: fixed upstream
[10:09] <smspillaz> didrocks: actually, I'm thinking of making a few buildsystem changes that should make our lives easier
[10:09] <smspillaz> like doing findcompiz_install if possible
[10:09] <smspillaz> (ditto findcompizconfig_install)
[10:11] <didrocks> smspillaz: no, please, don't do that
[10:11] <smspillaz> didrocks: oh ?
[10:11] <didrocks> smspillaz: don't remember why, but it's broken if I call it…
[10:11] <didrocks> before of the compiz_prefix IIRC
[10:12] <smspillaz> didrocks: all this does is it tries to install FindCompiz.cmake if possible, otherwise the user has to make findcompiz_install
[10:12] <smspillaz> because FindCompiz.cmake always must go in ${CMAKE_ROOT}
[10:12] <didrocks> smspillaz: hum, can we have a deeper look at that after this release?
[10:13] <smspillaz> its a simple change ... I'll test it quickly now
[10:13] <didrocks> smspillaz: I would prefer to not add extra breakage as I remember find_compizconfig was broken on the buildd
[10:13] <didrocks> well, not sure you can test on a buildd :)
[10:13] <smspillaz> didrocks: with this you will be able to remove findcompizconfig_install
[10:13] <smspillaz> didrocks: it's this:
[10:13] <smspillaz> compiz_opt_install_file (${_findcompizconfig_file} ${CMAKE_ROOT}/Modulescompizconfig/${_config_file}
[10:14] <smspillaz> that basically doesn't install it if you don't have priviledges for it to do there
[10:14] <smspillaz> not sure if that will work with DESTDIR though
[10:14] <didrocks> smspillaz: no it doesn't
[10:14] <didrocks> smspillaz: so, don't add extra work there today, please
[10:14] <didrocks> or I can revert the commit :)
[10:14] <smspillaz> didrocks: well, you just need to use COMPIZ_DESTDIR
[10:15] <didrocks> smspillaz: look http://paste.ubuntu.com/536229/
[10:15] <didrocks> no, because you prepend that to DESTDIR
[10:15] <didrocks> and DESTDIR is used by the buildd
[10:15] <smspillaz> ah right I see
[10:15] <smspillaz> so you just manually copy the cmake file for now?
[10:16] <smspillaz> didrocks: maybe we should look into reading the env var for DESTDIR in cmake and then applying it to our compiz_opt_install_file usage
[10:16] <didrocks> smspillaz: yep
[10:16] <didrocks> smspillaz: I tried that
[10:16] <didrocks> smspillaz: but seems to not be trivial in cmake
[10:16] <smspillaz> didrocks: doesn't work?
[10:16] <didrocks> and I asked agateau the cmake export
[10:16] <didrocks> expert*
[10:16] <didrocks> :)
[10:16] <didrocks> he's puzzled too
[10:17] <smspillaz> SET(A_CMAKE_VAR "$ENV{A_UNIX_VAR}") ?
[10:17] <didrocks> doesn't work as it tries to replace at configure time
[10:17] <smspillaz> DESTDIR=foo cmake .. ?
[10:17] <didrocks> and the var is set at compile time
[10:17] <smspillaz> or is that not possible
[10:17] <smspillaz> ?
[10:17] <didrocks> didn't worked, don't remember why
[10:17] <smspillaz> arg
[10:17] <didrocks> but I can tell I spent one hour on it :)
[10:18] <didrocks> so, maybe not the day
[10:18] <didrocks> I have some tests to do on unity
[10:18] <didrocks> finish my settings migration
[10:18] <didrocks> and quick njpatel as well ;)
[10:18] <smspillaz> ok, we will look into it another day
[10:18] <smspillaz> yeah
[10:18] <didrocks> smspillaz: definitively :)
[10:18] <smspillaz> didrocks: do you want me to make the profiles, and export the keys?
[10:18] <smspillaz> and then make the packages?
[10:18] <didrocks> smspillaz: you want that upstream?
[10:19] <didrocks> smspillaz: well, all is ready for that
[10:19] <smspillaz> didrocks: oh, just downstream
[10:19] <didrocks> smspillaz: ok, no all is done
[10:19] <didrocks> smspillaz: I just need to take your compizconfig-1 rename
[10:19] <smspillaz> even setting the default keys?
[10:19] <didrocks> + the patch for the transition
[10:19] <smspillaz> and also the bit that installs the config file systemwide
[10:19] <didrocks> smspillaz: if you can make dist the upstream branch, it will help me in winning some time though :)
[10:19] <smspillaz> sure
[10:19] <didrocks> yep
[10:20] <didrocks> smspillaz: do you make dist + the transition patch?
[10:20] <smspillaz> didrocks: I'll just make dist the tip of everything
[10:20] <didrocks> or do you want to keep as a downstream patch?
[10:20] <smspillaz> oh the transition stuff can be downstream
[10:20] <smspillaz> it's a bit hacky
[10:20] <didrocks> ok
[10:20] <didrocks> smspillaz: so, only the gconf branch + libcompizconfigcompiz
[10:20] <didrocks> the rest is done :)
[10:21] <smspillaz> ok, I'll make some test packages
[11:21] <MacSlow> hey andreasn!
[11:21] <MacSlow> smspillaz, gee... you're still/already up?
[11:30] <andreasn> MacSlow, hello!
[11:30] <andreasn> all good?
[11:31] <MacSlow> andreasn, good and budy
[11:31] <MacSlow> busy
[11:31] <andreasn> what are you hacking on?
[11:32] <MacSlow> andreasn, unity
[11:33] <andreasn> any specific part of it?
[11:34] <andreasn> how are things going with jumplists?
[11:37] <MacSlow> andreasn, jumplists... I guess you mean the quicklists (the context-menu like things on the lauchner-icons)
[11:37] <MacSlow> andreasn, actually I working on those atm
[11:38] <andreasn> maybe it was sandy that called them jumplists so I got confused
[11:38] <andreasn> how do I add stuff for Thunderbird, like Inboxes and so? the .desktop-file?
[11:40] <andreasn> 2. Is my life as an app developer amazing in the way that I need to do it two ways? One way for Unity and one for Shell?
[11:40] <andreasn> is/going to be
[11:43] <andreasn> :)
[11:46] <smspillaz> MacSlow: it's only 8pm
[11:46] <smspillaz> MacSlow: also I have a persistent irssi session running on ucc.asn.au
[11:48] <MacSlow> kamstrup, hey
[11:48] <kamstrup> MacSlow: ahoy!
[11:48] <MacSlow> kamstrup, hope you'll get better fast
[11:55] <kamstrup> MacSlow: so do I. This sucks :-S
[11:55] <kamstrup> seiflotfy_: meeting in 5 minutes
[11:57] <smspillaz> njpatel: ping
[11:57] <njpatel> smspillaz, pong
[11:58] <smspillaz> njpatel: I'm going to clean out the compiz unity plugin - do you think I'll be able to make the merge window?
[11:58] <smspillaz> there's a bunch of stuff that it does which is wrong compiz wise
[11:58] <smspillaz> (just unity.cpp and unity.h_
[11:59] <smspillaz> njpatel: basically all I'll do is just nuke a bunch of code which we don't use
[11:59] <smspillaz> (we have a bunch of functions wrapped which is useless for what we need)(
[11:59] <njpatel> smspillaz, yes, that sounds good, go for it
[12:00] <smspillaz> njpatel: ok
[12:00] <smspillaz> njpatel: also I'll add the load after bits so that we actually load last
[12:00] <kamstrup> seiflotfy_: ping
[12:01] <njpatel> smspillaz, will that mean we don't need to delay chatting to bamf on startup?
[12:01] <njpatel> smspillaz, because it freaks out right now
[12:05] <smspillaz> njpatel: we have to delay chatting to bamf because of the reparenting madness
[12:05] <smspillaz> njpatel: the re-parenting system needs to be rewritten
[12:05] <smspillaz> njpatel: I know how to do it, just no time right now
[12:06] <njpatel> smspillaz, okay, thanks
[12:08] <smspillaz> njpatel: yeah, we're re-parenting far too early
[12:08] <smspillaz> late rather
[12:15] <smspillaz> RAOF: ping
[12:15] <smspillaz> RAOF: seems that the latest intel drivers are broken in natty
[12:15] <smspillaz> RAOF: doesn't seem to change the mode, and then UMS kicks in and makes a mess
[12:15] <smspillaz> (blank screen(
[12:20] <seiflotfy_> hi n
[12:20] <seiflotfy_> kamstrup,
[12:20] <kamstrup> seiflotfy_: you're here! Fashionably late!
[12:20] <seiflotfy_> kamstrup, i was sleeping
[12:21] <seiflotfy_> im on skype andhow
[12:24] <johnlea> http://use-case-mapper.canonical.com/specifications/0AU5sFuLRpCpBZGZra2pqY2pfNDIxZjdkZnM5ZGo
[12:24] <seiflotfy_> johnlea, kamstrup https://docs.google.com/Doc?docid=0AU5sFuLRpCpBZGZra2pqY2pfNjI3Zms3NmZuZzY&hl=en_GB
[12:25] <kamstrup> http://use-case-mapper.canonical.com/specifications/0AU 5sFuLRpCpBZGZra2pqY2pfNjI3Zms3NmZuZzY
[12:25] <seiflotfy_> kamstrup,
[12:25] <seiflotfy_> http://use-case-mapper.canonical.com/specifications/0AU 5sFuLRpCpBZGZra2pqY2pfNjI3Zms3NmZuZzY
[12:36] <seiflotfy_> johnlea, http://seilo.geekyogre.com/2010/11/unity-place-people-day-3/
[12:43] <johnlea> http://use-case-mapper.canonical.com/specifications/0AU5sFuLRpCpBZGZra2pqY2pfNDIxZjdkZnM5ZGo/use_cases/4_4
[12:58] <kamstrup> seiflotfy_, johnlea: he technical tasks can be aggregated here https://docs.google.com/document/d/1yseTwHK6mwHhXtVpU_cTEEmORfyJfOn5PpcGZH7HuDA/edit?hl=en
[13:06] <johnlea> http://use-case-mapper.canonical.com/specifications/0AU5sFuLRpCpBZGZra2pqY2pfNjI3Zms3NmZuZzY/use_cases/2_1
[13:38] <lamalex> happy thanksgiving :)
[14:21] <dbarth> lamalex: hi Alex
[14:21] <dbarth> yeah happy thanksgiving
[14:21] <lamalex> thanks dbarth
[14:29] <dbarth> what's up on the testing front?
[14:30] <dbarth> lamalex: jibel was asking earlier about the landing of the branch to avoid the rebuild
[14:31] <lamalex> dbarth, the branch is landed
[14:31] <dbarth> lamalex: ah, super, i was not seeing it in the branch proposals
[14:31] <dbarth> cool
[14:31] <dbarth> so one down
[14:31] <lamalex> merged it last night
[14:31] <lamalex> should I mark it as DONE in the blueprint now?
[14:31] <dbarth> go ahead
[14:32] <dbarth> also, i've had an call this morning with the guys from the cert team to have access to the HW lab
[14:33] <dbarth> lamalex: i hinted at a first cut of an automated unity (whatever we call that in the end) that they could start running on their systems, in ~2 weeks
[14:33] <dbarth> lamalex: we'll see that in more details at their sprint, but this is a heads up to start thinking about putting pieces together
[14:34] <lamalex> yah
[14:34] <lamalex> when is A1?
[14:34] <dbarth> a2
[14:34] <dbarth> ie doesn't have to actually do all, but just return 0 or 1 and a log file
[14:34] <dbarth> so that the whole "vertical slice" can be tested, between the different participants and systems this has to run on
[14:34] <dbarth> i know these things take time
[14:35] <dbarth> when is a1 sorry you were asking
[14:35] <dbarth> a1 is next thursday officially
[14:35] <dbarth> but we're wrapping it today for the big landing
[14:35] <lamalex> cool
[14:36] <dbarth> and there'll be maybe a couple of bug fixes between now and tuesday
[14:36] <lamalex> right
[14:37] <lamalex> dbarth, starting next week I'll start looking into the autopiloting
[14:38] <dbarth> yeah, the point is to try to have something to connect the dots before the holiday break in december
[14:38] <dbarth> cool
[14:39] <dbarth> and then on atk and perf counters: do you manage to get both moving?
[14:42] <lamalex> atk I understand and will only take a day to implement- so that's my Friday
[14:43] <lamalex> and I got my compiz repo and so on set up for perf counters, so I'm ready to get moving on them next week
[14:43] <lamalex> but it's a Holiday ;) so we can talk tomorrow
[14:44] <dbarth> oh right, sorry ;)
[14:45] <dbarth> yeah, we have time tomrrow for that; enjoy thanksgiving
[15:30] <smspillaz> didrocks what's our plugin list again?
[15:30] <smspillaz> (just spew out the gconftool-2 output if you want
[15:31] <smspillaz> I'm going to force load unityshell after everything
[15:31] <didrocks> [core,bailer,detection,composite,opengl,mousepoll,move,resize,decor,compiztoolbox,place,gnomecompat,vpswitch,fade,staticswitcher,scale,expo,ezoom,wall,unityshell]
[15:31] <didrocks> argh, not the new one
[15:32] <didrocks> that + session
[15:32] <smspillaz> sure
[15:32] <smspillaz> done
[15:33] <didrocks> smspillaz: for the transition?
[15:33] <smspillaz> didrocks: no, for unityshell loading after everything
[15:33] <didrocks> ok
[15:33] <didrocks> wall is the latest
[15:33] <smspillaz> yeah, but this can change
[15:41] <dbarth_> didrocks: how's the baby presenting itself for the alpha-1 release?
[15:46] <didrocks> dbarth_: not yet ready
[17:51] <njpatel> cyphermox,  mind if i move https://bugs.launchpad.net/unity/+bug/680298 to you?
[18:34] <cyphermox> njpatel, np
[18:34] <cyphermox> njpatel, by the way, I'm just about ready to upload nm-applet with my patch today
[18:34] <njpatel> oh, awesome!
[18:34] <njpatel> cyphermox, what's your LP id?
[18:35] <njpatel> the obvious choice didn't work ;)
[18:37] <cyphermox> mathieu-tl
[18:37] <cyphermox> i know... but it's too much of a hassle to rename :)
[18:37] <njpatel> heh
[18:37] <njpatel> bribe a LP admin ;)
[18:39] <njpatel> okay, done it, thank you :
[18:39] <njpatel> will test out the nm-indicator tomorrow...can't wait :)
[21:38] <RAOF> smspillaz: Rah rawh!  Come to #ubuntu-x and we'll diagnose, but we haven't recently changed intel drivers (just the 3D component).
[22:10] <DBO> RAOF, can you speak to me about support of GLSL shaders on all common drivers in Natty
[22:11] <RAOF> Natty has the GLSL2 compiler rework that landed towards the end of Maverick.
[22:11] <RAOF> That should be much better at not rejecting valid GLSL, among other things.
[22:12] <DBO> so that means GLSL works for?
[22:12] <RAOF> It *should* work for everything.
[22:12] <DBO> radeon, fglrx, intel, nvidia (proprietary)
[22:12] <RAOF> Yes.
[22:13] <DBO> how well is the GLSL2 compiler rework tested?
[22:13] <RAOF> There are quite a lot of unit tests in piglit testing it.
[22:14] <RAOF> All the mesa drivers as of 7.9 are using it, and there were a spate of bug reports when it got turned on but most of those seem resolved.
[22:15] <RAOF> I'd be most concerned about Intel hardware, as that's the stuff which is least likely to actually implement required functionality in hardware.
[22:16] <RAOF> Radeon is switching to the gallium drivers, which are good at shaders.
[22:16] <RAOF> Oh, and also has real honest-to-goodness hardware :)
[22:16] <RAOF> Nouveau we don't support.
[22:17] <RAOF> And the binary drivers traditionally have a much more featureful GL stack than mesa.
[22:18] <RAOF> Does that about cover it?
[22:23] <DBO> RAOF, that basically said to me "use GLSL"
[22:23] <DBO> is that a fair takeaway?
[22:24] <RAOF> Yeah.
[22:24] <RAOF> If it's useful to you, use it.  The stack should be able to support you.
[22:24] <DBO> perfect...
[22:24] <DBO> we were afraid a dell mini 9 might puke
[22:25] <RAOF> Well, Intel are the ones driving most of the GLSL work at the moment.
[22:25] <RAOF> The dell mini 9 *might* puke from lack of physical hardware; that would be my concern there, rather than the drivers as much.
[22:26] <RAOF> If you try something too fancy.
[23:14] <spikeb> on natty. is there more than one ppa for unity?
[23:17] <spikeb> found the daily ppa.