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