=== MacSlow is now known as MacSlow|lunch | ||
=== MacSlow|lunch is now known as MacSlow | ||
tvoss | made grail green again, answered comments on omgubuntu and youtube, (self-)reviews, investigated test-failures for evemu | 14:15 |
---|---|---|
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:16 |
bregma | making good progress on #944822 | 14:18 |
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:19 |
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:20 |
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:21 |
cnd | preparing some packages like xorg-server for the archive opening up tomorrow | 14:22 |
cnd | bregma, tvoss: what's going wrong? | 14:22 |
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:23 |
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:24 |
cnd | bregma, we can apply it to trunk and ask people to use our ppa when necessary | 14:25 |
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:26 |
bregma | there's a bunch of evemu refactoring I'd like to do but it's low priority | 14:27 |
bregma | cnd, are you going to do #966367 (grail FTBFS in PPA) or should I MR what I did yesterday? | 14:28 |
cnd | bregma, I've already proposed it | 14:29 |
cnd | just waiting for someone to review | 14:29 |
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:30 |
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:31 |
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:32 |
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:33 |
cnd | but I won't be 100% sure until I can try it | 14:34 |
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:35 |
tvoss | bregma, just scheduled a one-shot build for my branch, if it passes, I'm going to mp it | 14:36 |
bregma | so, are we on track to do a release of the stack (evemu/frame/grail) tomorrow? | 14:37 |
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:41 |
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:42 |
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:43 |
cnd | but otherwise it's nice and smooth | 14:44 |
tvoss | cnd, thanks | 14:45 |
* tvoss waits for unity-2d-daily to finish compiling | 14:45 | |
cnd | aha, so the last update event sometimes has a huge position delta | 14:48 |
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:12 |
cnd | note to self: don't edit shared events from your phone | 15:16 |
bregma | OK | 15:16 |
bregma | is the fix straighforward? It should probably get int to 2.2.8 if possible. | 15:17 |
cnd | yes | 15:19 |
cnd | very | 15:19 |
cnd | bregma, http://paste.ubuntu.com/904046/ | 15:19 |
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:20 |
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:21 |
tvoss | bregma, do you remember my branch for fixing the format error in geis on i386? | 15:25 |
bregma | vaguely | 15:26 |
bregma | the one where we didn;t know why it wasn't failing | 15:27 |
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:29 |
tvoss | bregma, ack | 15:30 |
tvoss | bregma, would you mind merging it? we can have utouch all green then :) | 15:30 |
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:31 |
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:32 |
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:33 |
cnd | I wish the sync extension were better documented | 15:34 |
cnd | and way better coded | 15:34 |
cnd | it's really awful | 15:34 |
cnd | dandrader, can you find anything in the sync extension that would work the way we want it to? | 15:36 |
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:37 |
cnd | "The await is | 15:38 |
cnd | processed asynchronously by the server" | 15:38 |
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:39 |
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:40 |
cnd | I think I may have it wrong in the code and we are getting extra events we don't need | 15:41 |
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:42 |
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:48 |
tvoss | bregma, build fails with a missing header file: http://pastebin.ubuntu.com/904102/ | 15:52 |
bregma | tvoss, fixing.... | 16:02 |
tvoss | bregma, thanks | 16:02 |
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:10 |
cnd | tvoss, are there plans to move our jenkins work to qa.ubuntu.com? | 16:20 |
=== dandrader is now known as dandrader|lunch | ||
cnd | bregma, how's bug 944822 coming? | 17:23 |
cnd | I'm hitting it in my testcase for the position delta bug :) | 17:23 |
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:32 |
tvoss | bregma, scheduled a rebuild | 17:33 |
bregma | peachy, we'll just wee what we shall see | 17:34 |
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:35 |
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:38 |
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:39 |
tvoss | bregma, geis is green again | 17:42 |
cnd | actually, even overriding SetUp() won't work unless we begin using value-parameterized tests, which isn't really what they are intended for | 17:52 |
=== dandrader|lunch is now known as dandrader | ||
=== sbambrough is now known as scottb | ||
cnd | dandrader, any luck with the sync extension? | 19:54 |
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:55 |
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:56 |
dandrader | gotta submit a bug report now... | 19:57 |
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:58 |
dandrader | "works for me"(tm) | 19:59 |
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
dandrader | Why is utouch-geis implemented all in C (as opposed to C++, like in utouch-frame and utouch-grail)? | 21:16 |
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:20 |
bregma | C can provide a stable ABI across compilers, C++ can't | 21:21 |
bregma | of course, now that tgrail and friends were rewritten in C++, the pulling-in-the-whole-runtime is shot to heck | 21:22 |
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:36 |
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:37 |
dandrader | I'm missing the std goodies... Where to go for a hash table now? | 21:39 |
dandrader | but we do have a geis_bag :) | 21:40 |
cnd | dandrader, make one? | 21:43 |
cnd | dandrader, we could also use glib, but we were concerned about it's support across platforms | 21:43 |
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:44 |
cnd | bregma, I've proposed the fix for the delta position | 21:45 |
cnd | I realized that since the gtest_attr tests all use the same device, we can work around bug 944822 for now | 21:46 |
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:57 |
bregma | there are many times I missed my standard library when writinggeis | 21:58 |
bregma | cnd, I'll try to review your MRs later today | 21:59 |
cnd | bregma, sounds good :) | 21:59 |
dandrader | bregma, I feel your pain | 22:00 |
dandrader | rewriting standard stuff such as containers is far from motivating indeed | 22:00 |
dandrader | well. time's up for me | 22:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!