[05:06] <didrocks> good morning
[08:53] <didrocks> jo-erlend: hey, do you have a minute? seif and I had some design question for zeitgeist integration and discovering files not opened
[09:34] <didrocks> JohnLea: (sorry jo) ^^
[09:47] <didrocks> Kaleo: hey, snapshot of unity-2d today?
[10:05] <Kaleo> didrocks: sure, why not
[10:05] <Kaleo> didrocks: going for lunch now, let's talk later
[10:05] <didrocks> Kaleo: sure
[11:41] <API> njpatel, I have some branches waiting for review
[11:42] <API> I pinged lamalex last week but it seems that he forgot that
[11:42] <API> you are also assigned, should I assign that to other people?
[13:26] <API> njpatel, lamlex ping:
 njpatel, I have some branches waiting for review
 I pinged lamalex last week but it seems that he forgot that
 you are also assigned, should I assign that to other people?
[13:26] <lamlex> API: sorry i ran into massive computer troubles
[13:26] <lamlex> i think i've got them sorted but just this morning
[13:27] <API> lamlex, no problem, just wanted to know if I should ask for review to other people
[13:56] <jjardon> tedg: Hey, Can I know your opinnion about https://bugs.launchpad.net/indicator-power/+bug/811777 and https://bugs.launchpad.net/indicator-power/+bug/811769 ?
[13:57] <jjardon> or maybe is better to ask mpt as they are more design questions?
[13:58] <tedg> jjardon, So when we have things like that which need design input we add a bug task for "ayatana-design" so that they can prioritize it.
[13:58] <tedg> jjardon, So "Also affects project"
[13:59] <tedg> I don't think it should hide when full though... that seems like a support call waiting to happen.
[13:59] <tedg> And I think we should fix upower to better time instead of going back to percentage.
[14:00] <jjardon> tedg: ok, done
[14:00] <tedg> But, I'll let mpt have a say on it ;-)
[14:02] <jjardon> tedg: about the changes in https://wiki.ubuntu.com/Power : any idea how implement the  certified or validated thing? Is there a database packaged somewhere with this info?
[14:02] <jjardon> Also, I already told mpt that I'm not very sure this is the correct level to achieve this, suspend should work out-of-the-box. If not It's a kernel bug
[14:03] <tedg> jjardon, That's a good question.  Let me find an answer for you.
[14:03] <tedg> jjardon, I think the idea was OEMs and other folks could install a package to change the default value of the DConf key.
[14:03] <tedg> jjardon, It is a kernel bug, but unfortunately a reality for many users.
[14:04] <jjardon> Maybe is better to simply disable the suspend configuration options if Its not supported by the kernel
[14:04] <tedg> jjardon, The problem is that many drivers say they support it and are infact wrong.
[14:04] <jjardon> tedg: IMHO hide a bug below a configuration options is not the better aproach
[14:06] <tedg> jjardon, I think perhaps we should hide the config if we know it's good...
[14:06] <tedg> jjardon, Only provide it on systems that aren't verified to be good.
[14:07] <jjardon> tedg: I like more that option
[14:07] <tedg> jjardon, Write it up as a bug, and assign ayatana-design ;-)
[14:08] <jjardon> tedg: sure, thanks!
[15:14] <MacSlow> ola
[15:42] <DBO> API, ping
[15:52] <API> DBO, pong
[15:52] <API> tell me
[15:52] <DBO> API, does the a11y api require that there be a window associated with an object?
[15:52] <DBO> so if I wanted alt-tab to be a11y, does it need a window?
[15:54] <API> Daviey, well, at this moment I suppose that the objects that get the focus
[15:54] <API> ups
[15:54] <API> sorry
[15:54] <API> DBO,
[15:54] <API> at this moment
[15:54] <API> the a11y code
[15:55] <API> supposed that the objects will be included on a basewindow
[15:55] <API> but I didn't check how alt+tab is working
[15:55] <DBO> brb
[15:55] <API> in fact I thought that this was made by compiz but
[15:55] <API> not by unity plugin itself
[16:04] <Andy80> hi :)
[16:05] <DBO> API, sorry about that
[16:06] <DBO> API, so alt-tab is in a baswindow
[16:06] <DBO> but that basewindow does not have a x window associated with it
[16:06] <DBO> is that a problem?
[16:07] <API> DBO, no
[16:08] <API> I don't go to low
[16:08] <API> Im trying to use nux as the most low level stuff here
[16:08] <API> if there are a nux::basewindow and gets the focus
[16:08] <API> it would be ok
[16:09] <DBO> API, what about for the input method support?
[16:09] <DBO> (I am thinking about dash now)
[16:09] <API> dash is using a custom input method ?
[16:09] <API> for what?
[16:10] <DBO> its not currently
[16:11] <DBO> but I assume it would eventually need to use SCIM or whatever is common now
[16:12] <API> aha
[16:13] <DBO> does that need an x window?
[16:13] <API> well, in that case, eventually I would require to check it
[16:13] <API> ;)
[16:13] <API> but in the case of the key events
[16:13] <API> Im also using nux
[16:13] <API> and fwiw, one of the pending things that I have in my todo
[16:13] <API> in add AtkText and AtkEditable text support on nux textual objects
[16:14] <jjardon> tedg: done https://bugs.launchpad.net/ayatana-design/+bug/812394
[16:14] <API> DBO, so, please notify me when if you start to work on the input method stuff
[16:14] <API> so I could check that
[16:15] <API> and btw, that I already asked that
[16:15] <jjardon> tedg: FYI upstream seems to like the idea
[16:15] <API> DBO, so now unity itself will take care of the alt-tab stuff?
[16:16] <DBO> API, yes
[16:16] <API> ok, better
[16:16] <API> as in this case I would not need to take care also about compiz stuff
[16:17] <mterry> smspillaz, just FYI, that modal-compiz-ldtp question I had on Friday I'm currently pinning on LDTP after finding out it's not directly modal related.  I filed a bug, we'll see what they say
[16:29] <lamalex> API, i'm reviewing your gconf -> gsettings branch now
[16:30] <lamalex> we should file a bug on gsettings to not abort when a freaking schema is missing
[16:30] <lamalex> if there already isn't one
[16:30] <lamalex> seriously that is rediculous
[16:31] <API> lamalex, there are already one bug
[16:31] <API> and some weeks ago
[16:31] <API> a flame in a mailing list
[16:31] <API> I don't remember which one
[16:31] <API> probably desktop-devel
[16:31] <API> in summary, this is the way to go
[16:32] <API> check if the schema are present
[16:32] <API> if you want to be sure that _schema_new will not crash
[16:33] <API> lamalex, http://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00099.html
[16:40] <lamalex> API, +1, merge it up
[16:41] <API> lamalex, ok thanks
[16:41] <lamalex> API, reviewing the focus branch now
[16:41] <API> lamalex, I would prefer if you review the other one
[16:42] <API> is really more smaller
[16:42] <API> so I could get and answer faster
[16:42] <API> and it is a regression
[16:42] <lamalex> which other?
[16:42] <lamalex> i reviewed the gconf one already
[16:42] <API> the focus branch are improvements
[16:42] <API> lamalex, https://code.launchpad.net/~apinheiro/unity/bug810045
[16:42] <lamalex> ok
[16:43] <lamalex> API,  the unity script isn't called by default
[16:43] <lamalex> didrocks, am I right on that? ^^^
[16:43] <API> hmm
[16:43] <API> so we have a problem here ...
[16:43] <lamalex> to save time to avoid python
[16:44] <API> so taking into account that we want that env vars properly set
[16:44] <API> before running unity
[16:44] <didrocks> lamalex: right, it's not called
[16:44] <API> where should I set those?
[16:44] <API> didrocks, could you take a look to that branch?
[16:44] <API> https://code.launchpad.net/~apinheiro/unity/bug810045
[16:44] <didrocks> looking, one sec
[16:44] <lamalex> API, it wasn't working the other way?
[16:45] <API> if I can't do that on the unity script not sure where I should do that
[16:45] <API> lamalex, what means the other way?
[16:45] <API> without that branch?
[16:45] <lamalex> the current way
[16:45] <lamalex> in the code
[16:45] <API> lamalex, the current way is
[16:45] <didrocks> API: why do you need those env var?
[16:45] <API> on the unityshell initialization code
[16:45] <API> didrocks, because if not
[16:46] <API> when calling gtk_init
[16:46] <API> that now seems to be called before unity plugin
[16:46] <API> gtk_init will load a11y modules
[16:46] <lamalex> ahh
[16:46] <API> that means that the atk-bridge would
[16:46] <API> be using
[16:46] <API> a wrong atk implementation for some methods
[16:47] <API> those envvars are a hack added to solve the same problem with firefox
[16:47] <lamalex> yah
[16:47] <lamalex> i remember this from when i was assigned to a11y
[16:47] <API> they just said to the bridge to not be loaded
[16:47] <didrocks> API: we can distro-patch compiz to set those env if we always need them
[16:47] <lamalex> so where is gtk_init now? it was moved into its own plugin but i thought that was cancelled
[16:48] <didrocks> in compiz
[16:48] <API> didrocks, so right now is compiz itself the one calling gtk_init?
[16:48] <didrocks> API: exactly
[16:48] <API> hmm, yes that was I fear
[16:48] <API> lamalex, yes I saw that gtkloader plugin
[16:48] <API> I also tried there but no luck
[16:48] <API> didrocks, but now compiz made a call to gtk_init?
[16:48] <API> it is a upstream change or just for unity sake?
[16:49] <lamalex> smspillaz, ^
[16:49] <didrocks> API: it's done for unity
[16:49] <didrocks> API: you have unity dep on a new plugin
[16:49] <didrocks> but compiz isn't able on upgrade to check dependencies
[16:49] <didrocks> and to load the new plugin
[16:49] <didrocks> so, it will just segfault…
[16:49] <didrocks> the call to gtk_init is just a hack until compiz can handle plugins properly…
[16:49] <API> didrocks, but this is a temporal workaround or other solution is planned?
[16:50] <API> that answer my question
[16:50] <didrocks> hopefully, we will be able to use the additional plugin for oneiric
[16:50] <didrocks> API: so, I can add them to compiz right now
[16:50] <API> didrocks, I can do that if you want
[16:50] <API> but as you see, it is just set those envvars
[16:51] <API> before gtk_init
[16:51] <didrocks> API: I'm doing the compiz update, so no worry, will do it ;)
[16:51] <lamalex> API, ok so im going to reject this proposal
[16:51] <lamalex> API, do you want me to review the focus branch?
[16:53] <API> lamalex, ok, yes reject that proposal
[16:53] <API> lamalex, yes please review that focus branch
[16:53] <API> sorry, it is really long
[16:53] <API> didrocks, so I need to assign that bug to compiz?
[16:53] <didrocks> API: yes please, compiz + assign to me, I'll do it with the update tomorrow
[16:53] <API> didrocks, https://bugs.launchpad.net/unity/+bug/810045
[16:55] <API> didrocks, if I search for compiz, the first item is 0.9.5, it is correcT?
[16:55] <didrocks> API: it is :)
[16:56] <API> didrocks, ok, done, you have now a new bug ;)
[16:56] <didrocks> API: heh, excellent, thanks ;)
[16:56] <API> didrocks, thanks to you
[16:57] <API> but definitively we need to find a way to manage multi-toolkit environments without nasty hacks
[16:58] <API> but that would required to wait for atk-3
[20:53] <htorque> hello everyone! is it unity or compiz that's responsible for restoring a window when double-clicking the top panel?
[21:01] <thumper> htorque: probably unity
[21:02] <htorque> thumper: thanks, that was my guess too.