[14:15] <tvoss> made grail green again, answered comments on omgubuntu and youtube, (self-)reviews, investigated test-failures for evemu
[14:16] <dandrader> investigating why I'm getting a half-second or so of silence (i.e. no events coming) at the beginning of a 4 fingers' gesture
[14:18] <bregma> making good progress on #944822
[14:19] <bregma> tvoss, it looks like eemu tests are failing because they require root privs
[14:19] <bregma> s/eemu/evemu/ not a large flughtless bird
[14:19] <tvoss> bregma, considered that as well, but apparently, the device /dev/input/event10 is not present in the vm's
[14:20] <tvoss> bregma, checked that the tests are executed with root privs
[14:20] <tvoss> bregma, do you know if it's okay to switch to /dev/input/event0, it's only a construction test for class Device
[14:20] <bregma> does the kernel in the VM not support the required functionality perhaps (would not be the first time)?
[14:21] <tvoss> bregma, in general, it does. All other tests do pass and all other projects relying on evemu use that functionality as well
[14:21] <cnd> I'm working on the last remaining bugs in unity gestures
[14:21] <cnd> and then any miscellaneous fixes I can manage across the stack
[14:22] <cnd> preparing some packages like xorg-server for the archive opening up tomorrow
[14:22] <cnd> bregma, tvoss: what's going wrong?
[14:23] <bregma> tvoss, yeah, it looks like event10 was chosen at random ny Duncan when he wrote the test, it can probably be changed to event0
[14:23] <bregma> cnd, there is an evemu test case that fails on a non-existent device
[14:23] <cnd> ahh
[14:23] <bregma> it's just a poorly constructed test case
[14:24] <cnd> that reminds me, we need to add device properties to evemu
[14:24] <cnd> I'll open a bug and maybe get to it today
[14:24] <tvoss> http://pastebin.ubuntu.com/903964/
[14:24] <cnd> otherwise we won't be able to replicate buttonpad devices properly
[14:24] <bregma> I think that functionality will have to wait for Q
[14:25] <cnd> bregma, we can apply it to trunk and ask people to use our ppa when necessary
[14:26] <bregma> sure, no problem, but we should probably consider the released version of evemu frozed:  I should branch the packaging today
[14:26] <bregma> um, frozed was a typo but I like that word, I think I;ll keep it
[14:27] <bregma> there's a bunch of evemu refactoring I'd like to do but it's low priority
[14:28] <bregma> cnd, are you going to do #966367 (grail FTBFS in PPA) or should I MR what I did yesterday?
[14:29] <cnd> bregma, I've already proposed it
[14:29] <cnd> just waiting for someone to review
[14:30] <bregma> oops, missed that -- I seem to be having weird trouble with mail a lot lately
[14:30] <bregma> I especially hate when I send mail and it doesn't actually get sent
[14:31] <tvoss> bregma, same here
[14:31] <bregma> must be a bug in thunderbird, it happens mostly with "reply to list", but also with replying to Debian bugs (which is serious, because that's how Debian handles bugs)
[14:32] <cnd> I can't wait for the switch to gmail
[14:32] <bregma> tvoss, will you fix the evemu test case?
[14:32] <cnd> tvoss, oops, I meant googlemail
[14:32] <cnd> :)
[14:33] <tvoss> cnd, indeed :)
[14:33] <tvoss> bregma, ack
[14:33] <bregma> yeah, I really dislike g*mail but it's sounding better lately
[14:33] <bregma> especially with launchpad working better with gmail than with canonical mail servers
[14:33] <cnd> I personally really like gmail for personal mail, I hope I like it for work mail too
[14:34] <cnd> but I won't be 100% sure until I can try it
[14:35] <bregma> I just want to do code reviews and bug administration through mail instead of a browser without having taste like @$$
[14:35] <cnd> heh
[14:36] <tvoss> bregma, just scheduled a one-shot build for my branch, if it passes, I'm going to mp it
[14:37] <bregma> so, are we on track to do a release of the stack (evemu/frame/grail) tomorrow?
[14:41] <cnd> bregma, I think so
[14:41] <cnd> bregma, tvoss, dandrader: btw, if you can't get 4 touch drag to show/hide the launcher, there are two options you need to check
[14:42] <cnd> in the system settings -> appearances -> behavior, ensure that Auto-hide the launcher is on
[14:42] <tvoss> ah
[14:42] <cnd> if it's greyed out, then you need to open up ccsm, find the unity compiz plugin, go to the behavior tab, and ensure "Hide Launcher" is set to "Autohide"
[14:43] <cnd> the dock then hides/unhides properly as you are dragging
[14:43] <cnd> sometimes when you lift your fingers it reverts back
[14:43] <cnd> so I need to find out why
[14:44] <cnd> but otherwise it's nice and smooth
[14:45] <tvoss> cnd, thanks
[14:45]  * tvoss waits for unity-2d-daily to finish compiling
[14:48] <cnd> aha, so the last update event sometimes has a huge position delta
[15:12] <cnd> bregma, got one more geis bug
[15:12] <cnd> the position delta attribute value is calculated incorrectly, and it manifests when the number of touches changes
[15:16] <cnd> note to self: don't edit shared events from your phone
[15:16] <bregma> OK
[15:17] <bregma> is the fix straighforward?  It should probably get int to 2.2.8 if possible.
[15:19] <cnd> yes
[15:19] <cnd> very
[15:19] <cnd> bregma, http://paste.ubuntu.com/904046/
[15:20] <cnd> I have just confirmed it fixes the launcher hide/unhide reverting at the end of a gesture
[15:20] <cnd> and I believe it fixes windows warping oddly at the end of a three touch gesture too
[15:20] <cnd> I just need to make a test for it
[15:21] <cnd> it also seems to adjust the window movement speed to be more correct too
[15:21] <cnd> though I don't know exactly why that is
[15:25] <tvoss> bregma, do you remember my branch for fixing the format error in geis on i386?
[15:26] <bregma> vaguely
[15:27] <bregma> the one where we didn;t know why it wasn't failing
[15:29] <dandrader> cnd, when you call XSyncAwait() you not receive any events until the wait condition is met, right?
[15:29] <dandrader> s/you not/you will not
[15:30] <tvoss> bregma, ack
[15:30] <tvoss> bregma, would you mind merging it? we can have utouch all green then :)
[15:31] <cnd> dandrader, no, you can receive events
[15:31] <cnd> I think
[15:31] <cnd> I seem to be able to
[15:31] <dandrader> That's not happens in my box
[15:31] <dandrader> it seems
[15:31] <cnd> dandrader, interesting
[15:32] <cnd> dandrader, I think it will require some heavy-duty debugging to figure out :(
[15:32] <dandrader> and that's also what I understood from www.xfree86.org/current/synclib.pdf
[15:32] <cnd> it could be that the events are waiting on the X fd, but the fd isn't being set as readable
[15:33] <cnd> hmm...
[15:33] <cnd> then why is it working for me...
[15:33] <dandrader> cnd, that's where the pause I'm getting comes from
[15:33] <cnd> ok
[15:34] <cnd> I wish the sync extension were better documented
[15:34] <cnd> and way better coded
[15:34] <cnd> it's really awful
[15:36] <cnd> dandrader, can you find anything in the sync extension that would work the way we want it to?
[15:37] <dandrader> "The mechanism used by this extension for synchronization within the X server
[15:37] <dandrader> is to block the processing of requests from a client until a specific
[15:37] <dandrader> synchronization condition occurs.
[15:37] <dandrader> "
[15:37] <dandrader> that "block the processing" part scares me a bit
[15:37] <cnd> dandrader, actually, it looks to me like it shouldn't block
[15:37] <cnd> simply because it's called *a*wait
[15:38] <cnd> "The await is
[15:38] <cnd> processed asynchronously by the server"
[15:39] <cnd> dandrader, can you try switching it from an await to an alarm?
[15:39] <cnd> I honestly don't know what the difference between the two is
[15:39] <cnd> maybe the alarm won't block events?
[15:40] <dandrader> sure, I'll check it
[15:40] <cnd> biab
[15:40] <cnd> dandrader, while you're at it, try using XSyncPositiveTransition instead of XSyncPositiveComparison
[15:41] <cnd> I think I may have it wrong in the code and we are getting extra events we don't need
[15:42] <bregma> tvoss, merged, kick off a test build if you feel the need to see green
[15:42] <tvoss> bregma, thanks ... green is hope ;)
[15:48] <dandrader> "The extension provides an Alarm mechanism that allows clients to receive an
[15:48] <dandrader> event on a regular basis when a particular counter is changed."
[15:48] <dandrader> looks like that's what we want indeed
[15:52] <tvoss> bregma, build fails with a missing header file: http://pastebin.ubuntu.com/904102/
[16:02] <bregma> tvoss, fixing....
[16:02] <tvoss> bregma, thanks
[16:10] <bregma> tvoss, I pushed up a fix but most tests are disabled in the packaging builds so I can't guarantee you won't get other errors, go ahead and give it another try
[16:20] <cnd> tvoss, are there plans to move our jenkins work to qa.ubuntu.com?
[17:23] <cnd> bregma, how's bug 944822 coming?
[17:23] <cnd> I'm hitting it in my testcase for the position delta bug :)
[17:32] <bregma> I'm working on it... you don't need to hit it, since your test case can create devices in advance of creating a geis instance, like other test cases do
[17:33] <tvoss> bregma, scheduled a rebuild
[17:34] <bregma> peachy, we'll just wee what we shall see
[17:35] <bregma> I hate it when I write a test case and it fails and I spend a lot of time going through my code, only to realize the test case was wrong not my code
[17:38] <cnd> bregma, I can do that, but it means I have to have multiple test fixtures
[17:38] <cnd> or override the SetUp() function...
[17:39] <cnd> but it's easier, and I think cleaner, if we can instantiate the device in the test body
[17:39] <cnd> if you'll be done soon, I can just wait
[17:39] <cnd> if not, I'll override the SetUp() method
[17:42] <tvoss> bregma, geis is green again
[17:52] <cnd> actually, even overriding SetUp() won't work unless we begin using value-parameterized tests, which isn't really what they are intended for
[19:54] <cnd> dandrader, any luck with the sync extension?
[19:55] <dandrader> cnd, yes
[19:55] <dandrader> alarms work alright
[19:55] <cnd> dandrader, great :)
[19:55] <dandrader> although XSyncPositiveTransition doesn't work
[19:55] <cnd> oh well
[19:56] <dandrader> I've to create an alarm tiwh XSyncPositiveComparison and then delete it when I first get an alarm notifitation from it
[19:56] <dandrader> but actually that logic would be the same for the *Transition case.
[19:57] <dandrader> gotta submit a bug report now...
[19:58] <cnd> dandrader, sounds good
[19:58] <cnd> I'm still curious why it works here and not on your computer
[19:58] <cnd> oh well
[19:59] <dandrader> "works for me"(tm)
[21:16] <dandrader> Why is utouch-geis implemented all in C (as opposed to C++, like in utouch-frame and utouch-grail)?
[21:20] <bregma> some of the target applications are not written in C (eg. GTK) and are less likely to use a library that pulls in the whole C++ runtime
[21:20] <bregma> C is the lowest common denominator for most things, C++ is not compatible with many things
[21:21] <bregma> C can provide a stable ABI across compilers, C++ can't
[21:22] <bregma> of course, now that tgrail and friends were rewritten in C++, the pulling-in-the-whole-runtime is shot to heck
[21:36] <cnd> bregma, yeah, though that's supposed to be temporary
[21:36] <cnd> we just need to get the dbus backend finished
[21:36] <cnd> and make the backends into plugins
[21:37] <cnd> however, the need for that has diminished since the core gtk developers have said they are ok with a c++ runtime dependency
[21:37] <cnd> as long as the api is c
[21:39] <dandrader> I'm missing the std goodies... Where to go for a hash table now?
[21:40] <dandrader> but we do have a geis_bag :)
[21:43] <cnd> dandrader, make one?
[21:43] <cnd> dandrader, we could also use glib, but we were concerned about it's support across platforms
[21:44] <cnd> for example, on windows
[21:44] <cnd> by sticking with straight C and C++, we have a stack that *should* be cross-platform in nature, and does not bring in unwanted dependencies
[21:45] <cnd> bregma, I've proposed the fix for the delta position
[21:46] <cnd> I realized that since the gtest_attr tests all use the same device, we can work around bug 944822 for now
[21:57] <bregma> dandrader, geis_bag is the only generic container in geis, given the nature of most data in geis anything else would be overkill (without a good standard library)
[21:58] <bregma> there are many times I missed my standard library when writinggeis
[21:59] <bregma> cnd, I'll try to review your MRs later today
[21:59] <cnd> bregma, sounds good :)
[22:00] <dandrader> bregma, I feel your pain
[22:00] <dandrader> rewriting standard stuff such as containers is far from motivating indeed
[22:01] <dandrader> well. time's up for me