/srv/irclogs.ubuntu.com/2012/03/26/#ubuntu-touch.txt

=== MacSlow is now known as MacSlow|lunch
SatorisFour finger gestures are still broken for me. Are they working for anyone?11:17
=== MacSlow|lunch is now known as MacSlow
SatorisUnity 2D still works with swipe a couple of times. Then it crashes.13:48
cndSatoris, they are still going to be broken until I get some touch accounting fixes in14:15
cndSatoris, bregma_, dandrader, tvoss: standups!14:15
dandraderProposed 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:15
dandraderbregma_, yep. timezone shifts cased it14:16
cndbregma_, yes, europe just entered DST14:16
tvosschromium and bug work, jenkins work14:16
cndI'm going to be doing code reviews and cleaning up touch accounting fixes in grail to propose it14:16
SatorisTried 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 changed14:16
SatorisChromium finalisation too.14:16
SatorisWhich touch bugs are fixed and worked on and which ones are not?14:17
dandraderSatoris, you mean from that "Grail fixes" e-mail?14:18
SatorisThat, but anywhere really.14:18
cndbregma_, this is getting some attention on #ubuntu-devel: https://bugs.launchpad.net/unity/+bug/96350014:18
bregma_yet another duplicate14:19
bregma_I will tackle that today then14:19
cndok14:19
dandraderSatoris,  from that e-mail the only item that no one worked on yet is "6. All tests", I think14:19
SatorisIt's not causing any bugs (yet). cnd, what should we focus on next?14:21
cndSatoris, that would still be very helpful to have done14:21
cndI can get you a diff14:22
SatorisThere are no crashers or usability issues (apart from nothing working at all)?14:22
dandradercnd, do you recall the bug that caused that output? https://bugs.launchpad.net/ubuntu/+source/utouch-grail/+bug/96413514:25
cndSatoris, I'm not sure what you want?14:25
cndyou can test things, find bugs, and try to resolve them14:26
cndbut it will be hard for another day or two until I can get the touch accounting stuff fixed14:26
cnddandrader, that's also due to the touch accounting issues14:26
dandraderah, ok14:27
dandradermaybe you could make it a duplicate or something14:27
Satoriscnd: should I work on 6 or some other issue tomorrow?14:28
cndSatoris, 6 would be helpful if it's not fixed by then14:28
cnddandrader, I don't think we have a bug for touch accounting yet, so I may just use it14:31
dandradereven better14:31
cndSatoris, http://paste.ubuntu.com/900536/14:32
cndit's a hand edited diff, so it may need some massaging to apply14:32
bregma_was someone working on porting Unity to GEISv2?14:32
dandraderbregma_, o/14:33
bregma_what's the status of that?14:33
dandraderbregma_, done. but not proposed yet as it doesn't fix any bug14:33
bregma_well, actually I have a list of at least 6 bugs it would fix14:33
dandraderin reality it does fix14:33
dandraderbut it's not a proper fix for the bugs14:34
dandradera proper fix being fixing GEISv114: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 with14:34
cndbregma_, ?14:35
cndit's really really late to be moving to geis v214:35
SatorisShould someone want to play with it: https://code.launchpad.net/~jpakkane/utouch-evemu/cmake14:36
SatorisNot 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
SatorisIt is implemented in autogarbage.14:36
bregma_I find your attitude unprofessional in this regard14:37
Satoristvoss: 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 rant14:37
=== dandrader is now known as dandrader|afk
tvossSatoris, bregma_ it is indeed more cumbersome to adjust the auto* build systems for automatic building and testing, at least: that's my experience with it14:38
SatorisI 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:39
tvossbregma_, not in terms of a description that one could put in a bug report14:40
bregma_<Satoris> Tried to work on bugs and stuff but turned out unproductive. In a fit of rage rewrote evemu's build system in CMake14:40
tvossbregma_, it's more like papercuts to me that add up to decreased efficiency14:41
bregma_surely those bugs have descriptions?14:41
SatorisThey are bugs (and design decisions) of autotools, not our projects.14:41
SatorisTime 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 project14:42
SatorisThe fit of rage came elsewhere. I chose evemu, because it was the easiest and thus makes a good proof of concept.14:42
bregma_ah, I see, purely political then14:43
SatorisLoss of productivity is political?14:43
bregma_I have not loss of productivity with that project14:44
bregma_I builds, it runs, it has zero bugs14:44
bregma_that's why I was asking14:44
SatorisThere 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.14:45
=== dandrader|afk is now known as dandrader
cndbiab15:05
cnddandrader, I'm going to propose the fix to the tests for subscription deactivate before slice unreferencing16:16
cndjust fyi16:16
dandradercnd,16:16
dandraderok16:16
cndthat's the last thing necessary before I can look into proposing the touch accounting fixes16:17
dandradercnd, btw, should that practice be documented somewhere in grail.h?16:17
dandrader(the slice before subscription thing)16:17
cnddandrader, maybe...16:17
cndI'd actually rather fix it for real16:18
cndI think if UGEvent held a shared_ptr reference to the subscription, it would work16:18
cndit's a bit of a corner case16:18
cndthe user normally shouldn't be closing down a subscription while still processing events16:18
dandraderI find it a bit confusing that a gesture can be active and ended at the same time16:24
dandradercnd, could the code in gesture.cpp:202 be simply a call to End()?16:28
cnddandrader, End() is a method that does ends a gesture, line 202 is an if conditional16:31
cnddid you mean something else?16:31
dandraderI meant calling End() from inside that if(){}16:32
dandradercnd, ^16:32
dandraderinstead of replicating the code. One difference is that End() also clears some lists. I don't know if that matters16:33
dandraderthat's why I asked16:33
cnddandrader, yeah, we should call End() there16:33
cndgood catch16:33
dandradercool. I'll add this change to a branch along with some other simple refactoring commits16:36
cndsounds good16:36
cnddandrader, I just proposed the test fixes, btw16:37
dandraderok, I'll check them after lunch16:38
=== dandrader is now known as dandrader|lunch
cnddandrader|lunch, I filed a bug for the fact that UGSlice does not have a reference to UGSubscription16:41
cndso it's a documented issue16:41
=== dandrader|lunch is now known as dandrader
* cnd wishes grail and gcc had C11 _Generic support18:30
cndI just spent 20 minutes tracking down a bug where I was passing a pointer to a c++ bool instead of an int18:31
cndwhich are of different sizes on i386 at least18:31
bregma_hint:  don't do that18:34
cndbregma_, you're always so helpful :)18:42
bregma_np18:42
cnddandrader, bregma_: I just proposed a utouch-grail branch that will make gestures work properly19:37
cndit should fix all the grail warnings people see in their .xsession-errors and when running apps on the command line19:38
cndI'm going to get some lunch, biab19:38
bregma_I'm waiting for MR mail to come through19:38
bregma_whups, there it is....19:39
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
cnddandrader, help me understand why signals and slots is a better architectural solution21:24
cndthe reason I'm hesitant about it is because it replaces a strong linkage between two objects with a weaker dynamic linkage21:24
cndwhile 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 other21:25
dandraderit's just about having better or true encapsulation. A Touch is shouldn't know that a Recognizer exists. It's the other way around21:31
dandraders/Touch is/Touch21:31
dandraderit's a big enabler of unit testing, for instance.21:32
dandraderif you have hard links between objects it gets very difficult to use them individually or to use them in different parts of the system21:33
cndhmm... that's a good point21:35
cnddandrader, I'm hesitant to make a change to using a new library at this point though21:35
cndmerely because of how close we are to release21:36
cndit adds a huge new variable to everything21:36
cndthough after 12.04 is released we can look into using signals21:36
cnddandrader, what do you think?21:36
dandraderI 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
dandraderbut sure21:36
dandraderat this point it might be risky to add this dependence21:37
cndI do agree about the tangled relationships21:38
cndit does make me cringe having the all_touches_ array and the Recognizer::DeleteTouch method21:38
cnddandrader, maybe we don't need Recognizer::DeleteTouch...21:39
cndmaybe we can just delete it from all_touches_ when the TouchEnd is seen21:39
cndwe're guaranteed not to receive any more events for that touch21:39
cndwe're also guaranteed to receive the TouchEnd21:40
cndwe could put a check at the end of ProcessEvent to reap all ended touches from all_touches_21:40
dandraderyeah, that sounds good21:44
dandradergotta go. I'll continue reading your patch tomorrow morning. see you tomorrow21:45
cndbregma_, 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/ directory22:47
cndthe aclocal system uses serial numbers to keep track of newer macro scripts, so it shouldn't be harmful22:48
cndand our distributed tarball includes the scripts anyways, so it's not as though the real upstream distribution will be any different22:48
cndmerely the upstream source code repository will contain one more file22:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!