[08:32] <MCR> duflu: Hi :) Haha, do you mean me, if you say: "even abusers of CCSM" ?
[08:33] <duflu> MCR: No, but there are plenty of people who break their systems with CCSM.
[08:34] <MCR> duflu: I tried to bring more structure to bug 1030473 and seperated the different warnings/potential errors, but I need advice on how to best act on those...
[08:34] <ubot5`> Launchpad bug 1030473 in Compiz "Error-reports cppcheck (http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Main_Page)" [Medium,In progress] https://launchpad.net/bugs/1030473
[08:34] <MCR> duflu: https://code.launchpad.net/~mc-return/compiz/compiz.fix1030473-part4/+merge/118409
[08:35] <duflu> MCR: I rejected that proposal. Please ignore it.
[08:35] <duflu> MCR: Please submit each type of fix separately
[08:37] <MCR> duflu: It would be nice if you could take a look at the different types and advice me how to/if to fix them.
[08:38] <duflu> MCR: Please submit each as a new bug and we can discuss them formally that way.
[08:40] <MCR> duflu: Maybe you are right and I should have done that in the first place, but at least we have reduced warnings to about 25% already.
[08:40] <duflu> MCR: Yes, it's good. But we have to have some discipline and formality to manage complexity. Otherwise everything becomes a mess.
[08:41] <MCR> duflu: Sure, I agree.
[08:41] <duflu> MCR: As always, one topic per bug please. And only one.
[08:41] <MCR> duflu: That is why I did the fix in parts and not all at once with a huge diff.
[08:42] <duflu> MCR: "per bug" means multiple bugs. Not multiple parts.
[08:42] <duflu> I got tired of being spammed with emails
[08:43] <MCR> duflu: ok, sorry - my intention was not to spam you, but to help with Compiz.
[08:43] <duflu> Although multiple emails is fine if each is a separate clearly defined bug. Otherwise there is no end.
[09:19] <MCR> duflu: Done. All issues separated into new individual bug reports. (Except for the field width specifiers, which we reject to fix if I understood you correctly)
[09:25] <duflu> MCR: Cool. Thanks
[09:32] <noob7> hello, I filed a wish on launchpad Bug #1026764  and was told to name the package. Can someone help me on the package?
[09:32] <ubot5`> Launchpad bug 1026764 in unity (Ubuntu) "Shortcut "Home|Ubuntu" disappears " [Undecided,Incomplete] https://launchpad.net/bugs/1026764
[09:33] <noob7> oh sorry it was the wrong package
[09:33] <noob7> *bug
[09:34] <noob7> Bug #1028392
[09:34] <ubot5`> Launchpad bug 1028392 in Ubuntu "shutdown shortcut " [Undecided,New] https://launchpad.net/bugs/1028392
[09:34] <noob7> that's the right one
[09:41] <noob7> or is the package just unity?
[09:45] <duflu> noob7: Fixed. I think... ?
[09:45] <noob7> whaaaaat?
[09:45] <noob7> that is awesome
[09:47] <MCR> duflu: np
[09:47] <noob7> thanks
[09:47] <duflu> noob7: Package status corrected. Not bug fixed :)
[09:47] <noob7> yes that's what I was thinking at first ;)
[09:47] <noob7> thanks
[09:48] <duflu> I could be wrong though.
[09:48] <noob7> should be better than nothing
[09:48] <MCR> noob7: You can add such a shortcut easily via CCSM.
[09:49] <noob7> yes I know there are "workarounds" but it would be nice having it there
[09:49] <noob7> just for noobs ;)
[09:50] <MCR> noob7: Try this: http://www.iloveubuntu.net/how-add-shutdown-restart-suspend-hibernate-ubuntu-1204s-dash-ppa-available
[09:53] <noob7> so you would hit metakey, type power, and then click on the power icon??
[09:54] <MCR> noob7: I use Synapse ;)
[09:55] <MCR> noob7: But you do not even need that - all you need is the CompizConfigSettingsManager.
[09:56] <MCR> noob7: There you have Commands, where you can take any shortcut you like and assign a comand to it, for example: sudo shutdown now -h
[09:57] <MCR> but afaik Ctrl+Alt+Del is used in Gnome to logout, so this is not available without removing this shortcut first
[09:58] <noob7> yes, you would just deactivate it in the shortcut menu and activate the shutdown/restart command
[09:58] <noob7> that's what I was thinking about
[09:58] <Zhenech> MCR, not in gnome3, its ctrl-alt-L there
[09:58] <Zhenech> ctrl-alt-del will try to shutdown/reboot
[09:59] <noob7> don't want to have a gnome3<->unity argument ;)
[09:59] <noob7> I'm used to gnome and try to get used to unity
[10:00] <noob7> tha's just my point of view
[10:00] <MCR> noob7: With the power commands I posted above you just get .desktop files for the respective actions, so you have starters for those (with Synapse this means Ctrl+Space, type sh, hit Return to shutdown here.)
[10:01] <MCR> Zhenech: It is a highly customized Unity-2d/Compiz environment here ;)
[10:01] <noob7> ;)
[10:02] <MCR> noob7: I recommend using CCSM for all your needs ;)
[10:02] <noob7> will have a look at this one thanks for the help
[10:03] <MCR> np
[12:29] <sil2100> Trevinho: hi
[12:30] <sil2100> Trevinho: I tried bisecting that Launcher problem with trunk...
[12:31] <sil2100> Trevinho: strange thing though - I'm using quantal bamf right now and unity revision 2500, and the bug is still there ;/
[13:00] <ayesh> hello
[13:00] <ayesh> anybody there?
[13:00] <sil2100> Hi
[13:01] <ayesh> this is from ubuntu staff?
[13:03] <sil2100> ayesh: what do you mean?
[13:09] <sil2100> jaytaoko: hi
[13:35] <jaytaoko> sil2100: hello
[13:42] <sil2100> jaytaoko: hello - did you get the e-mail from me about the launcher unity problems?
[13:43] <sil2100> jaytaoko: I'm currently trying to bisect my way to finding the problem, but the bug doesn't seem to be in unity or bamf ;/
[13:43] <jaytaoko> sil2100: not sure I saw that mail. when did you send it?
[13:44] <sil2100> Like around an hour ago
[13:44] <sil2100> Re: Fwd: unity-team/staging ppa launcher results
[13:44] <jaytaoko> sil2100: ok I have it
[13:45] <sil2100> jaytaoko: me and andyrock think it might be nux? But it doesn't make much sense... compiz also was probable
[13:45] <sil2100> jaytaoko: or maybe it's the commit that moved geis to nux
[13:45] <andyrock> jaytaoko, we tried with an old compiz and the problem is still here
[13:46] <andyrock> with an old bamf and the problem is still here
[13:46] <andyrock> i'm trying to revert nux to rev 633 now
[13:47] <andyrock> building unity without geis commits
[13:47] <jaytaoko> sil2100: so what is the problem exactly?
[13:47] <jaytaoko> sil2100: still reading...
[13:48] <sil2100> jaytaoko: the launcher does not correctly show the state of running applications, i.e. after starting a new application, a launcher icon does not appear - to make it appear, I have to switch to another workspace
[13:48] <sil2100> jaytaoko: same with pips of running apps and windows, or when closing an application
[13:49] <sil2100> That's on unity-team/staging and unity trunk
[13:53] <jaytaoko> sil2100: ok, my first impression this does not seems related to geis. No gesture is involved in reproducing the problem...
[13:55] <sil2100> jaytaoko: it seems to be something in nux
[13:55] <sil2100> andyrock just tested on an earlier revision
[13:55] <mhr3> sounds like a redraw issue
[13:57] <andyrock> mhr3, mmm no
[13:57] <andyrock> in bamflaunchericon.cpp i don't get the bamf signal
[13:58] <andyrock> "active-changed"
[14:00] <jaytaoko> sil2100: I am updating my system to check the issue
[14:00] <Zhenech> mhh, unity does not find .desktop files in /usr/local/share/applications?
[14:01] <jaytaoko> andyrock: are you receiving a signal that the application has started in bamf?
[14:04] <andyrock> i've tried with another signal "active-changed"
[14:04] <andyrock> nux rev 639 no problem
[14:04] <andyrock> nuv rev 640: i can reproduce the problem
[14:05] <andyrock> i'm going to double check
[14:06] <sil2100> \o/
[14:06] <sil2100> andyrock: excellent bisecting
[14:07] <andyrock> nux is stealing glib events :P
[14:08] <andyrock> but I'm not sure this is possible
[14:08] <andyrock> :)
[14:13] <sil2100> jaytaoko: could you take a look at it? As andyrock says, rev 640 seems to be the problem here
[14:14] <jaytaoko> sil2100: yes
[14:15] <sil2100> jaytaoko: thanks!
[14:32] <sil2100> andyrock: btw. you think the same was causing the panel issue?
[14:32] <andyrock> sil2100, yep and a lot of side effects
[14:33] <andyrock> click on spread not working
[14:33] <andyrock> etc,
[14:33] <sil2100> andyrock: woha, it's a big commit this 640, I could have waited with this one till after 6.2 release
[14:33] <sil2100> :(
[14:52] <jaytaoko> sil2100: andyrock: are there other issues related to that branch
[14:59] <sil2100> jaytaoko: ouch... well, yes, we noticed problems with the panel as well
[15:07] <sil2100> jaytaoko: ...can you fix it, or should we revert?
[15:08] <jaytaoko> sil2100: I fear if we revert, then we would have to revert other branches in Unity as well...
[15:08] <sil2100> jaytaoko: I know :( This is the problem, since unity has removed the gesture stuff too...
[15:09] <sil2100> But if there is more than one regression, the regression potential is big
[15:13] <jaytaoko> dandrader: do you think we can have a timely fix for this? ^
[15:15] <dandrader> jaytaoko,  no.
[15:16] <jaytaoko> dandrader: how much impact would this have on unity if we were to revert the branch in Nux?
[15:16] <dandrader> jaytaoko,  you have also to revert the corresponding patch in unity
[15:16] <sil2100> I think it's safer just to revert those
[15:17] <dandrader> and add a patch to make unity use libgeis instead of libutouch-geis, which should be a one-liner
[15:17] <jaytaoko> sil2100: dandrader: any features that were expected for this release?
[15:17] <dandrader> jaytaoko, ?
[15:18] <sil2100> jaytaoko: none really, just the introduced fixes - so that quantal can have more-or-less weekly unity
[15:18] <jaytaoko> dandrader: I mean, any bugs or requirement that were relying on geis in this release?
[15:18] <dandrader> the "alt-tab with gestures" patch
[15:18] <dandrader> that's currently sitting as a merge proposal. it builds on top of those patches
[15:21] <sil2100> Well, I would recommend to revert the nux and unity revisions and just add a merge to unity with renaming of utouch to geis
[15:35] <jaytaoko> sil2100: can we have a bit more time to try and fix this?
[15:35] <jaytaoko> dandrader: any candidate for investigation? I am going through WindowThread::Mainloop
[15:36] <dandrader> MainLoopGlib.cpp, WindoThread::ProcessEvents...
[15:37] <dandrader> couldn't reproduce the problem yet
[15:38] <Mirv> didrocks: hi. I verified the fix for bug #1032902 in compiz SRU. that means lp:~timo-jyrinki/compiz/precise_SRU-1 should be ready for pushing to precise-proposed. all other bugs in 1.3 release verification-done.
[15:38] <ubot5`> Launchpad bug 1032902 in compiz (Ubuntu Precise) "compiz 1:0.9.7.8-0ubuntu1.3 FTBFS in precise-proposed on armel, armhf" [Critical,Triaged] https://launchpad.net/bugs/1032902
[15:38] <Mirv> afk, though, but just in case it'd be ready already
[15:40] <sil2100> jaytaoko: hm, since my EOD is nearing, let's maybe do it like this - if you want, you can try fixing this up today
[15:40] <sil2100> If it will be not enough time, then I'll just revert the two revisions tomorrow in the morning
[15:40] <doctormon> didrocks: Hey, did you manage to check out the library link I sent you a few weeks ago?
[15:40] <jaytaoko> sil2100: understood
[15:40] <sil2100> But I would in _overall_ prefer to have a well tested trunk released
[15:41] <sil2100> ;)
[15:41] <sil2100> jaytaoko: good luck then! :)
[15:41] <didrocks> seb128: did you want to sponsor Mirv's compiz as you did upload the previous one?
[15:41] <didrocks> doctormon: quite quickly, but yeah, I looked over to it, I like it :)
[15:41] <seb128> didrocks, upload to where?
[15:42] <seb128> didrocks, we already have a version in the queue no? didn't you upload it during GUADEC?
[15:42] <jaytaoko> sil2100: thanks
[15:42] <seb128> didrocks, yeah, we have a version in proposed accepted 3 days ago
[15:43] <sil2100> seb128: didrocks means a new version
[15:44] <sil2100> seb128: since the previous one had a armel/armhf build problem which was fixed by Mirv
[15:44] <sil2100> Mirv: ^
[15:44] <doctormon> didrocks: It seemed to me that gtkme and quickly's python library are very similar in goals.
[15:44] <seb128> sil2100, oh ok, I can have a look tomorrow I guess
[15:44] <doctormon> are they a kin worth joining up?
[15:44] <sil2100> seb128: excellent, thanks!
[15:44] <seb128> not today, I'm fighting with a zillion things
[15:45] <seb128> trying to do some +1 work, while looking a desktop workitems, some GNOME updates and some other build issues on the side
[15:48] <didrocks> seb128: hum, seems that Mirv pointed to a link showing it FTBFS
[15:49] <didrocks> doctormon: indeed, it seems to me you are making project similar to Quickly :)
[15:49] <seb128> didrocks, sorry my todolist for the end of day is like 5 hours worth of work still long and keep increasing, I'm not following IRC out of highlights ;-)
[15:49] <didrocks> no worry ;)
[15:50] <seb128> will have a look to the log later or tomorrow
[15:50] <didrocks> no worry
[15:50]  * didrocks continues writing
[15:52] <doctormon> didrocks: not all the deployment work though and gtkme has been around since 2009, I noticed only at the showdown how similar it was.
[16:17] <jaytaoko> andyrock: ping
[16:19] <andyrock> jaytaoko, pong
[16:19] <jaytaoko> andyrock: I can reproduce some issues here but I fail to see the relation with the geis branch in nux... so I need to ask a few questions
[16:20] <andyrock> i fail to see the relation too, but reverting that commit fixs the issue :/
[16:21] <jaytaoko> andyrock: so, I don't have totem pinned in my launcher. I open the dash and start Totem. Totem starts but then its icon does not show up in the launcher... how?
[16:22] <jaytaoko> andyrock: I understand the relationship to the geis branch but we need to dig deeper
[16:23] <jaytaoko> andyrock: so I wonder, is the icon being added to the launcher?
[16:23] <andyrock> jaytaoko, is the icon being added to the launcher? i think not
[16:24] <andyrock> because i think we don't receive the bamf signals
[16:24] <andyrock> have you already checked?
[16:24] <jaytaoko> andyrock: I mean if the icon is not being added to the launcher then something is not receiving a signal that the application has started
[16:25] <andyrock> jaytaoko, yeah... bamf should emit the signal
[16:25] <jaytaoko> andyrock: ok, so the bamf signal is not received... but still the application starts... can you show me the signal that bamf expects?
[16:25] <andyrock> hang on
[16:27] <andyrock> jaytaoko, view-opened
[16:27] <andyrock> LauncherController.cpp
[16:27] <jaytaoko> andyrock: that is the signal that bamf is waiting for?
[16:27] <andyrock> grep for view-opened
[16:27] <andyrock> no that's is the signal unity is waiting for
[16:28] <bschaefer> andyrock, jaytaoko hello, I also just started looking at this...there are also some other signals in BamfLauncherIcon....
[16:29] <bschaefer> andyrock, im checking the view opened right now
[16:29] <jaytaoko> bschaefer: hello and welcome to the party!
[16:29] <sil2100> I see now that the issue is in good hands: 3 devs working on it, we cannot fail ;)
[16:29] <bschaefer> :)
[16:29] <bschaefer> jaytaoko, hello!
[16:29] <andyrock> we miss Trevinho :(
[16:29] <bschaefer> andyrock, no the ViewOpen signal is not getting sent
[16:29] <andyrock> the BamfLauncherIcon king
[16:29] <sil2100> I keep my fingers crossed that you'll somehow be able to figure this out guys!
[16:29] <bschaefer> but Active Changed
[16:29] <bschaefer> is
[16:29] <sil2100> See you tomorrow
[16:30] <andyrock> sil2100, see ya
[16:30] <bschaefer> see you sil2100 !
[16:30] <andyrock> bschaefer, can you try to revert rev 640 (nux)
[16:30] <andyrock> '
[16:30] <andyrock> ?
[16:30] <bschaefer> andyrock, yup ill give that a try
[16:30] <jaytaoko> andyrock: bschaefer: you are all on Q right?
[16:31] <andyrock> jaytaoko, no on P
[16:31] <bschaefer> yup!
[16:31] <bschaefer> I just upgrade last night....
[16:31] <jaytaoko> andyrock: on P? and you have that issue?
[16:32] <bschaefer> andyrock, did you compile libgeis your self?
[16:32] <jaytaoko> andyrock: on P, we deactivate geis in Nux because there is no libgeis on P
[16:32] <andyrock> jaytaoko, yeah i have unity trunk + nux trunk
[16:32] <andyrock> bschaefer, JanC yep
[16:32] <andyrock> JanC, sorry
[16:32] <bschaefer> andyrock, haha I almost did that!
[16:32] <andyrock> i built libgeis
[16:33] <jaytaoko> andyrock: ok
[16:33] <bschaefer> dam autogen
[16:33] <jaytaoko> andyrock: ok, it is still interesting to know that it happens on P with your setting
[16:34] <andyrock> i can confirm that i don't get the view-opened signal
[16:34] <bschaefer> andyrock, with nux rev 640?
[16:35] <andyrock> bschaefer, i've nux trunk now so yes i've rev640 too :)
[16:35] <bschaefer> andyrock, :), well if it fails at 640 ill drop that and drop the geis support in unity and see if thats the problem
[16:36] <bschaefer> as I haven't updated bamf since the problem started so I don't think it is a problem in Bamf
[16:36] <andyrock> doing bzr revert -r 639
[16:36] <andyrock> i cannot reproduce these issues :)
[16:36] <bschaefer> awesome!
[16:36] <bschaefer> soo geis is the problem or the changes that came with geis in nux hmm
[16:37] <jaytaoko> andyrock: understood
[16:37] <andyrock> bschaefer, but rev640 is huge and it's not so easy to understand the relationship
[16:37] <andyrock> jaytaoko, we should try to see if bamf emit that signal
[16:37] <jaytaoko> andyrock: bschaefer: I am tracing back view_opened_signal_...
[16:38] <bschaefer> andyrock, yeeah, well Ill start trying to split up the changes and slowly add them until it fails
[16:39] <andyrock> bschaefer, good luck :P
[16:39]  * bschaefer hasn't looked at the diff yet...
[16:39] <andyrock> bschaefer, make a picture to your face when you see the diff :)
[16:40] <bschaefer> andyrock, haha...well I already made it when I did a bzr revert from 640 -> 639...
[16:41] <jaytaoko> andyrock: bamf will match view-opened with Impl::OnViewOpened. is that right?
[16:41] <andyrock> jaytaoko, yep
[16:42] <jaytaoko> andyrock: who emits "view-opened" signal?
[16:42] <andyrock> bamf
[16:42] <bschaefer> o my....
[16:42] <bschaefer> that is a large diff
[16:43] <andyrock> jaytaoko, i'm checking if that signal is emitted ;)
[16:43] <jaytaoko> andyrock: ok, i am checking as well...
[16:48] <jaytaoko> andyrock: I opened the dash and clicked on Totem... The OnViewOpened signal is not emitted. I instrumented the code source to check that it prints something if it is emitted...
[16:49] <jaytaoko> andyrock: and so totem does not show up in the launcher
[16:50] <andyrock> yep i can confirm
[16:52] <bschaefer> i can also
[16:52] <bschaefer> hmm im missing 'libutouch-geis' ... that is annoying
[16:52] <bschaefer> when Im trying to compile unity before the geis update, must be something on P not on Q
[16:53] <dandrader> bschaefer, you need libgeis, not libutouch-geis.
[16:53] <bschaefer> dandrader, yes, for after the geis update
[16:54] <bschaefer> dandrader, I was trying to revert back before the libgeis change (which is on Q)
[16:54] <mhr3> sounds like real fun issue
[16:55] <mhr3> starving of mainloop, or some worker thread?
[16:55] <mhr3> which would sound reasonable, cause when i switch workspaces, the bamf events are "replayed" rapidly
[16:55] <jaytaoko> andyrock: ok, we know that the dash is getting the mouse click signal when we click on the totem icon in the dash
[16:56] <jaytaoko> andyrock: I am checking ResultViewGrid::MouseClick
[16:56] <bschaefer> mhr3, yeah, the Bamf signals for active are still going off, so Bamf is doing something
[16:57] <jaytaoko> mhr3: very interesting observation. I can confirm.
[16:58] <jaytaoko> mhr3: when I switch to another desktop and come back then the icon shows up in the launcher
[16:58] <jaytaoko> andyrock: can you check this ^
[16:58] <andyrock> confirmed
[16:58] <mhr3> now to *just* figure out who causes the starvation :)
[17:00] <jaytaoko> mhr3: andyrock: ok that is interesting
[17:02] <mhr3> so it'll be either a GSource with high priority or it could also be a worker thread blocked by some mutex that gets unlocked from time to time
[17:02] <bschaefer> mhr3, are you talking about starvation of an event? I thought they used queues!
[17:02] <bschaefer> or at lease some way to prevent that of events in a main loop...
[17:02] <andyrock> jaytaoko, mhr3, bschaefer  if (IsEmbeddedWindow())
[17:02] <andyrock>      geis_adapter_->CreateGSource(nullptr);
[17:03] <mhr3> i'm sure the geis would know :)
[17:03] <andyrock> commented that line seems to fix the issue
[17:03] <mhr3> geis people*
[17:03] <mhr3> heh, nice andyrock
[17:03] <jaytaoko> andyrock: what line is this?
[17:03] <andyrock> MainGlibLoop.cpp
[17:03] <bschaefer> andyrock, awesome! As soon as I get back from my trash system atm haha
[17:03] <bschaefer> ill confirm that as well :)
[17:04] <andyrock> line 270
[17:04] <jaytaoko> andyrock: I see it...
[17:05] <jaytaoko> andyrock: ok in this case we IsEmbeddedWindow is true
[17:05] <jaytaoko> andyrock: because we are running Nux inside Compiz
[17:05] <andyrock> yeah i know
[17:06] <bschaefer> andyrock, jaytaoko confirmed that fixed the problem...
[17:06] <jaytaoko> dandrader: can you have a look at WindowThread::RunGlibLoop in Nux/MainLoopGlib.cpp
[17:07] <jaytaoko> bschaefer: thanks!
[17:07] <bschaefer> andyrock, nice find :)
[17:07] <andyrock> eheh but we not found the real problem :)
[17:08] <jaytaoko> dandrader: around line 270... is there something there?
[17:08] <bschaefer> andyrock, yeah, but that diff...
[17:08] <bschaefer> is smaller
[17:08] <andyrock> LOL
[17:14] <dandrader> hmm...
[17:18] <jaytaoko> dandrader: any idea why it could affect?
[17:21] <andyrock> maybe that gsource prevent the main context to dispatch the events of other sources
[17:21] <andyrock> *prevents
[17:21] <andyrock> but I'm not a GSource expert :)
[17:26] <bschaefer> andyrock, hmm can you uncomment the line and re confirm its broken?
[17:26] <bschaefer> andyrock, i uncommented that back in and now things are working...(unless I broke my unity/nux build haha)
[17:27] <andyrock> i have just uncommented that code
[17:27] <andyrock> and i can reproduce the issues
[17:27] <bschaefer> hmm what did I do...haha...
[17:27] <bschaefer> thanks!
[17:28] <dandrader> well, maybe I could make GeisAdapter share the existing gsource (as the TODO comment says) to see if the problem goes away. unfortunately I still cannot reproduce that issue in my test machine. the dash shows nothing when I run the unity I built myself
[17:30] <bschaefer> dandrader, oo thats because you need to add a link to the lenses to where you built unity
[17:30] <dandrader> I did it, still no luck.
[17:30] <dandrader> maybe I did it in the wronge dir....
[17:31] <bschaefer> o really? hmm it should be /usr/share/unity/lenses/
[17:31] <bschaefer> worst case andyrock or I could build and test your changes
[17:32] <bschaefer> or jaytaoko :)
[17:32] <andyrock> dandrader, i'm going to add a mutex
[17:32] <andyrock> in the check function
[17:33] <andyrock> dandrader, to reproduce the problem
[17:33] <andyrock> just un-pin the gedit launcher icon
[17:33] <andyrock> open gedit using the terminal
[17:33] <andyrock> see if the gedit icon is on the launcher
[17:34] <dandrader> the icon is there
[17:34] <dandrader> I have an up to date quantal with trunk versions of unity, compiz and nux
[17:35] <dandrader> and a non-functioning dash :)
[17:35] <dandrader> andyrock, what check function?
[17:37] <bschaefer> dandrader, like 270 in MainLoopGlib.cpp (Im guessing)
[17:38] <andyrock> geis_source_check
[17:38] <andyrock> geis_source_prepare etc
[17:38] <andyrock> but it doesn't help :)
[17:39] <mhr3> i think the prepare function is wrong
[17:40] <mhr3> it should return TRUE if the revents contains IO_IN
[17:40] <mhr3> basically the same thing the check func does
[17:41] <mhr3> (talking about geis_source_prepare)
[17:43] <andyrock> mhr3, http://paste.ubuntu.com/1134651/
[17:43] <andyrock> i think we you should return TRUE if there are pending geis events
[17:43] <andyrock> or i'm wrong?
[17:44] <mhr3> andyrock, that's what it does, right :)
[17:45] <jaytaoko> dandrader: I can test any solution you have since I can reproduce the problem...
[17:45] <dandrader> mhr3, you likely pinpointed the problem. when I wrote the prepare function I just followed what written here http://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#GSourceFuncs
[17:46] <jaytaoko|lunch> mhr3: nice catch!
[17:47] <jaytaoko|lunch> I hope we can all confirm this is the issue
[17:49] <mhr3> dandrader, i just tested http://paste.ubuntu.com/1134656/ it didn't fix it
[17:50] <dandrader> :(
[17:51] <mhr3> dandrader, do you read all the data from the source?
[17:51] <mhr3> if you don't, it'll be just dispatching the same source over and over
[17:51] <dandrader> mhr3, in the dispatch function?
[17:51] <mhr3> yes
[17:52] <dandrader> GeisAdapter::ProcessGeisEvents() is the one doing it
[17:52] <andyrock> mhr3, making _check always returning FALSE fix the problem here
[17:53] <andyrock> but it's not a fix :)
[17:53] <dandrader> it should be doing so
[17:53] <dandrader> mhr3 ^
[17:53] <andyrock> http://paste.ubuntu.com/1134651/
[17:53] <mhr3> dandrader, perhaps there's a race where it doesn't?
[18:15] <sbte> tedg, hi, are there any gtk3 python bindings for libindicate-gtk (the set_property_icon method)?
[18:34] <mhr3> dandrader|lunch, from what i see, geis_next_event is always returning EMPTY_EVENT, yet the fd is triggered pretty much all the time
[18:34] <mhr3> weird
[18:45] <andyrock> dandrader, in   gboolean geis_source_dispatch(GSource *source, GSourceFunc  callback, gpointer user_data)
[18:46] <andyrock> you don't call the callback...
[18:46] <andyrock> ;/
[18:46] <andyrock> why?
[18:48] <dandrader> andyrock, if I'm not mistaken it's because I didn't supply any callback
[18:48] <dandrader> but let me check
[18:49] <jaytaoko> andyrock: mhr3: anything you want me to try?
[18:51] <dandrader> andyrock,  GeisAdapter.cpp:138 - g_source_set_callback(source, 0, this, 0);
[18:51] <andyrock> mmm ok
[18:53] <dandrader> mhr3, in the very beginning there should be a couple of events
[18:53] <dandrader> during initialization
[18:54] <dandrader> mhr3, at the very least a GEIS_EVENT_INIT_COMPLETE event should come
[18:54] <mhr3> dandrader, ok, it probably did, but why is the fd still being triggered afterwards?
[18:55] <dandrader> yeah, it shouldn't
[18:55] <mhr3> seems like it's watching an X fd
[18:55] <mhr3> that's what's being triggered
[18:56] <dandrader> geis itself, internally, has an X display opened and thus listens to some x events
[18:57] <mhr3> somehow there's a loopback so to say
[18:57] <mhr3> anyway, i had eod like 3 hours ago, /me out
[18:59] <dandrader> mhr3, ok, thanks for the help
[18:59] <cnd> dandrader: so the geis fd remains "readable", even though there's no event to read?
[19:00] <andyrock> I'm out too...
[19:00] <andyrock> bye bye
[19:00] <dandrader> bye
[19:00] <dandrader> cnd, seems so. I couldn't reproduce the issue myself
[19:00] <cnd> hmm
[19:01] <cnd> I'll take a look at the code to see if anything stands out to me
[19:02] <mhr3> before i go, 35 was the x event type ;)
[19:03] <mhr3> maybe that helps
[19:03] <mhr3> maybe not
[19:05] <dandrader> ok, thanks
[19:19] <cnd> dandrader: mhr3: X event 35 is a generic event
[19:19] <cnd> XInput 2.x events are the only generic events so far
[19:19] <cnd> thus, it probably is a touch event
[19:20] <dandrader> cnd,  maybe a timer event?
[19:20] <tedg> sbte, There should be through the gobject-introspection bindings.
[19:21] <dandrader> I wonder if the reason I don't get this bug in my test machine is because it has multitouch devices, thus making geis behave and initialize differently...
[19:26] <dandrader> nah, I still cannot reproduce it in my other box
[19:26] <sbte> tedg, any idea what the indicate-gtk module is called then?
[19:27] <sbte> from gi.repository import Indicate doesn't work for the set_property_icon method
[19:28] <tedg> sbte, Should be IndicateGtk3 I think.
[19:31] <sbte> tedg, doesn't seem to work
[19:31] <sbte> [21:30:30 ERROR root] Could not find any typelib for IndicateGtk3
[19:33] <tedg> Hmm, doesn't seem to be in the dev package.  kenvandine, do you know why the GIR file for libindicate GTK3 isn't in the -dev package?
[19:34] <kenvandine> tedg, not off hand...
[19:34] <kenvandine> but sbte's error was missing typelib
[19:35] <sbte> kenvandine, >>> from gi.repository import blagh
[19:35] <sbte> ERROR:root:Could not find any typelib for blagh
[19:36] <sbte> kenvandine, it just means it's nonexistent
[19:38] <kenvandine> tedg, oh... i think we couldn't generate GIR for libindicate-gtk at all
[19:38] <kenvandine> remember the namespace issue?
[19:38] <tedg> kenvandine, I thought we fixed that.... that was one of the API breakages you bitch about :-)
[19:38] <tedg> kenvandine, I have one in my build directory, just not in the package.
[19:42] <seb128> tedg, kenvandine: we just don't install the files in any binaries it seems
[19:42] <kenvandine> tedg, maybe you fixed it and we never fixed the package
[19:43] <seb128> got bitten by not using dh_install --list-missing
[19:43] <kenvandine> :)
[19:43] <kenvandine> --fail-missing FTW
[19:43] <seb128> indeed!
[19:44] <seb128> kenvandine, you can blame ted though
[19:44] <seb128> be did the package updates for those versions
[19:44] <kenvandine> everything is tedg's fault
[19:44] <kenvandine> :-p
[19:44] <seb128> well, first if the name was not that confusing...
[19:44]  * kenvandine has missed picking on tedg this cycle
[19:44] <seb128> is libindicate the one going away?
[19:44] <seb128> or is it libindicator?
[19:44] <kenvandine> yes
[19:44] <kenvandine> libindicate
[19:45] <tedg> Heh, no worries.  And libindicator has no GIR support ;-)
[19:45] <kenvandine> it wouldn't be useful for libindicator right?
[19:45] <tedg> Naw, I don't think it would be.
[19:45] <kenvandine> i think we've discussed that before
[19:45] <tedg> It'd probably only be useful for validating the gtk-doc comments :-)
[19:51] <cnd> dandrader: a timer event would be a normal, non-generic event
[19:51] <cnd> so it would have a different number than 35
[19:51] <cnd> IIRC
[19:51] <dandrader> ok
[19:55] <cnd> yep, it's not an extension type
[19:57] <cnd> it's hard to see what could be going wrong
[19:57] <cnd> dandrader: is it mainly andyrock and mhr3 who see the issue?
[19:57] <cnd> perhaps we can have a group debug session tomorrow to try to figure out what's really happening
[19:58] <dandrader> quite a few are people getting it. I seem to be the lucky one
[19:59] <cnd> dandrader: is it available in a ppa?
[19:59] <cnd> or do I need to manually build it in order to test?
[20:00] <dandrader> cnd, I don't know. jaytaoko: do you?
[20:02] <jaytaoko> cnd dandrader: I compiled nux and unity trunk on a quanta machine.
[20:03] <cnd> jaytaoko: there isn't a daily ppa I could install instead?
[20:03] <jaytaoko> cnd dandrader: then I had to resolve the lenses issue in the dash, and I could see the problem
[20:03] <cnd> I don't like compiling and installing unity because of the compiz plugin mess :(
[20:03] <jaytaoko> cnd: you could try the unity staging ppa
[20:03] <cnd> ok
[20:39] <dandrader> jaytaoko, could you please try out this branch? lp:~dandrader/nux/geis_source
[20:39] <dandrader> I'm creating the GSource for GeisAdapter differently there. fingers crossed :)
[20:40] <cnd> I added ppa:unity-team/staging and dist-upgraded, but now X comes up blank :(
[20:42] <cnd> I'm trying to downgrade off the ppa to see if that is the issue, but it's more difficult than it used to be
[21:46] <cjohnston> me4oslav: ping
[21:47] <me4oslav> cjohnston Aha!
[22:02] <sbte> tedg, so I won't be able to use set_property_icon in gtk3?
[22:04] <tedg> sbte, Well, that's a harder question, and I'm about to run out.
[22:05] <tedg> sbte, I'm not sure if a packaging change can get an SRU in 12.04
[22:05] <tedg> sbte, But it should definitely be fixable in 12.10
[22:05] <tedg> Sorry, I was really logging off :-)
[22:05] <sbte> tedg, me too