=== MacSlow is now known as MacSlow|lunch [11:17] Four finger gestures are still broken for me. Are they working for anyone? === MacSlow|lunch is now known as MacSlow [13:48] Unity 2D still works with swipe a couple of times. Then it crashes. [14:15] Satoris, they are still going to be broken until I get some touch accounting fixes in [14:15] Satoris, bregma_, dandrader, tvoss: standups! [14:15] Proposed fix for "2. UGEvent::Unref()" issue from "[Systems-team] Grail fixes" e-mail sent by cnd. Now I'll start looking into the issue described in "3. Recognizer::AcceptGesture()". [14:15] did the standups gets moved by an hour, or am I confused? [14:16] bregma_, yep. timezone shifts cased it [14:16] bregma_, yes, europe just entered DST [14:16] chromium and bug work, jenkins work [14:16] I'm going to be doing code reviews and cleaning up touch accounting fixes in grail to propose it [14:16] Tried to work on bugs and stuff but turned out unproductive. In a fit of rage rewrote evemu's build system in CMake. It's a proof of concept that took maybe an hour. [14:16] that doesn't make sense, my timezone hasn't changed [14:16] Chromium finalisation too. [14:17] Which touch bugs are fixed and worked on and which ones are not? [14:18] Satoris, you mean from that "Grail fixes" e-mail? [14:18] That, but anywhere really. [14:18] bregma_, this is getting some attention on #ubuntu-devel: https://bugs.launchpad.net/unity/+bug/963500 [14:19] yet another duplicate [14:19] I will tackle that today then [14:19] ok [14:19] Satoris, from that e-mail the only item that no one worked on yet is "6. All tests", I think [14:21] It's not causing any bugs (yet). cnd, what should we focus on next? [14:21] Satoris, that would still be very helpful to have done [14:22] I can get you a diff [14:22] There are no crashers or usability issues (apart from nothing working at all)? [14:25] cnd, do you recall the bug that caused that output? https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/964135 [14:25] Satoris, I'm not sure what you want? [14:26] you can test things, find bugs, and try to resolve them [14:26] but it will be hard for another day or two until I can get the touch accounting stuff fixed [14:26] dandrader, that's also due to the touch accounting issues [14:27] ah, ok [14:27] maybe you could make it a duplicate or something [14:28] cnd: should I work on 6 or some other issue tomorrow? [14:28] Satoris, 6 would be helpful if it's not fixed by then [14:31] dandrader, I don't think we have a bug for touch accounting yet, so I may just use it [14:31] even better [14:32] Satoris, http://paste.ubuntu.com/900536/ [14:32] it's a hand edited diff, so it may need some massaging to apply [14:32] was someone working on porting Unity to GEISv2? [14:33] bregma_, o/ [14:33] what's the status of that? [14:33] bregma_, done. but not proposed yet as it doesn't fix any bug [14:33] well, actually I have a list of at least 6 bugs it would fix [14:33] in reality it does fix [14:34] but it's not a proper fix for the bugs [14:34] a proper fix being fixing GEISv1 [14:34] well, the problem is that GEISv1 is incompatible with the new grail architecture, so the solution is to move to GEISv2 and be done with [14:35] bregma_, ? [14:35] it's really really late to be moving to geis v2 [14:36] Should someone want to play with it: https://code.launchpad.net/~jpakkane/utouch-evemu/cmake [14:36] Not proposing for merge for obvious reasons. [14:36] can you describe what problems you were having with the utouch-evemu build as it currently exists? [14:36] It is implemented in autogarbage. [14:37] I find your attitude unprofessional in this regard [14:37] tvoss: please tell how many hours you have lost due to said build system. [14:37] I asked for a problem desription, not a politicl rant === dandrader is now known as dandrader|afk [14:38] Satoris, bregma_ it is indeed more cumbersome to adjust the auto* build systems for automatic building and testing, at least: that's my experience with it [14:39] I have made my point several times (more than I should have, probably). Autotools is a poor system, which is fragile, hard to use, unreliable, and causes lost productivity. [14:39] _is_ there a problem description? [14:40] bregma_, not in terms of a description that one could put in a bug report [14:40] Tried to work on bugs and stuff but turned out unproductive. In a fit of rage rewrote evemu's build system in CMake [14:41] bregma_, it's more like papercuts to me that add up to decreased efficiency [14:41] surely those bugs have descriptions? [14:41] They are bugs (and design decisions) of autotools, not our projects. [14:42] Time lost fighting the system rather than working on real issues is the main thing for me. [14:42] what were you trying to do in utouch-evemu that caused the fits of rage? Surely something that bad can be described in words. [14:42] Given that there are zero bugs against that project [14:42] The fit of rage came elsewhere. I chose evemu, because it was the easiest and thus makes a good proof of concept. [14:43] ah, I see, purely political then [14:43] Loss of productivity is political? [14:44] I have not loss of productivity with that project [14:44] I builds, it runs, it has zero bugs [14:44] that's why I was asking [14:45] There have been issues raised that possibly CMake could not do some things that we need. This was made to show that it can do what is required. === dandrader|afk is now known as dandrader [15:05] biab [16:16] dandrader, I'm going to propose the fix to the tests for subscription deactivate before slice unreferencing [16:16] just fyi [16:16] cnd, [16:16] ok [16:17] that's the last thing necessary before I can look into proposing the touch accounting fixes [16:17] cnd, btw, should that practice be documented somewhere in grail.h? [16:17] (the slice before subscription thing) [16:17] dandrader, maybe... [16:18] I'd actually rather fix it for real [16:18] I think if UGEvent held a shared_ptr reference to the subscription, it would work [16:18] it's a bit of a corner case [16:18] the user normally shouldn't be closing down a subscription while still processing events [16:24] I find it a bit confusing that a gesture can be active and ended at the same time [16:28] cnd, could the code in gesture.cpp:202 be simply a call to End()? [16:31] dandrader, End() is a method that does ends a gesture, line 202 is an if conditional [16:31] did you mean something else? [16:32] I meant calling End() from inside that if(){} [16:32] cnd, ^ [16:33] instead of replicating the code. One difference is that End() also clears some lists. I don't know if that matters [16:33] that's why I asked [16:33] dandrader, yeah, we should call End() there [16:33] good catch [16:36] cool. I'll add this change to a branch along with some other simple refactoring commits [16:36] sounds good [16:37] dandrader, I just proposed the test fixes, btw [16:38] ok, I'll check them after lunch === dandrader is now known as dandrader|lunch [16:41] dandrader|lunch, I filed a bug for the fact that UGSlice does not have a reference to UGSubscription [16:41] so it's a documented issue === dandrader|lunch is now known as dandrader [18:30] * cnd wishes grail and gcc had C11 _Generic support [18:31] I just spent 20 minutes tracking down a bug where I was passing a pointer to a c++ bool instead of an int [18:31] which are of different sizes on i386 at least [18:34] hint: don't do that [18:42] bregma_, you're always so helpful :) [18:42] np [19:37] dandrader, bregma_: I just proposed a utouch-grail branch that will make gestures work properly [19:38] it should fix all the grail warnings people see in their .xsession-errors and when running apps on the command line [19:38] I'm going to get some lunch, biab [19:38] I'm waiting for MR mail to come through [19:39] whups, there it is.... === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [21:24] dandrader, help me understand why signals and slots is a better architectural solution [21:24] the reason I'm hesitant about it is because it replaces a strong linkage between two objects with a weaker dynamic linkage [21:25] while signals and slots look better aesthetically, to me at least, I worry that it opens us up to less maintainable architectures because it won't be quite as obvious how objects interact with each other [21:31] it's just about having better or true encapsulation. A Touch is shouldn't know that a Recognizer exists. It's the other way around [21:31] s/Touch is/Touch [21:32] it's a big enabler of unit testing, for instance. [21:33] if you have hard links between objects it gets very difficult to use them individually or to use them in different parts of the system [21:35] hmm... that's a good point [21:35] dandrader, I'm hesitant to make a change to using a new library at this point though [21:36] merely because of how close we are to release [21:36] it adds a huge new variable to everything [21:36] though after 12.04 is released we can look into using signals [21:36] dandrader, what do you think? [21:36] I think if you have objects calling each other you can easily end up with an entanglement of relationships that makes the system more complex. [21:36] but sure [21:37] at this point it might be risky to add this dependence [21:38] I do agree about the tangled relationships [21:38] it does make me cringe having the all_touches_ array and the Recognizer::DeleteTouch method [21:39] dandrader, maybe we don't need Recognizer::DeleteTouch... [21:39] maybe we can just delete it from all_touches_ when the TouchEnd is seen [21:39] we're guaranteed not to receive any more events for that touch [21:40] we're also guaranteed to receive the TouchEnd [21:40] we could put a check at the end of ProcessEvent to reap all ended touches from all_touches_ [21:44] yeah, that sounds good [21:45] gotta go. I'll continue reading your patch tomorrow morning. see you tomorrow [22:47] bregma_, it dawned on me that the resolution to our aclocal m4 script daily build issue is that we should be checking in a copy of xorg-gtest.m4 into our upstream m4/ directory [22:48] the aclocal system uses serial numbers to keep track of newer macro scripts, so it shouldn't be harmful [22:48] and our distributed tarball includes the scripts anyways, so it's not as though the real upstream distribution will be any different [22:49] merely the upstream source code repository will contain one more file