[07:53] <didrocks> good morning
[07:57] <MacSlow> greetings everybody!
[08:12] <smspillaz> oubiwann: do you know if utouch works with the wacom bamboo touch?
[08:12] <didrocks> smspillaz: do you reproduce compiz not exiting when trying to replace it with another wm error too?
[08:12] <smspillaz> didrocks: no, it works fine
[08:13] <didrocks> smspillaz: you use the glib mainloop branch too?
[08:13] <smspillaz> didrocks: if it wasn't exiting, I would say it would be something to do with us not catching --replace maybe? (I tried it on the glib and glibmm branch and it worked fine though)
[08:13] <didrocks> hum
[08:13] <smspillaz> didrocks: do you get 100% CPU usage from compiz?
[08:13] <didrocks> not 100%, but a high CPU usage from compiz, right
[08:14] <didrocks> I think MacSlow told he got that too
[08:14] <didrocks> seb got it for sure
[08:15] <MacSlow> didrocks, smspillaz: I don't get 100% cpu-load from coompiz
[08:15] <didrocks> MacSlow: not that, but when you try to change to another wm, like metacity --replace, compiz hanging
[08:16] <MacSlow> didrocks, oh... that... yeah... that can happen sometimes... but recently (last week) it happened less (maybe only once iirc)
[08:17] <didrocks> quite reproductible here
[08:17] <didrocks> smspillaz: any thought how to debug this? ^^
[08:17] <smspillaz> MacSlow: didrocks: probably an infinite loop. Can you attach with gdb and get a backtrace?
[08:17] <didrocks> smspillaz: you mean, stopping the process in gdb?
[08:17] <smspillaz> you'd get something in the high 90s
[08:17] <smspillaz> didrocks: yeah, trigger the hang, go to a vt
[08:18] <smspillaz> pidof compiz suddo gdb attach ${pid}
[08:18] <didrocks> sure
[08:18] <smspillaz> c
[08:18] <smspillaz> bt
[08:18] <MacSlow> smspillaz, if it happens again ok
[08:18] <smspillaz> I think you can set a log file too
[08:18] <smspillaz> sure
[08:18] <didrocks> without debug symbols for now
[08:18] <smspillaz> oh ok. debug symbols would be nice ^.^
[08:18] <MacSlow> smspillaz, but like I said I get it a lot less frequently since about a week
[08:18] <didrocks> smspillaz: sure for now, will get one to you later :)
[08:18] <smspillaz> ok
[08:19] <smspillaz> also while you two are here
[08:19] <MacSlow> smspillaz, so don't hold you breath
[08:19] <smspillaz> I'm having this build error with unity
[08:19] <smspillaz> MacSlow: oh dw, I have tons of other bugs to fix :p
[08:19] <didrocks> MacSlow: as I said, I get that everytime
[08:19] <smspillaz> (let me pastebin this error)
[08:19] <didrocks> and it prevents gnome to logout properly :)
[08:19] <MacSlow> didrocks, hm
[08:19] <MacSlow> smspillaz, I can imagine :)
[08:19] <smspillaz> yeah. there are about a million code paths in compiz, very bug-prone
[08:20] <smspillaz> didrocks: also, french--; because they invented AZERTY keyboards
[08:20] <smspillaz> those things are hard to use
[08:20] <smspillaz> (this is on dbarth's netbook
[08:22] <smspillaz> didrocks: kamstrup: paste.ubuntu.com/535108 <- look familiar?
[08:23] <kamstrup> smspillaz: ugh, yeah it does
[08:23] <didrocks> smspillaz: azerty keyboard is awesome :)
[08:23] <smspillaz> didrocks: lol
[08:23] <kamstrup> smspillaz: pull unity - i think didrocks committed a fix
[08:23] <didrocks> smspillaz: yeah, do you use the trunk?
[08:23] <smspillaz> didrocks: lp:unity ? yes
[08:23] <didrocks> smspillaz: what's the revision you have?
[08:24] <kamstrup> smspillaz: you on natty?
[08:24] <didrocks> 614 fix it
[08:24] <didrocks> well "fix"…
[08:24] <didrocks> :)
[08:24] <smspillaz> 614
[08:24] <smspillaz> kamstrup: yes, I'm on natty
[08:24] <didrocks> smspillaz: did you reconfigure?
[08:24] <smspillaz> (I'm on rev 614 btw)
[08:25] <smspillaz> didrocks: pretty sure I did, but I can try a force clean, sec
[08:26] <sladen> morning people
[08:27] <didrocks> hey sladen
[08:27] <smspillaz> (if this actually compiles then I will finally see if my glibmm stuff really does work)
[08:29] <smspillaz> didrocks: still doesn't compile, I'm on  614, there's no new revisions
[08:29] <smspillaz> meh, if I were to fix it manually, what should I stick in those files?
[08:29] <didrocks> smspillaz: it shouldn't even try to compile those files
[08:30] <didrocks> smspillaz: and it's working in natty (not compiling those file), not sure what you get locally
[08:30] <didrocks> smspillaz: mehhh, compiz doesn't hang under gdb, tried 3 times…
[08:30] <smspillaz> didrocks: maybe I need to change the buildsystem
[08:30] <smspillaz> didrocks: hah!
[08:30] <kamstrup> smspillaz: can you give me your valac --version? Because it works fine here with valac from Maverick as well as with valac from Vala git master
[08:30] <didrocks> smspillaz: autotools? (kidding) :)
[08:31] <smspillaz> kamstrup: 0.11.2
[08:31] <smspillaz> didrocks: oh, as in, there is probably some lingering file in there
[08:31] <kamstrup> smspillaz: hmmm and I have Vala 0.11.2.20-376e2 here...
[08:31] <didrocks> smspillaz: probably, like a remaining .c or whatever
[08:32] <kamstrup> smspillaz: let me try and checkout the released 0.11.2 version in git and see if it can reproduce
[08:33] <didrocks> smspillaz: ok, meanwhile, did you create "projects" on git.compiz.org for the bailer and the detection plugin?
[08:34] <smspillaz> didrocks: git.compiz.org/users/smspillaz/bailer git.compiz.org/users/smspillaz/detectioon
[08:35] <didrocks> smspillaz: even if it's uses/smspillaz, we take that as trunk, ok :)
[08:35] <didrocks> smspillaz: so, that + a snapshot of compiz for A1 on Wednesday sounds good to you?
[08:36] <TheMuso> Hey folks.
[08:36] <didrocks> evening TheMuso!
[08:36] <smspillaz> didrocks: sure. I just need to talk to iXce about getting it in /compiz
[08:36] <smspillaz> didrocks: BTW wrt to that session thing ... you know about how compizconfig allows you to have different settigns "profiles" and switch between them right?
[08:37] <smspillaz> didrocks: my idea was that we ship a wrapper script called "unity" which starts dbus services, launches compiz
[08:37] <didrocks> smspillaz: not really
[08:37] <didrocks> smspillaz: I saw the "profile" in ccsm, but not sure how they work
[08:37] <smspillaz> didrocks: it will automatically detect the session id and pass --profile="unityprof" so we can set all of the "unity" settings (including loading the unity plugin)
[08:38] <smspillaz> and then for gnomeclassic, we start up --profile="gnomeclassic"
[08:38] <didrocks> smspillaz: and the user changes are stored in a different path locally?
[08:38] <smspillaz> didrocks: the user changes happen to the currently active profile
[08:38] <didrocks> (in gconf or ini backend)
[08:38] <smspillaz> didrocks: and it's backend transparent, yes
[08:38] <didrocks> ok
[08:38] <smspillaz> so I'll look into adding a --profile switch
[08:39] <didrocks> so sounds good, but a wrapper script isn't good for performance…
[08:39] <smspillaz> usually we don't use switches in compiz, but the ccp thing is a special case
[08:39] <didrocks> hum, I'm just worried about the wrapper TBH
[08:39] <smspillaz> didrocks: There's always going to be a script somewhere across the line (.xsession, etc) so even just put it in that one
[08:40] <smspillaz> and I'm pretty sure you can start things with arguments as part of a gnome-session component
[08:40] <didrocks> smspillaz: not really, because it has a be launched by gnome-session
[08:40] <didrocks> so, yeah, gnome-session component, I have to look at the code
[08:40] <smspillaz> (otherwise, how would we pass --replace to compiz and metacity?)
[08:40] <didrocks> the issue is that if we do that, we are breaking many tools (as they change the gconf keys)
[08:41] <didrocks> smspillaz: do you know about gconf layer, mandatory keys and sessions?
[08:41] <smspillaz> what tools?
[08:41] <smspillaz> didrocks: we'd only be changing stuff in /apps/compiz
[08:41] <didrocks> smspillaz: ah, there is a gconf key for the profile?
[08:42] <smspillaz> didrocks: what do you mean by this?
[08:42] <didrocks> smspillaz: can we change the profile chosen at start in /apps/compiz/<whatever> in gconf?
[08:43] <smspillaz> oh cool, someone got wayland working on an fb compositor
[08:43] <smspillaz> didrocks: no. the active profile is in .config/compiz/compizconfig/config.ini (iirc)
[08:43] <didrocks> smspillaz: do you think it's feasable to get it into gconf?
[08:44] <didrocks> smspillaz: the thing is, I think that a wrapper script will be rejected for that usage as we took so many times to kill them in lucid
[08:44] <smspillaz> didrocks: it could be done, but then we'd make a hard dependency on gconf
[08:44] <didrocks> smspillaz: also, gnome doesn't really support sessions
[08:44]  * smspillaz doesn't want to do that
[08:44] <smspillaz> didrocks: are you sure it's impossible to pass switches to compiz when it starts up?
[08:44] <didrocks> smspillaz: that's not the issue, let me take an example
[08:45] <didrocks> so, gnome-session has a list of required component
[08:45] <smspillaz> ... if you're able to set DESKTOP_SESSION=unity, then you should be able to do compiz --replace --profile=foo &
[08:45] <didrocks> one of those is the windowmanager
[08:45] <didrocks> it's a gconf key stored in /desktop/gnome
[08:45] <smspillaz> ah right
[08:45] <didrocks> until then, ok, I've introducted a hack to change the gconf system path depending on the session
[08:46] <didrocks> so we can say "default for this session is compiz --replace foo" and "default for the other session compiz --replace bar"
[08:46] <didrocks> the thing is
[08:46] <didrocks> if the use change the windowmanager by default (it's their right), like in g-c-c
[08:46] <didrocks> the key is changed
[08:46] <didrocks> (so stored in ~/.gconf/…)
[08:46] <didrocks> it overwrites both default, from whatever session
[08:47] <smspillaz> ah right
[08:47] <didrocks> the workaround is to set it as a mandatory key
[08:47] <didrocks> but that means, no way for the user to change their windowmanager
[08:47] <didrocks> not sure it's acceptable :)
[08:47] <didrocks> a mandatory key for the profile key in /apps/compiz would have been acceptable
[08:48] <smspillaz> hmm
[08:48] <smspillaz> is it possible for us to load a different .config per session?
[08:48] <didrocks> transparently for compiz?
[08:48] <smspillaz> I'm pretty sure .config is some XDG evn var
[08:48] <didrocks> smspillaz: right, but maybe we want different keys for compiz but not for ubuntuone, or shotwell, or whatever…
[08:49] <smspillaz> symlink them?
[08:49] <didrocks> that's horrible :)
[08:49] <smspillaz> gah
[08:50] <smspillaz> didrocks: in that case, I am willing to change it slightly so that we don't use a switch --profile but maybe just a COMPIZ_PROFILE_NAME env var
[08:50] <smspillaz> is it possible to set that easily without impacting startup perf?
[08:51] <didrocks> smspillaz: no problem to set that, we are aready doing that for the gconf hack
[08:51] <smspillaz> (in fact, COMPIZCONFIG_PROFILE_NAME is probably cleaner than --profile for a number of reasons)
[08:51] <didrocks> the scripts in /etc/X11/Xsession.d/ are sourced and I'll add to an existing one
[08:51] <didrocks> smspillaz: think just to fallback to default if it doesn't exists
[08:52] <didrocks> smspillaz: that can happens if someone is creating a foo.desktop in /usr/share/xsessions/
[08:52] <smspillaz> didrocks: yeah. The only problem I just thought of then is that if the user makes another profile they won't be able to switch to it
[08:52] <didrocks> happen*
[08:52] <didrocks> hum, you don't read .config first?
[08:53] <didrocks> argh, but that would be the same for every sessions :}
[08:53] <smspillaz> we'll read .config first but obviously we want COMPIZ_PROFILE_NAME to override it
[08:53] <didrocks> this session stuff is a headache since lucid!
[08:53] <didrocks> I really think we should handle that in XDG to tell to apps "you should do that way", will be so much easier
[08:54] <smspillaz> didrocks: well, I'm trying to get this in upstream libcompizconfig
[08:54] <didrocks> smspillaz: ok, but we should just find a way for the user to change their profile
[08:54] <didrocks> hum… not easy :)
[08:54] <smspillaz> yeah
[08:55] <didrocks> apart from an other settings "force"
[08:55] <didrocks> like "don't take care about your sessions"
[08:55] <didrocks> but again, that will impact all sessions
[08:55] <didrocks> not ideal :/
[08:55] <smspillaz> didrocks: let me think about this
[08:56] <kamstrup> didrocks: on the libunity vs valac compile failure....
[08:56] <smspillaz> didrocks: do you think there's a usecase for the user changing their profile in the unity session?
[08:57] <kamstrup> didrocks: the problem is that the gio-2.0 vapi changed API between M and N
[08:57] <kamstrup> didrocks: and it's not trivial to make libunity compile on both afaics
[08:57] <smspillaz> if not, we'll set COMPIZCONFIG_PROFILE_NAME=foo there and for gnome-classic, not set anything (eg, load the default profile)
[08:57] <didrocks> smspillaz: I think we can ignore that in the unity session as we want a well tested and known profiles, no headache. The gnomeclassic one, they can be…
[08:58] <didrocks> kamstrup: you know for what platform you are developping, right? (hint: it begins with a N :))
[08:58] <smspillaz> didrocks: ok then. so I'll add a COMPIZCONFIG_PROFILE_NAME to libcompizconfig
[08:58] <smspillaz> and then we specifiy the profile name
[08:58] <smspillaz> and load that directly
[08:58] <smspillaz> no need to "detect" session
[08:58] <didrocks> smspillaz: nice! so, the profile will be the "default" in gnome-classic?
[08:58] <smspillaz> didrocks: yes
[08:59] <kamstrup> didrocks: Nintendo?
[08:59] <smspillaz> in gnome-unity it will be "Unity"
[08:59] <didrocks> smspillaz: makes sense, making the changes in the xsessions scripts
[08:59] <didrocks> kamstrup: hehe, nice try!
[08:59] <smspillaz> and we'll tweak the settings in the Unity Session to be more appropriate
[08:59] <didrocks> kamstrup: oh, this "unity" game on wiiware? :)
[08:59] <smspillaz> there's a unity game on wiiware?
[08:59] <kamstrup> schweet!
[08:59] <didrocks> smspillaz: no, just a joke :)
[08:59] <smspillaz> damn ;-)
[08:59] <smspillaz> I wonder if I should get a kinect
[09:00] <smspillaz> just for hax0ring
[09:00] <smspillaz> hook it up to libgeis XD
[09:00] <hyperair> compiz with kinect support sounds interesting.
[09:00] <didrocks> smspillaz: ok, once done, can we have a look about the profile thing? Not sure how to define a default profile telling "ok, create a unity profile with that plugins by default" (but hack the env variable first, will get that later)
[09:00] <smspillaz> hyperair: I once wrote a wiimote plugin for compiz too!
[09:01] <smspillaz> didrocks: we'll just ship it in the user's homedir skeleton by default
[09:01] <hyperair> smspillaz: i know. i've never used it though.
[09:01] <kamstrup> didrocks: ok, everyone with slow CPUs can cry me a river then - I'm adding Vala to the jhbuild :-)
[09:01] <smspillaz> FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
[09:01] <didrocks> kamstrup: hehe :)
[09:01] <hyperair> lol
[09:02] <hyperair> why, does vala take a long time to compile?
[09:02] <smspillaz> I hope it doesn't take as long as nux
[09:02] <kamstrup> hyperair: ok, it's not like a kernel, but does take some time - more than most components we use at least
[09:02] <smspillaz> kamstrup: FUUUUbuntu is what this is XD
[09:02] <kamstrup> smspillaz: it's in the same ballpark as nux
[09:02] <didrocks> smspillaz: hum, shipping another homedir skeleton? but if we use the gconf backend rather?
[09:02] <smspillaz> kamstrup: hehe, ok
[09:03] <hyperair> smspillaz: nux?
[09:03] <smspillaz> hyperair: it's a small layer that allows us to write unity on top of compiz
[09:03] <hyperair> ah.
[09:04] <smspillaz> didrocks: we implement the profiles as ini files, yes
[09:04] <smspillaz> but you'll need the homedir skeleton anyways (to provide a .config/compiz/compizconfig to tell l-c-c to use the gconf backend
[09:04] <didrocks> smspillaz: ok, and then, load that in gconf at startup I guess?
[09:05] <smspillaz> didrocks: yeah. If it's already loaded then it won't load again
[09:05] <didrocks> smspillaz: ok, then, we will really need this "first time init script" for upgrading users
[09:06] <smspillaz> well it only happens once, like I said
[09:06] <smspillaz> so there's no need to put it in a "transition script" or anything
[09:06] <smspillaz> however, if you change sessions it will also change gconf keys around iirc
[09:07] <didrocks> smspillaz: you still need the ini file to be shipped in the home directory, isn't it?
[09:07] <smspillaz> yes
[09:07] <didrocks> smspillaz: so, what happens for users being on Natty today? they don't have it, hence the migration script to ship in ~
[09:07] <didrocks> smspillaz: apart from you look for the profile in a /usr/share/compiz if it doesn't exist
[09:09] <smspillaz> didrocks: we only install a Unity.profile
[09:09] <smspillaz> didrocks: the Default one is either created on first start, or we use the user's settings
[09:10] <didrocks> smspillaz: right, but my question is rather: "where should be this Unity.profile?" can we ship in the system directory and that get copied (as the Default one) on first launch by compiz?
[09:10] <didrocks> smspillaz: if we need to ship it in the user directory, that will be a fail as we have to handle people upgrading who doesn't have it
[09:11] <smspillaz> didrocks: it goes into .config/compiz/compizconfig
[09:11] <smspillaz> ah right
[09:11] <didrocks> :)
[09:11] <smspillaz> maybe I should make it possible to load profiles from $PREFIX/share/compizconfig
[09:11] <didrocks> smspillaz: I think compiz should first look at .config/compiz/compizconfig, and then, look in a known system dir if it doesn't find it
[09:11] <didrocks> agreed, do you want some help on that?
[09:11] <smspillaz> that's what I was thinking
[09:11] <smspillaz> oh, I know how to do it
[09:11] <smspillaz> just have to ... do it
[09:11] <didrocks> nice :)
[09:12] <didrocks> preparing the profile meanwhile
[09:12] <smspillaz> kamstrup: where is this magical jhbuild thing of yuors
[09:12] <smspillaz> *yours
[09:12] <smspillaz> didrocks: here's a dare for you. Go into ccsm and tweak out all the settings to have lots of wobbly and fire and blur and save that as Unity.profile for A1
[09:12] <smspillaz> just to make Jason explod
[09:13] <smspillaz> *explode
[09:13] <didrocks> smspillaz: of course, and should I activate this "I love Jason" plugin too :)
[09:14] <smspillaz> I'll hack together a plugin which displays text on screen
[09:15] <smspillaz> <3 U JASON 4EVA
[09:15] <kamstrup> smspillaz: let me just push it to a public place
[09:15] <smspillaz> while there's plenty of fire, wobbly, water, blur, particles, cubes etc in the background
[09:15] <smspillaz> kamstrup: thx
[09:15] <didrocks> smspillaz: can open a bug task and set to high :)
[09:45] <smspillaz> kamstrup: where is this link to your jhbuild?
[09:55] <didrocks> smspillaz: looking at compiz core, there is no central point that is called when a plugin is unloaded, isn't it? (only this unload function which is inherited from plugin.h)
[09:56] <smspillaz> didrocks: no there isn't :( I'll need to make loaderLoadPlugin and loaderUnloadPlugin wrappable functions properly
[09:57] <smspillaz> so that we can so something like (in the future) python -> dl -> built-in
[09:58] <didrocks> smspillaz: ok, nice to have in the future, not sure it's needed right now. So, it seems nothing more to add right now in the bailer/detection plugin, isn't it?
[09:58] <didrocks> (for A1)
[09:59] <didrocks> apart from now hacking gnome-session to add required components on the fly
[09:59] <smspillaz> didrocks: yeah. I think getting loaderLoadPlugin and loaderUnloadPlugin wrappable should be an easy task
[09:59] <smspillaz> it basically is now, except in a more "manual" way
[10:00] <didrocks> smspillaz: so that, when a "shell" plugin unload, we fallback to another shell, sounds the best way to deal with it (but we can deal with it manually in unity now)
[10:00] <smspillaz> didrocks: yeah, just hardcode it for now
[10:00] <smspillaz> didrocks: you should be able to push to both the bailer and detection plugins
[10:01] <didrocks> smspillaz: done already if you didn't notice :)
[10:01] <smspillaz> ah right ;-)
[10:01] <didrocks> smspillaz: I've removed the env var as well as we will deal with the profile
[10:01] <didrocks> ok, so now gnome-session hacking :)
[10:01] <smspillaz> didrocks: we don't have CIA.vc running on the userrepos so I didn't get a text message about it XD
[10:02] <didrocks> smspillaz: well, make sense to avoid spamming…
[10:02] <smspillaz> heh
[10:02] <smspillaz> you should have seen my phone bill when I pushed about 500+ committs to group about 3 weeks ago
[10:03] <didrocks> smspillaz: oh, you pay depending the bits you are pushing?
[10:03] <smspillaz> oh, just for all the text messages I receieved XD
[10:03] <smspillaz> I forgot to turn notifications off and my phone was on silent
[10:04] <smspillaz> go back the next day and I have 500 new messages
[10:04] <didrocks> ahah :)
[10:05] <didrocks> njpatel: dude, you won't have time to work on the file:///*.desktop for the launcher this week, I can handle it along with the migration script if needed?
[10:07] <njpatel> you can, though I do need to work on that code for other things this week, so i'll probably add the file:// stuff tomorrow
[10:07] <njpatel> but i won't be doing the migration stuff
[10:07] <didrocks> njpatel: oh ok, so updating the migration stuff only then :)
[10:07] <didrocks> also changing the defaults
[10:08] <smspillaz> njpatel: when did you need the decorations stuff done btw?
[10:09] <didrocks> smspillaz: hum, it's normal that you couldn't build the last version, Jason --overwrite my branch
[10:09] <didrocks> grrr :)
[10:10] <didrocks> so rev 614 isn't mine
[10:10]  * didrocks rebase and push
[10:10] <smspillaz> didrocks: ahahahahahaha
[10:10] <didrocks> smspillaz: so, rev 615 should build :)
[10:11] <smspillaz> ok :p
[10:51] <didrocks> njpatel: assigning that one to jay? Unity won't be in A1 otherwise :) https://bugs.launchpad.net/unity/+bug/678460
[10:53] <njpatel> didrocks, urgh, yes, of course
[10:54] <njpatel> didrocks, also, I don't think he can ship those files
[10:54] <didrocks> njpatel: so, using system font rather?
[10:54] <njpatel> why does natty insist that I am using firefox as my default browser?
[10:54] <didrocks> njpatel: yeah, it's quite aggressive about it :/
[10:54] <njpatel> didrocks, no, this is something else
[10:54] <njpatel> didrocks, will figure it out with jay
[10:54] <didrocks> njpatel: ok, nice :)
[10:54] <didrocks> thanks
[10:55]  * njpatel doesn't want to use firefox
[10:55] <didrocks> njpatel: the thing is, there is still the same bug for me with a very slow firefox on nvidia with launchpad…
[10:55] <njpatel> right
[10:55] <njpatel> also, their bastardisation of the current Gtk theme hurts my eyes
[10:56] <gord> didrocks, natty using firefox 4 yet? speed improvements in that have made a big difference to me
[10:56] <njpatel> at least chromium is upfront in that they aren't going to respect it
[10:56] <njpatel> gord, FF 4.0 beta 7
[10:56] <gord> must be a fun cairo problem then
[10:57] <didrocks> gord: not really on firefox vs launchpad for me, still the same bug where launchpad guys says "not our fault if we use repetition in images" and where Mozilla tells "we don't support that"
[10:57] <gord> if your website is slow in one of the worlds most popular browsers, it is your fault ;)
[10:58] <seb128> njpatel, because they changed how the handlers are working
[10:58] <seb128> njpatel, re <njpatel> why does natty insist that I am using firefox as my default browser?
[10:58] <seb128> njpatel, you need to claim the handler/http type in the .desktop or something
[10:58] <seb128> njpatel, check with chrisccoulson if you want for the specifics, he fixed firefox for it
[10:59] <seb128> chrisccoulson, ^ (didn't notice you were here)
[11:01] <chrisccoulson> njpatel, i think the only way to set your default browser currently is by hand editing mimeapps.list
[11:01] <smspillaz> dbarth: it's already known where the g_main_loop is going to impact plugins
[11:02] <smspillaz> dbarth: basically 1) can't re-set timers while running (glib regression)
[11:02] <smspillaz> 2) the filewatch stuff needs to be ported
[11:02] <chrisccoulson> njpatel, you need to edit ~/.local/share/applications/mimeapps.list and add something like x-scheme-handler/http=chromium-browser.desktop;firefox.desktop
[11:02] <chrisccoulson> (and the same also for https)
[11:02] <njpatel> chrisccoulson, ah, thanks
[11:03] <chrisccoulson> njpatel, this will be fixed in firefox once mozilla bug 611953 has landed, but i don't know if anybody is working on the chromium changes
[11:03] <njpatel> interesting
[11:04] <chrisccoulson> i guess i should reserve some time to fix chromium too
[11:12] <seb128> chrisccoulson, don't bother, fta will likely do it
[11:16] <seiflotfy_> njpatel,
[11:16] <seiflotfy_> http://seilo.geekyogre.com/uploads/2010/11/Screenshot.png
[11:16] <seiflotfy_> :)
[11:16] <njpatel> seiflotfy_, niiice :D
[11:17] <seiflotfy_> i even have a video showing that it works
[11:29] <gord> seiflotfy_, pretty! i wonder if we can do something about those icons though, maybe force a rounded edge
[11:31] <seiflotfy_> gord, good idea
[11:36] <kamstrup> njpatel: yeah, rounded edges would be nice. That could be a new renderer
[11:37] <njpatel> kamstrup, yep, it definitely will be
[11:37] <njpatel> the plan is to make the entire thing look nicer and add a few more renderers at the same time
[11:38] <kamstrup> njpatel: I assume you are the scoundrel that removed all my unit tests for UnityAppInfoManager?
[11:38] <njpatel> kamstrup, yes, yes, don't worry, they will be restored
[11:39] <kamstrup> njpatel: yeah, because I'm just updating Unity.IO and Unity.AppInfoManager to conform to the latest breakage in the GIO VAPI
[11:39] <njpatel> ah, right
[11:40] <kamstrup> njpatel: I had to break libunity API for that, and it would be nice to assert that I didn't break too much :-)
[11:41] <seiflotfy_> njpatel, must i remind you of http://twitter.com/#!/njpatel/status/19843856935
[11:43] <njpatel> kamstrup, will try and have that by EOF, before releasing for A1. I'm currently trying to figure out why unity is so crashing on maverick
[11:44] <njpatel> mavercik? I mean natty
[11:44] <njpatel> seiflotfy_, yeah, but after that we found one bug of kamstrup, therefore he's just as crap as the rest of us!!!!
[11:44] <seiflotfy_> w000000000000000000t
[11:44] <seiflotfy_> how dare you
[11:45] <spikeb> for what it is worth, it is quite crashing on maverick too ;)
[11:46] <njpatel> :)
[11:49] <njpatel> any specifc apps that cause the crash would be helpful :)
[11:50] <njpatel> knowing which specific... *
[11:50] <njpatel> wow, shadows are broken
[11:51] <spikeb> in my case, its firefox and gwibber that tend to do it. the first far more than the second.
[12:00] <nerd_bloke> Would the following bug be suitable for a papercut, it is basic functionality of Launchpad, not the desktop:
[12:00] <nerd_bloke> https://bugs.launchpad.net/bugs/68277
[12:11] <kamstrup> so who had the fun idea of doing infinite recursion in unity?
[12:11] <njpatel> hmm, these bamf crashes are weird
[12:12] <njpatel> Depends, where does it happen? if it's panel then probably me
[12:12] <kamstrup> njpatel: i'm not really sure because it's hard to get a stack trace...
[12:15] <kamstrup> njpatel: here http://paste.ubuntu.com/535171/
[12:16] <njpatel> mother of god
[12:16] <njpatel> at least it's not me
[12:16]  * njpatel tries to decipher that
[12:26] <nacho1977> hi there
[12:28] <kamstrup> njpatel: the nice thing about c++ is that it gives you totally easy to read stack traces ;-)
[12:29] <kamstrup> njpatel: I think it must be some compiz related change that caused this since the changes in unity since last are minimal
[12:29] <smspillaz> njpatel: c++filt. learn it. live it. love it.
[12:30] <smspillaz> kamstrup: hm?
[12:30] <kamstrup> smspillaz: what's your take on here http://paste.ubuntu.com/535171/ ?
[12:30] <njpatel> kamstrup, does it happen every start?
[12:30] <kamstrup> njpatel, smspillaz: happens whenever I start 'compiz ccp'
[12:30] <smspillaz> sigc failing at life as usual
[12:31] <smspillaz> let me have a look at the code
[12:31] <njpatel> smspillaz, what does ccp actuall mean/do? I don't ever start compiz with it
[12:31] <smspillaz> njpatel: compiz configuration plugin
[12:31] <njpatel> i'm assuming that's default?
[12:31] <smspillaz> njpatel: it's basically left behind from the whole compiz-fusion/compiz thign when david reveman wouldn't accept our patches for ccsm and like so we wrote our own configuration thingo
[12:31] <njpatel> ah
[12:31] <smspillaz> njpatel: but yes, it is the default, no, it can't go into core for various reasons
[12:32] <njpatel> sure
[12:32] <smspillaz> :p
[12:33] <smspillaz> we also have a small ini plugin that we ship with core too which is a bit lighter than compizconfig, but there's no graphical tool for it
[12:34] <njpatel> if we can pull glib into trunk, can we just have a gsetttings plugin and be done with it?
[12:34] <smspillaz> njpatel: it will be much easier to write a gsettings backend for libcompizconfig
[12:34] <njpatel> seems like it would solve your problems (dconf or keyfile backend), and you don't need to maintain it
[12:34] <njpatel> cool
[12:34] <smspillaz> in fact, we can do that right now
[12:34] <smspillaz> ... I just need to finish my mountain of other stuff too
[12:35] <smspillaz> also, I don't want to pull glib into trunk just yet because there is some mainloop stuff that is NI
[12:35] <smspillaz> (eg filewatches
[12:35] <njpatel> right, no rush :)
[12:35] <didrocks> njpatel: it seems we won't take the gsettings backend this cycle if we don't upgrade g-s-d, which is more than probable
[12:37] <njpatel> cool
[12:37] <didrocks> njpatel: is it a cool like a monkey island: "nice"? :)
[12:38] <njpatel> :)
[12:41] <smspillaz> kamstrup: hmm, sigc::mem_fun (this, &Launcher::RecvMouseDown) should basically not compile if you ask it to do something unsafe
[12:41] <smspillaz> kamstrup: maybe run it through valgrind to see exactly what stupid things it is doing?
[12:42] <nacho1977> anybody knows why my desktop appears as a folder but it does not act as desktop
[12:42] <nacho1977> UBUNTU 10.10
[12:42] <nacho1977> MACUBUNTU 10.10 sorry
[12:42] <smspillaz> nacho1977: probably /apps/nautilus/whateveritis/show_desktop is disabled in gconf
[12:45] <smspillaz> also "macbuntu" == "ubuntu". it is just a theme + some settings
[12:45] <fagan> it is very accurate though I have to say
[12:46] <smspillaz> eh
[12:46] <fagan> it just shows how awesome docky is for that bottom bar thingy
[12:46] <smspillaz> the stacks thing looks .. wrong
[12:47] <fagan> yeah but thats the only major thing thats different
[12:47] <smspillaz> panel proportions are incorrect
[12:47] <smspillaz> app name not shown in panel
[12:47] <smspillaz> icons are not spaced correctly
[12:47] <fagan> hmmm well on maybe its just on the surface then that it looks right
[12:47] <smspillaz> spotlight icon not shown correctly
[12:47] <smspillaz> top panel too big
[12:47] <smspillaz> color icons in top panel
[12:48]  * fagan only used a mac for like 10 minutes in the past 3 years 
[12:48] <smspillaz> IMO, ambiance looks closer to mac os x than macbuntu does
[12:48] <fagan> I like radience better :)
[12:48] <smspillaz> fagan: ah ok. I've got an osx86 install that I use regularly, so that probably explains why I have an eye for these things ;-)
[12:48] <fagan> I keep an eye on their website though to see what they are up to
[12:49] <fagan> and i was impressed by those 10 minutes
[12:49] <smspillaz> it's pretty good now actually
[12:49] <fagan> :)
[12:49] <smspillaz> it has pretty much got to the point where you just burn preboot ISO, insert preboot ISO, eject disc, insert off-the-shelf disc, hit enter, done
[12:49] <smspillaz> if you have supported hardware that is
[12:50] <smspillaz> this dell laptop is pretty much the same as an early 2008 macbook pro hardware wise
[12:50]  * smspillaz has everything working except for restart
[12:50] <fagan> I think some of the ARM devices are cooler than that new macbook air
[12:50] <smspillaz> indeed
[12:50] <smspillaz> I was tempted to pick up one of those until I saw the CX300 ;-)
[12:51] <fagan> Well toshiba have a new touchbook that runs android and its just like an iPad in many ways
[12:51] <fagan> maybe not the same hardware but its still cool
[12:51]  * smspillaz bets it runs android 1.6
[12:52] <fagan> hah well when im getting one im going to put ubuntu on it
[12:52] <smspillaz> that sounds like a treck
[12:52] <fagan> I prefer unity's interface to android on that sort of thing
[12:52] <smspillaz> is there opengl accelleration??
[12:52] <fagan> its a little bit of a chore to get android off
[12:53] <fagan> well there is but its 2d at the moment
[12:53] <fagan> I think 3d is coming soonish though thanks to linaro
[12:53] <smspillaz> so, no opengl accelleration ;-)
[12:54] <fagan> it would be safe to say we will probably have 3d accelleration by the next LTS
[12:54] <smspillaz> maybe
[12:54] <fagan> im happy with that
[12:54] <smspillaz> the thing to remember is that those devices probably have some kind of powervr chipset
[12:54] <smspillaz> and those things are notoriously closed and notoriously difficult to write drivers for
[12:54] <fagan> yeah
[12:55] <fagan> but if it works on android there should be kernel support somewhere for it
[12:55] <smspillaz> the problem is that the driver is closed source
[12:55] <boulabiar> fagan: you want to install ubuntu on a tablet ?
[12:55] <fagan> boulabiar: probably when I get one
[12:55] <smspillaz> powervr will only give you specs under an NDA, and that means closed drivers
[12:56] <boulabiar> fagan: because we lack a demo for ubuntu running on a tablet
[12:56] <smspillaz> NDA + $$$$$$ licence fees
[12:56] <fagan> boulabiar: well there was the one on canonical's blog a month or so ago with the dell tablet
[12:57] <boulabiar> there is a difference between a tablet-pc and a tablet
[12:57]  * smspillaz has a wacom bamboo tablet!
[12:57] <smspillaz> (ah, damn, the play on words stops there)
[12:57] <fagan> hmmmm do we actually have an onscreen keyboard made yet?
[12:58] <boulabiar> some one exist already
[12:58] <boulabiar> I know literki for example
[12:59] <fagan> I remember it was a session in the past 2 UDS but I didnt see any yet
[12:59]  * fagan looks in the repo 
[13:00] <Devil505> hi :)
[13:00] <fagan> oh there is an onscreen keyboard in the repo its called "onboard" and the screenshot looks like ass
[13:01] <fagan> there is one cool one I found
[13:02] <boulabiar> fagan: try literki, it has a very bad gui, but it works
[13:02] <fagan> boulabiar: there was a cool looking one called keyboard in the repo
[13:02] <fagan> it looks like a mac keyboard
[13:03] <boulabiar> was ?
[13:03] <fagan> but ill have a poke about when I actually get a tablet to use it on
[13:03] <fagan> boulabiar: is :)
[13:06] <fagan> oh and that tablet is on 2.2 of android
[13:08] <smspillaz> cool
[13:08] <smspillaz> wow, I have not written python in a long time it seems
[13:09] <boulabiar> fagan: which one ?
[13:10] <fagan> boulabiar: toshiba folio 100
[13:10] <boulabiar> hmm, I'm thinking in the same model too :)
[13:10] <boulabiar> but it should be possible to put ubuntu on it
[13:11] <fagan> yeah its after dropping in price since everyone started sending them back when they couldnt use adobe flash on it
[13:11] <fagan> boulabiar: its the same spec as the ac100 which works ubuntu out of the box
[13:11] <fagan> just a different screen
[13:11] <boulabiar> I've only found this to get into the bootloader http://forums.computers.toshiba-europe.com/forums/thread.jspa?threadID=57467
[13:11] <didrocks> smspillaz: no opinion against the detection plugin using dbus to communicate with the session handler?
[13:12] <didrocks> smspillaz: I've hooked gnome-session so that we can dynamically tells "this app should be autorespawn" or not
[13:12] <fagan> boulabiar: there is some annoying steps to go through
[13:13] <smspillaz> didrocks: hmm. stick it in there for now I guess, although I should really make the dbus plugin for compiz a better ... dbus plugin
[13:13] <smspillaz> it's a bit crap right now
[13:13] <didrocks> smspillaz: ok, not sure how dbus works in C++, let's see :)
[13:14] <smspillaz> didrocks: basically just make sure you extern C your callbacks
[13:14] <smspillaz> ugh, I'm so damn tired
[13:14] <didrocks> smspillaz: ok
[13:14] <didrocks> smspillaz: take some rest :)
[13:15] <smspillaz> no idea why, for some reason I will just become *really* tired for one week, and I can sleep for like 14 hours straight with no effect
[13:15]  * smspillaz is probably anemic or something
[13:15] <didrocks> :/
[13:15] <smspillaz> probably just a post-exams slump
[13:15] <smspillaz> I'll finish this script tonight at least
[13:15] <boulabiar> smspillaz: the current compiz dbus plugin crashes any dbusviewer app (like d-feet)
[13:16] <smspillaz> boulabiar: yeah. that should be fixed now
[13:17] <fagan> didrocks: are you guys doing thursday/friday releases of unity?
[13:17]  * fagan was wondering when to expect expect some testing
[13:18] <didrocks> fagan: yeah
[13:20] <smspillaz> boulabiar: hm strange, qdbusviewer seems to be able to view compiz dbus stuff fine, but not d-feet
[13:38] <rsajdok> I am trying to compile unity. I get error: http://pastie.org/1317276 Any suggestion?
[13:40] <boulabiar> smspillaz: qdbusviewer don't view all compiz dbus stuff :)
[13:41] <boulabiar> d-feet output is larger, but it blocks most of times
[14:11] <njpatel> rsajdok, you need the latest libbamf-dev, you can get it from this repo ppa:unity
[14:21] <rsajdok> njpatel: I have it
[14:21] <jcastro> hey dbarth
[14:22] <jcastro> so I was testing unity this weekend on my laptop
[14:22] <jcastro> and you know how we want to switch over to it soon
[14:22] <jcastro> well, it's impossible to do the roaming laptop usecase without a network indicator
[14:22] <jcastro> just something we might want to think about before we switch it over
[14:26] <njpatel> jcastro, systray, you mean? or were you using indicator-network and it didn't work?
[14:27] <njpatel> rsajdok, not sure then, that compile error seems definitely to be about not finding the latest headers of  bamf
[14:27] <jcastro> I was using defaults, so no indicator-network
[14:27] <njpatel> maybe the paths are wrong?
[14:27] <njpatel> jcastro, right
[14:27] <jcastro> njpatel: it was my understanding that we were adapting the indicator to work with nm?
[14:27] <njpatel> i'm not sure of the indicator plans
[14:27] <njpatel> indicator-network plans, I mean
[14:27] <rsajdok> njpatel: Maybe Must I have latest source version of libbmaf-dev ?
[14:28] <njpatel> rsajdok, source, no, but you need the latest package, yep
[14:31] <seb128> njpatel, we still have a systray for compat anyway no?
[14:32] <njpatel> not right now
[14:32] <njpatel> i haven't added it to the panel yet
[14:32] <seb128> but it will come back?
[14:32] <njpatel> seems like it could be important for A1 :)
[14:32] <njpatel> yep
[14:32] <jcastro> oh, I thought it wasn't coming back
[14:32] <seb128> like it's somebody not done yet, not a decision to deprecate it yet?
[14:32] <njpatel> it's back for network manager and wine apps, I think
[14:32] <njpatel> the rest will be rejected
[14:32] <seb128> njpatel, ok great, and yeah, without it no nm-applet
[14:33] <jcastro> ok so if we want A1 to have unity by default then you need that.
[14:33] <jcastro> njpatel: I just wasn't sure if anyone had realized it; I was at some coffee shop and I sat there staring at my screen "surely we thought about this"
[14:33] <jcastro> I then shook my fist in your general direction
[14:34] <njpatel> lol
[14:34] <seb128> njpatel, I think filtering other things out is an error
[14:34] <njpatel> I'm just trying to fix the natty crashers at the moment, then I'll prioritise the systray support
[14:34] <seb128> njpatel, but let's not argue about that today
[14:34] <njpatel> seb128, speak to mpt about it, I'm just the code monkey in this case :)
[14:34] <seb128> mpt, ^ I think doing that is an error
[14:35] <seb128> njpatel, done ;-)
[14:35] <njpatel> heh
[14:35]  * njpatel tests 5th bamf build of the day
[14:35] <seb128> joke aside users will probably have issues with some of the things we change, we probably don't want to add frustration because their applications break
[14:36] <seb128> or they will associate that frustration with unity
[14:36] <jcastro> well, I think having broken things is fine in A1, anything but networking though
[14:36] <seb128> you don't convince users by breaking what they use and telling them they should not having been using the software they use
[14:37] <njpatel> seb128, btw, where are all the -dbg packages for natty?
[14:37] <njpatel> is there a ddebs natty repo?
[14:37] <seb128> njpatel, yes
[14:38] <njpatel> oooh
[14:38] <seb128> same as for any serie
[14:38] <seb128> you just need to update the sources.list line to use the correct distro
[14:38] <jcastro> hey seb128, is it useful for people testing upstreams to have those installed? Like, if I were to ask banshee testers to use those for example.
[14:39] <seb128> jcastro, those what?
[14:39] <seb128> dbg?
[14:39] <jcastro> yeah, the dde
[14:39] <seb128> the dbg are useful to get debug stacktraces
[14:39] <jcastro> yeah the ddebs repo (sorry, new keyboarD)
[14:40] <seb128> but I don't think it would work with mono
[14:40] <jcastro> ok
[14:40] <seb128> we still not have nice apport,mono integration I think
[14:40] <seb128> the mono crashes are not handled the same way that C crashes
[14:40] <jcastro> we do not
[14:40] <seb128> ok so no point for banshee
[14:40] <seb128> it's useful for unity though
[14:40] <jcastro> I have a WI to ask someone from upstream to talk to pitti
[14:41] <jcastro> should we add the instructions to the unity install pages then?
[14:41] <rsajdok> njpatel: I think I have latest version: http://pastie.org/1317426
[14:41] <seb128> jcastro, well that's rather for a debug package
[14:42] <seb128> jcastro, but I will let didrocks or njpatel or lamalex comment about debug instructions
[14:42] <jcastro> seb128: right, I guess what I am asking is, if we want people banging on unity is it worth having them install the debug stuff.
[14:42] <jcastro> ok
[14:42] <seb128> ideally we would let apport catch the crash and retrace those
[14:42] <seb128> but we are a bit early in the cycle, I'm not even sure we have natty retracers yet
[14:42] <njpatel> rsajdok, can you do apt-cache policy libbamf-dev please
[14:42] <didrocks> for banshee apport?
[14:42] <jcastro> didrocks: I mean all of unity
[14:42] <didrocks> I get something done, but then, upstream didn't answer if it was right or not for those
[14:43] <didrocks> jcastro: I have a WI on that, just ETOOMUCHWORK
[14:43]  * jcastro nods
[14:43] <didrocks> and ETOOMUCHPING too :)
[14:43] <njpatel> didrocks, stop striking once a week then
[14:43]  * didrocks runs after njpatel :)
[14:43] <njpatel> :)
[14:43]  * njpatel tries to crash unity again
[14:43] <mpt> njpatel, seb128: See https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-nm-indicator
[14:44] <jcastro> didrocks: if you're getting pinged too much close all your channels except an emergency PM window to seb and njpatel, done. :)
[14:44]  * njpatel needs to do that too
[14:44] <didrocks> jcastro: well, right, I should think about that seriously…
[14:44] <jcastro> didrocks: I don't even join IRC for the first hour of the day
[14:45] <didrocks> jcastro: same for me, but still…
[14:45] <rsajdok> njpatel: http://pastie.org/1317429
[14:45] <lamalex> the fact that bzr doesn't commit after merge drives me nuts
[14:46] <njpatel> rsajdok, right, you need 0.2.60 from ppa:unity (sudo add-apt-repository ppa:unity)
[14:46] <njpatel> lamalex, you might need to fix conflicts/make changes?
[14:46] <njpatel> (to make a successful merge)
[14:47] <lamalex> so if merge fails then don't commit (what git does)
[14:47] <lamalex> but if everything is A-OK, commit the merge dog
[14:48] <njpatel> lamalex, i think the idea is that you might have a successful merge but your code might not build
[14:48] <njpatel> bzr doesn't know so it doesn't be clever
[14:49] <njpatel> jcastro, are you on natty + unity + amd64 and experiencing crashes?
[14:49] <njpatel> seb128, ^
[14:49] <njpatel> can you test my debs?
[14:49] <seb128> njpatel, intel there
[14:50] <seb128> x86 I mean, 32bits
[14:50] <njpatel> seb128, sorry, I meant 64-bit
[14:50] <njpatel> ah, right :)
[14:50] <seb128> I don't do 64 bits installs
[14:50] <seb128> it's always lagging behind on buildds etc ;-)
[14:50] <njpatel> anyone here on 64bits and natty and can test a new bamf package to see if unity crashes less?
[14:50] <njpatel> seb128, heh
[14:51] <rsajdok> njpatel: It works :) thanks
[14:51] <jaytaoko> njpatel: I am on 64 bits on macbook pro
[14:51] <jaytaoko> njpatel: where is the package?
[14:52] <pavolzetor> I can
[14:52] <seb128> hy jaytaoko
[14:52] <pavolzetor> I have compiz unity
[14:52] <jaytaoko> seb128: Bonjour!
[14:52] <seb128> mpt, right, that doesn't fix the issues I described though
[14:53] <jaytaoko> seb128: so what is to be tested? should I just get lp:bamf and see if it works?
[14:54] <jaytaoko> seb128: oh wait... I am still on maverick...
[14:54] <seb128> jaytaoko, you want to talk to njpatel
[14:54] <jaytaoko> seb128: ok
[14:54] <jcastro> njpatel: I have 2 amd64/natty/unity machines, no crashers in a while
[14:55] <seb128> jaytaoko, he was the one asking, I just said hello ;-)
[14:55] <jaytaoko> seb128: no problem :)
[15:03] <njpatel> jaytaoko, no, hold up
[15:03] <jaytaoko> njpatel: ok
[15:08] <njpatel> didrocks, natty doesn't have bamf 0.2.62!
[15:09] <didrocks> njpatel: waow, forgot to upload it, it seems, I have it locally. It was just a crasher fix, no new api IIRC, isn't it?
[15:09] <njpatel> didrocks, yeah, that's the thing that fixes the crasher!
[15:10] <njpatel> s/thing/release
[15:12] <didrocks> njpatel: uploaded, sorry dude
[15:13] <njpatel> didrocks,
[15:13] <njpatel> didrocks, np dude, I think that'll fix a bunch of crashers
[15:19] <rsajdok> njpatel: I made this guide https://wiki.ubuntu.com/Unity/InstallationGuideFromSource, but what now to build *.deb file to test on other machine ?
[15:21] <MacSlow> tedg, ding-dong
[15:21] <MacSlow> tedg, which example/test for dbusmenu can you recommend that would build a dbusmenu with all different types of items?
[15:22] <njpatel> rsajdok, er, that's harder and a bit out of my depth. I think you can use the packaging branches located at lp:~unity-team/$PROJECT/packaging
[15:25] <tedg> MacSlow, If you're looking for the app-indicators I'd just to the simple-client in lp:indicator-application
[15:25] <tedg> MacSlow, It also has ones that you can click on to change state.
[15:25] <MacSlow> tedg, ok... I'll take a look
[15:25] <tedg> MacSlow, It's not exhaustive for the menuitems, but it'd be a good start.
[15:26] <MacSlow> tedg, I'll see how far I can get... otherwise I'll poke you again :)
[15:27] <lamalex> grr
[15:27] <lamalex> Why can't compilers give sane output
[15:27] <lamalex> https://pastebin.canonical.com/40022/ doesn't mean anything
[15:27] <lamalex> tell me what the real problem is
[15:36] <kklimonda> I can only guess you are writing in C++ ;)
[15:37] <lamalex> kklimonda, yah
[15:37] <lamalex> making introspect non-virtual fixes it, but it shouldn't matter it's implemented in Introspectable.cpp
[15:39] <lamalex> I guess it doesn't really need to be virtual
[15:48] <lamalex> njpatel, https://code.launchpad.net/~alexlauni/unity/state-introspection/+merge/41479
[15:48] <rsajdok> nejpatel: How do you test your code? Do not create *.deb file?
[15:48] <njpatel> lamalex, awesome dude, will review it as soon as I'm done with this other stuff
[15:57] <lamalex> njpatel, thanks
[16:28] <mhr3> c++ with plain glib calls... that looks odd :)
[16:30] <lamalex> dbarth, sure
[16:32] <lamalex> smspillaz, does compiz have anything in the way or perf logging at the moment?
[16:32] <dbarth> lamalex: so the atk bridge
[16:32] <dbarth> lamalex: what i was thinking was that you could write a small test module that loads the module (or makes sure the way we integrate gtk already brings that correctly into the process space anyway)
[16:33] <dbarth> lamalex: and then have a fake gtk widget somewhere to see if it's properly exposed in orca
[16:33] <dbarth> that way you'd know that this part of the job is done
[16:33] <dbarth> and luke can come from the other end
[16:33] <smspillaz> lamalex: no, not yet
[16:34] <lamalex> dbarth, ok sure, that makes sense
[16:34] <dbarth> and have his code work, because the foundations are sane
[16:34] <lamalex> so I am working on making sure atk gets loaded, luke is implementing/integrating atk
[16:34] <dbarth> right
[16:34] <lamalex> good stuff
[16:34] <dbarth> you may have noticed also an update in the spreadsheet
[16:35] <dbarth> i've marked the dbus api mostly done
[16:35] <dbarth> and in maintenance mode now
[16:35] <dbarth> ie, what i think is left is: adding more objects to the registry, exposing more of them, but that should mostly be done by other developers when they implement something new
[16:36] <dbarth> based on the example code you can give them
[16:36] <dbarth> and also what jibel was asking for, ie merging the code and getting screen coordinates in the widgets
[16:40] <jcastro> njpatel: did you need me to test anything on amd64?
[16:43] <njpatel> jcastro, no, i didn't realise that the version was wrong in archive, sorry. When bamf is built in main, please update when you can and see if everything behaves more properly with it
[16:43] <jcastro> njpatel: ok, so just overall try it or was something messed up specifically?
[16:44] <njpatel> overall, just to see if you get less crashes when minimising/restoring windows
[16:44] <njpatel> and generally better stability
[16:44] <dbarth> lamalex: so on atk there is still a bit of work, but i'm expecting that to be hopefully limited now on
[16:46] <lamalex> dbarth, re: pipeline- ive proposed merging, and on-screen coordinates should be added as properties, right?
[16:46] <jcastro> njpatel: ok, I'll get some forum feedback for you too, amd64 specific?
[16:46] <didrocks> smspillaz: ok, thinking a little bit more about the profiles, I guess that with the Unity.profile, there will be no way to add "new defaults" once the profile picked by the gconf backend?
[16:46] <njpatel> jcastro, nope, across the board. Thanks!
[16:47] <jcastro> rock
[16:47] <lamalex> dbarth, what do you mean by "so on atk there is still a bit of work, but i'm expecting that to be hopefully limited now on"
[16:48] <smspillaz> didrocks: what do you man
[16:48] <smspillaz> *mean?
[16:49] <didrocks> smspillaz: well, let's say that we activate today "foo, app, bar" plugins -> we set it in the Unity.profile file, right? Then compiz load it (by the environment variable), this profiles sets a gconf backend and the keys are imported
[16:49] <didrocks> smspillaz: let's say that the user doesn't change the plugin list and still have the default
[16:49] <didrocks> and we want to add the awesome baz plugin to the list
[16:49] <smspillaz> didrocks: sure
[16:49] <smspillaz> didrocks: oh, the profile is only the defaults
[16:49] <didrocks> smspillaz: I mean, we want to add baz on the default :)
[16:50] <smspillaz> ah right
[16:50] <didrocks> so, we add it to Unity.profile -> ok for newcomers
[16:50] <didrocks> but for old and intrepid natty testers?
[16:50] <smspillaz> if the profile changes I think it overwrite the settings of the old one
[16:50] <didrocks> (I raise the point because that will happen for sure)
[16:50] <didrocks> smspillaz: ok, needs testing then
[16:50] <smspillaz> if profile != settings && then settings = profile
[16:50] <smspillaz> if you load the profile directly
[16:50] <smspillaz> iirc
[16:51] <didrocks> smspillaz: even if the profiles tells "use gconf backend"
[16:51] <smspillaz> doesn't matter which backend you sue
[16:52] <didrocks> smspillaz: ok, we'll see and test this then, sounds good if it's that :)
[16:52] <smspillaz> cool
[16:52] <didrocks> smspillaz: btw, why s0 in s0_active_plugins ?
[16:52] <smspillaz> didrocks: screen0
[16:52] <didrocks> ok :)
[16:52] <didrocks> thanks!
[16:52] <smspillaz> it should probably die now because we don't support multiscreen but I forgot to remove it
[16:53] <smspillaz> doesn't matter anyways though because everything is s0
[16:53] <didrocks> yeah, sounds a post alpha1 task :)
[16:56] <dbarth> lamalex: sorry, was on a call
[16:56] <dbarth> lamalex: so
[16:56] <lamalex> dbarth, no problem
[16:56] <dbarth> lamalex: hoping that this task is a 10-15% of your time this week
[16:56] <dbarth> so that you can take new ones ;)
[16:57] <dbarth> hence the 2 new i've highlighted in the spreadsheet, ie: the atk one, and getting started (later in the week) on some compiz performance checks
[16:58] <lamalex> dbarth, i just started syncing up with smspillaz on compiz perf counters
[17:09] <Technoviking> njpatel: the new bamfdaemon is a definitely a speed boost, but I'm have applets crash. Need a bug report, is there one already
[17:10] <njpatel> Technoviking, applets?
[17:10] <njpatel> Technoviking, is unity crashing?
[17:11] <Technoviking> the clock, indictor-applet crash and ask to reload everytime I login unity, they 1/2 the unity will disappear afterwards
[17:12] <Technoviking> spell: then 1/2 the time unity will crash/disappear
[17:12] <njpatel> Technoviking, okay, so the indicator's are because of the gnome-panel, it's not really related to unity specifically, it's just natty being not very stable
[17:12] <njpatel> Technoviking, the 1/2 time crashing is what, specifically, I hope the bamf update makes better
[17:13] <njpatel> Technoviking, so if unity is a little more robust after the update, then that would be good. If there are other crashes, then hopefully apport can pick them up
[17:13] <dbarth> lamalex: cool
[17:14] <dbarth> (sorry on another call now)
[17:37] <kenvandine> tedg, did you get a chance to look at the dbusmenu gir i sent you?
[17:38] <tedg> kenvandine, No, I forgot.  Sorry.
[17:38] <dbarth> seb128, tedg, kenvandine: so for dbusmenu/gdbus, and other libs we're porting to gdbus, are you guys happy to land them in alpha-1 even of they're not used yet?
[17:38] <tedg> dbarth, ?  I'm not sure what you're asking there.
[17:38] <seb128> dbarth, we do use dbusmenu?
[17:39] <tedg> dbarth, They *are* used
[17:39] <seb128> the port is a new version, not a new lib
[17:39] <dbarth> but the gdbus version, we can't switch to that until ther other bits are migrated, right?
[17:39] <tedg> dbarth, Correct, so if we "land them" well end up with most of the archive in depwait...
[17:39] <tedg> we'll
[17:39] <dbarth> so, should we land them, is the question?
[17:40]  * tedg probably overstated the importance with "most of the archive", but he likes it better that way.
[17:40] <tedg> dbarth, No, they need to land together (or close to together0
[17:40] <tedg> )
[17:40] <dbarth> ie, can the build system figure out that the version numbers are different and is not required by anyone, so should'nt be used, or will it just try to link with the latest and break everything?
[17:40] <dbarth> tedg: ok
[17:41] <dbarth> but isn't there a way to use some conflicts or .so bumps or something?
[17:41] <tedg> dbarth, If we just left it the linker, everything would break.  But we'll tell the packaging of the issues, and it'll ensure that nothing breaks.  That though means that it'll hold stuff back.
[17:42] <dbarth> ok, so the answer is really "no "i guess ;)
[17:42] <kenvandine> i think dbarth was suggesting we upload the libraries that are ported and leave the indicators that use them link against the old versions for now
[17:42] <kenvandine> or if it is worth the trouble
[17:42] <dbarth> apperently the build system will not like it unless we change a lot of other packages
[17:42] <tedg> kenvandine, Yeah, but they won't continue to build against the old versions if the -dev packages aren't versioned.  So then we can't release any indicators.
[17:42] <kenvandine> yeah
[17:43] <tedg> I'd rather not block indicator releases if they are needed.
[17:43] <dbarth> i don't want to rush things here, especially if that can create nastry issues like that at the build level
[17:43] <dbarth> there is already enough to do on this front with the gir issues
[17:43] <dbarth> right
[17:43] <tedg> Oh, I though they all were grrrrr issues :)
[17:43] <kenvandine> we need to just get things building on natty :)
[17:43] <kenvandine> grrrr
[17:44] <dbarth> and so the same is true of libzeitgeist?
[17:44] <dbarth> didrocks: ? ^^
[17:44] <tedg> dbarth, I don't think it has the same issue.
[17:44] <dbarth> not taking the new version until the other bits are ready
[17:44] <tedg> libbamf shouldn't have the same issue either.
[17:44] <Technoviking> njpatel: delete the bottpn panel got rid of the applet errors
[17:44] <dbarth> hmm, libdee and libzg at least
[17:44] <tedg> So it should be okay to release those two.
[17:45] <dbarth> that's what the places daemon use for interfacing with the bus
[17:45] <dbarth> libdee may be doable
[17:45] <njpatel> Technoviking, right, I think it's to do with the gtk3 stuff, I'm not sure, though
[17:46] <njpatel> Technoviking, or gsettings stuff....there's so much going on ;)
[17:46] <Technoviking> njpatel: heh, will keep testing and reportin problem, starting to become very awesome
[17:47] <njpatel> Technoviking, thanks, it's very much appreciated!
[17:48] <didrocks> dbarth: sorry, backlogging
[17:51] <didrocks> dbarth: no libzg does'nt' have the same issue, as it communicates with zg and just linked to unity AFAIK
[17:54] <didrocks1> "nice"
[18:06] <jcastro> are running gnome panels normal in the natty session? I have my old gnome-panels running underneath my unity panel
[18:31] <dbarth> jcastro: uh, not really
[18:32] <dbarth> jcastro: but didrocks told me he had not enabled unity by default yet though
[18:32] <jcastro> dbarth: it appears on 2 of my machines that we are, when I enable the compiz cube I can look underneath
[18:33] <dbarth> jcastro: let me try the cube
[18:34] <jcastro> hah, no wonder I was getting errors about applets not loading
[18:34] <jcastro> dbarth: you need to enable "rotate cube" too
[18:35] <dbarth> sure
[18:35] <dbarth> i don't see it here
[18:36] <dbarth> now that's on a hand built config.
[18:36] <dbarth> so there is something wrong with the packaging / default settings
[18:36] <jcastro> yeah, I'll file it and take a picture
[18:36] <dbarth> ok
[18:38] <dbarth> anyway, i guess we need to see with smspillaz next week (once alpha-1 is out safely) how we can define a unity profile that locks down some settings and plugins and make sure we can provide stronger support for that set when we get bugs
[18:38] <jcastro> nod
[18:38] <dbarth> ie, drawing a line so that the compiz and unity teams don't end up supporting configurations that have not been meant to work together
[19:15] <jono> dbarth, can we expect Unity to land by default in Natty on Thursday?
[20:08] <Devil505> i've a little problem:
[20:08] <Devil505>   CCLD   indicator-application-service
[20:08] <Devil505> The GObject name 'AppIndicator' isn't compatibile
[20:08] <Devil505> with the configured identifier prefixes:
[20:08] <Devil505>   ['AppIndicator']
[20:08] <Devil505> The class would have no name.  Most likely you want to specify a
[20:08] <Devil505> different --identifier-prefix.
[20:08] <Devil505> any idea ?
[20:39] <Devil505> ok i've found
[20:39] <Devil505> disabling introspection :)
[21:01] <Devil505> http://frugalware.org/~devil505/blog/?p=1519 :)
[21:08] <tedg> Devil505, If notify-osd used gsettings, wouldn't that work for you guys?
[21:09] <tedg> Instead of forking it, why not spend the time porting?
[21:09] <Devil505> tedg, it's not me but I can ask elentir :)
[21:10] <Devil505> have to go now, bye
[23:32] <fagan> jono: yep the releases are thursdays or fridays
[23:32] <fagan> I was talking with didrocks about it earlier
[23:35] <jono> fagan, I know the releases are then, I just want to know when it is switched on natty, and afaik it will be thurs :-)
[23:36] <fagan> hmmmm I heard rumblings they are doing it when the dash is working