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