| === MacSlow is now known as MacSlow|lunch | ||
| dandrader | bregma, can I assume that a GeisTouch will have the same ID as its XInput2 counterpart? | 12:17 |
|---|---|---|
| bregma | dandrader, I can't guarantee it, the GEIS touchId is the same as the Frame touchId but I can't guarantee that's transitive with the X touchId | 12:37 |
| Satoris | I have to leave early, but today I have been refactoring and adding tests to the secret project. | 12:46 |
| bregma | ah, Friday | 12:50 |
| * bregma thinks about making an espresso to fill his empty cup | 12:51 | |
| === MacSlow|lunch is now known as MacSlow | ||
| tvoss | chromium patch love, utouch-frame backend work, secret project | 14:15 |
| bregma | before I bring up some dbus-backend tests for geis I'm trying to figure out a nice way to simplify existing tests, they're a bit of a pain | 14:15 |
| * tvoss notices that bregma didn't have a coffee for standus today | 14:16 | |
| dandrader | Finished mocking up Xlib and XInput2 for utouch-geis testing. Works beautifully. Now I've started to tidy up things and write the actual regression test for https://bugs.launchpad.net/bugs/984069 | 14:16 |
| tvoss | dandrader, do you have the mocks reusable or are they tightly integrated with geis? | 14:17 |
| * bregma swirls the dregs of a fine melange spice coffee from Arrakis | 14:17 | |
| dandrader | tvoss, they're reusable, but made for geis needs | 14:18 |
| bregma | I hope they're reusable so they can be used with frame and grail tests | 14:18 |
| dandrader | so they're not mocking up all of Xlib | 14:18 |
| dandrader | just what geis and frame uses | 14:18 |
| tvoss | dandrader, ack .. will take a look at it then | 14:18 |
| tvoss | dandrader, might have questions though :) | 14:18 |
| tvoss | cnd, standup? | 14:19 |
| cnd | right, thanks :) | 14:19 |
| dandrader | bregma, grail tests could use the utouch-frame generic backend that tvoss is cooking up as well | 14:19 |
| * bregma passes cnd some spice coffee to help his eyes open | 14:19 | |
| cnd | I'm going to fix up the geis deltas patch, then look for more bugs to work on | 14:19 |
| cnd | bregma, dandrader: reviews of the xorg-gtest patches would be appreciated :) | 14:26 |
| dandrader | cnd, about that x11 mock up project that you mentioned the other day. The one that Robert Ancell started. Seems to be an absolute overkill for our needs. https://launchpad.net/xig | 14:26 |
| cnd | dandrader, overkill isn't necessarily a bad thing | 14:27 |
| dandrader | I didn't spend enough time to understand it properly. but seems quite complex | 14:28 |
| cnd | dandrader, are you trying to say that you think it's not designed well, and we shouldn't integrate with it? | 14:29 |
| cnd | or? | 14:29 |
| dandrader | cnd, Can't really tell right now as I didn't spend enough time to understand it properly. It's just my feeling against adding more complexity than needed. the mocking I did is pretty simple and it's sufficient. | 14:36 |
| dandrader | most functions are empty implementations | 14:37 |
| cnd | dandrader, the tradeoff is that we might end up reimplementing similar things multiple times | 14:37 |
| cnd | I'm a big fan of reuse and extending existing projects | 14:37 |
| cnd | dandrader, I'd feel better if you have concrete reasons why we shouldn't integrate with xig | 14:39 |
| cnd | we could then give feedback to robert too | 14:39 |
| bregma | for a proper mock Xlib I would want to be able to capture real X events to a file and be able to send them through the mock object to reproduce operations in a controlled way | 14:39 |
| cnd | bregma, that would be rather difficult | 14:40 |
| bregma | I'm just sayin' that's what I would want | 14:40 |
| cnd | because of things like window IDs | 14:40 |
| cnd | at a certain point, you're better off using the real implementation | 14:40 |
| cnd | dandrader, would you mind doing a more in depth look at xig and writing up your conclusions? | 14:41 |
| bregma | is that project on lp? | 14:42 |
| cnd | bregma, xig? | 14:42 |
| cnd | https://launchpad.net/xig | 14:42 |
| bregma | super, thanks | 14:42 |
| dandrader | cnd, I can do it after I'm done with https://bugs.launchpad.net/bugs/984069 | 14:42 |
| cnd | dandrader, will that require merging in your xi mocks? | 14:43 |
| dandrader | yes :) | 14:43 |
| cnd | ugh | 14:44 |
| cnd | I would rather we made full decisions up front about this | 14:44 |
| bregma | sounds like a good sprint-time discussion | 14:45 |
| cnd | dandrader, an xorg-gtest based test would get us over the hump for this specific bug | 14:45 |
| cnd | and then we can look more closely at the X mocks | 14:45 |
| dandrader | I would rather not use xorg-gtest for this. Besides, I have the mock ready right now. | 14:46 |
| dandrader | Why start it over with an xorg-gtest approach? | 14:46 |
| cnd | there's a real cost with multiple implementations of the same thing | 14:46 |
| dandrader | the mock is small, it's simple to remove it | 14:47 |
| cnd | dandrader, maybe we can work out a deal | 14:47 |
| cnd | we can merge your mock, but one of your tasks is to do a more formal look at xig | 14:47 |
| cnd | and either redevelop the mock in xig if it is suitable | 14:48 |
| cnd | or provide sufficient reasoning why we shouldn't | 14:48 |
| dandrader | there's a real cost in integration tests that are slow to run and are unreliable since they break easily because they depend on several external factors | 14:48 |
| cnd | all that can be fixed | 14:48 |
| cnd | even the slowness for the most part | 14:49 |
| cnd | the way we do the tests right now we insert delays where we don't "really" need them if we write the tests properly | 14:49 |
| dandrader | cnd, sure. your deal was my suggestion. dig into xig after I'm done with bug 984069 | 14:49 |
| cnd | dandrader, let's aim to have things ready to discuss at the sprint | 14:50 |
| * bregma hates artificial delays | 14:50 | |
| * bregma spent too many years doing realtime to have likes for usleep() | 14:50 | |
| cnd | there's two places where we generally have delays in our tests: | 14:51 |
| cnd | device init waits | 14:51 |
| dandrader | cnd, to tell the truth I don't even know how to test bug 984069 with xorg-gtest. With the mock I send Xinput2 events with specific window and device coords. Then I can easily check which of the coords showed up on the other side, in Geis events | 14:51 |
| cnd | and polling for more events | 14:51 |
| cnd | dandrader, you can send a gesture event from a touchscreen evemu recording | 14:52 |
| cnd | and check that the coordinates match known good values | 14:52 |
| cnd | for the device waits, we can listen for XIHierarchyChanged events | 14:52 |
| cnd | instead of waiting X seconds | 14:52 |
| cnd | and for the polling for more events, we probably should just break the loop when we get the gesture end event we're looking for | 14:53 |
| bregma | most of what's in the geis integration tests is slapped together quickly so I could forcus on functionality rather than pukka tests | 14:53 |
| cnd | yeah | 14:53 |
| bregma | I am turning my attention to improving the tests today | 14:53 |
| cnd | I do the same in grail and frame though | 14:53 |
| cnd | it's not just you :) | 14:53 |
| bregma | because it is hurting me avery time I look at one | 14:53 |
| cnd | bregma, I'm beginning to think that xorg-gtest should have an event processor and dispatcher | 14:54 |
| cnd | so we don't reimplement the same event loop in every test | 14:54 |
| bregma | perhaps, but it will take some though to make it usefully generic | 14:54 |
| cnd | yeah | 14:54 |
| cnd | that's why I haven't done it yet :) | 14:54 |
| bregma | I would start by refactoring the geis tests to see if we can identify what can be further refactored upstream into xorg-gtest | 14:55 |
| cnd | yep | 14:55 |
| cnd | the other thing I might tackle today is that when the env shuts down we SIGTERM/SIGKILL the x server but we don't wait for it to actually die | 14:55 |
| cnd | I think this is causing race conditions in the geis tests | 14:55 |
| cnd | where the next test starts before the previous test is finished | 14:56 |
| bregma | I would think the OS should really take care of that sort of thing | 14:56 |
| bregma | perhaps the X server is a special case because of all the wacky external stuff it does | 14:56 |
| bregma | like all the DBus stuff it ssems to do (ever run strace -f on it?) | 14:57 |
| bregma | cnd, your comments on bzr/git sure poked a sore spot | 14:58 |
| cnd | there's a not insignificant amount of time between the server being sent SIGTERM and it actually completing shut down | 14:58 |
| cnd | yeah... | 14:58 |
| cnd | but it's inevitable, there are people ingrained on bzr and git | 14:59 |
| bregma | it's a religious issue for many | 14:59 |
| bregma | I was playing with git-bzr-ng yesterday.... sweet | 14:59 |
| cnd | yeah | 15:00 |
| cnd | bregma, the one from termie's github repo? | 15:01 |
| bregma | yes | 15:01 |
| bregma | it's not package for Debian or Ubuntu | 15:01 |
| cnd | it still has some rough edges though | 15:01 |
| cnd | but it definitely helps | 15:02 |
| cnd | bregma, if I want to listen for both drags and pinches, I create separate filters for them and add them to one subscription? | 15:05 |
| bregma | yes: filter terms are ANDed, subscription filters are ORed | 15:08 |
| cnd | k | 15:08 |
| bregma | I repeat that to myself a lot because I always muck it up | 15:08 |
| cnd | bregma, what's the easiest way to determine what type of a gesture a geis 2 frame is? | 15:12 |
| cnd | it looks like it would be easy if I could get the gesture class of a frame | 15:13 |
| cnd | but that doesn't seem possible | 15:13 |
| bregma | the only way is to call geis_frame_is_class(), which means you need to remember all the classes as they are reported | 15:14 |
| cnd | bregma, should we be adding a geis_frame_get_class() call? | 15:14 |
| bregma | a frame can be classified more than one way | 15:15 |
| cnd | ahh | 15:15 |
| bregma | in theory there could be a ..._get_classes() call | 15:16 |
| cnd | if I have both a pinch and a drag going on for the same subscription, will I just get one set of frames? | 15:16 |
| bregma | that's the way it's supposed to work | 15:16 |
| cnd | ok | 15:16 |
| bregma | I believe it does work that way, but I don't think there's a test to prove it | 15:17 |
| bregma | dandrader, do you have a branch with your mock X available? | 15:23 |
| dandrader | bregma, lp:~dandrader/utouch-geis/lp984069 | 15:25 |
| bregma | thanks -- I think you're right, this is exactly what we need, but I think it should be a completely separate project, it's got potential uses outside uTouch | 15:28 |
| bregma | that can be done later | 15:28 |
| bregma | xig wouldn't help use | 15:29 |
| bregma | *us* | 15:29 |
| cnd | bregma, why wouldn't xig help us? | 15:41 |
| === dandrader is now known as dandrader|lunch | ||
| bregma | as far as I can tell by reading the code, xig is a glib wrapper around Xlib that comes with a mock xserver | 15:43 |
| bregma | it would help us if we rewrote utouch to use gobjects | 15:44 |
| cnd | ok | 15:45 |
| bregma | we should maybe get Robert to join us for a chat at the sprint or at UDS, if he's not busy, and share | 15:45 |
| cnd | yeah | 15:46 |
| bregma | or maybe the whole idea of a mock xlib is worthy of a session at UDS? | 15:46 |
| cnd | I worry a bit about creating lots of test frameworks for X, when we might move off it soonish | 15:46 |
| * bregma backs away slowly from a project that could consume small cities | 15:46 | |
| cnd | yeah, that's my concern too | 15:47 |
| cnd | I do sort of feel the need for a mock is lessened if we make the integration tests work well | 15:48 |
| bregma | is there some way we could change evemu so it doesn't need root privs? | 15:49 |
| cnd | yes, it's actually quite easy | 15:49 |
| cnd | however, it's quite the security hole | 15:49 |
| cnd | bregma, put this: http://paste.ubuntu.com/938453/ in /etc/udev/rules.d/99-user-input.rules | 15:50 |
| cnd | and change the group to whatever makes sense for you | 15:50 |
| cnd | then restart | 15:51 |
| cnd | or chmod/chown the files for the current session | 15:51 |
| cnd | with that and the fix currently in upstream xorg-gtest master you can run tests as the normal user without having to switch to a VT | 15:52 |
| cnd | biab | 15:53 |
| === tvoss is now known as tvoss|gftd | ||
| cnd | bregma, with the xorg-gtest patch I just sent out, I'm able to run through a full geis test suite without issue | 16:53 |
| bregma | I'll test it out locally -- do you need a reviewed-by or anything? | 16:55 |
| cnd | yes | 16:56 |
| cnd | for all four patches sent to the list | 16:56 |
| bregma | righty-o | 16:56 |
| cnd | thanks | 16:56 |
| cnd | I wish there was a version of the wait* syscalls that took a timeout value | 16:57 |
| cnd | it seems silly that there isn't | 16:57 |
| cnd | and registering a signal handler for SIGCHLD in a library seems bad | 16:58 |
| bregma | well, having a mainline in a library is a bit unusual, too | 16:59 |
| cnd | bregma, you mean having main()? | 16:59 |
| cnd | it's optional, so you don't have to use it if you don't want | 16:59 |
| bregma | I knwo, but it's weird to me | 16:59 |
| cnd | yeah | 16:59 |
| cnd | but it does make things easier | 16:59 |
| bregma | that's why SDL does it on windows | 17:00 |
| bregma | just, you know, a data point | 17:00 |
| === dandrader|lunch is now known as dandrader | ||
| cnd | bregma, with some simple changes we can drop the geis2 tests from over a minute to 18 seconds :) | 17:15 |
| cnd | http://paste.ubuntu.com/938581/ | 17:16 |
| bregma | cnd, why do you think delta-radius should be geometric rather than arithmetic? Doing it that way doesn't feel quite right on a touchscreen. | 17:44 |
| cnd | bregma, the radius value is geometric now | 17:44 |
| cnd | it feels right to me, too | 17:45 |
| cnd | when I pinch in unity | 17:45 |
| bregma | I mean geometric doesn;t feel right | 17:46 |
| bregma | then again, gestures no longer work in eog | 17:46 |
| bregma | I wonder when that happened | 17:46 |
| bregma | hmmmm | 17:46 |
| AlanBell | !ping | 17:46 |
| lubotu3 | another contentless ping... sigh... | 17:46 |
| cnd | bug 986215 | 17:47 |
| lubotu3 | Launchpad bug 986215 in utouch-geis "Radius delta values should be a ratio instead of a difference" [Medium,In progress] https://launchpad.net/bugs/986215 | 17:47 |
| cnd | welcome lubotu3 :) | 17:47 |
| bregma | skynet is here | 17:47 |
| cnd | bregma, why does geometric not feel right? | 17:48 |
| cnd | we discussed this a while back | 17:48 |
| cnd | though on irc, where records are harder to find :( | 17:48 |
| bregma | it just doesn't feel... right | 17:48 |
| bregma | I guess it's just subjective | 17:48 |
| bregma | I don't recall any discussion on radius delta being geometric | 17:49 |
| bregma | actually, it feels right for touchpads | 17:49 |
| cnd | there's also hand size to take into account | 17:49 |
| cnd | which geometric handles inherently | 17:50 |
| AlanBell | !ping | 17:50 |
| ubot5 | another contentless ping... sigh... | 17:50 |
| AlanBell | quick botswap, I sent the wrong one in | 17:51 |
| bregma | perhaps it's mostly a matter of training, geometric is not broken, just not how I expect it to behave on a touchscreen | 17:51 |
| bregma | I admit it's really really subjective | 17:51 |
| cnd | the problem is if you have arithmetric, you'll have to do thresholds that are based on each individual device size | 17:52 |
| cnd | and resolution | 17:52 |
| bregma | very true | 17:52 |
| cnd | and some devices can't provide accurate values for both :) | 17:52 |
| bregma | yes, pain is to be had there | 17:53 |
| cnd | I honestly felt like the pinch threshold in unity before this change was good for the magic trackpad | 17:53 |
| cnd | but too high for the touchscreen | 17:53 |
| cnd | I had to really work to trigger it on behemoth | 17:53 |
| cnd | now it feels much more natural on both | 17:53 |
| cnd | it was also near impossible on my netbook, but now it is impossible because my netbook is only semi-mt :( | 17:54 |
| bregma | well, it's not really that big of a deal for me and perhaps if necessary in the future we can make this a tuning point | 17:56 |
| cnd | yeah | 17:56 |
| cnd | ubotu | 18:11 |
| cnd | ubot5, ubotu | 18:11 |
| ubot5 | Hi! I'm #ubuntu-touch's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi | Usage info: http://ubottu.com/devel/wiki/Plugins | Bot channels and general info: https://wiki.ubuntu.com/IRC/Bots | 18:11 |
| cnd | ubot5, es | 18:11 |
| ubot5 | En la mayoría de los canales de Ubuntu, se habla sólo en inglés. Si busca ayuda en español entre al canal #ubuntu-es; escriba "/join #ubuntu-es" (sin comillas) y presione intro. | 18:11 |
| cnd | !es | 18:13 |
| ubot5 | En la mayoría de los canales de Ubuntu, se habla sólo en inglés. Si busca ayuda en español entre al canal #ubuntu-es; escriba "/join #ubuntu-es" (sin comillas) y presione intro. | 18:13 |
| cnd | dandrader, just for you: | 18:13 |
| cnd | !pt | 18:13 |
| ubot5 | Por favor, use #ubuntu-br para ajuda em português. Para entrar no canal por favor faça "/join #ubuntu-br" sem as aspas. Para a comunidade local portuguêsa, use #ubuntu-pt. Obrigado. | 18:13 |
| cnd | ubot5, thanks! | 18:14 |
| ubot5 | You're welcome! But keep in mind I'm just a bot ;-) | 18:14 |
| dandrader | :) | 18:14 |
| dandrader | what's the problem people have with resubmitting a proposal? for me it's the most natural way to do precisely that. otherwise verdicts for an earlier version of the path (like "needs fixing") will still list there | 19:56 |
| dandrader | s/path/patch | 19:57 |
| cnd | dandrader, earlier reviews can be overwritten by later reviews, and the log tells you what has changed over time | 20:03 |
| cnd | the problem with resubmissions is that the interleaving of the code and the reviews are lost | 20:03 |
| cnd | but I don't know how to best handle the situation where you add new stuff to an existing approved proposal | 20:04 |
| cnd | dandrader, can you provide more detail on why a gtest test won't work for your geis proposal? | 20:06 |
| cnd | I don't understand why it can't be used | 20:06 |
| dandrader | cnd, it can be used. but I would have to disentangle it from xorg-gtest and the optional compilation of integration tests | 20:07 |
| cnd | dandrader, I think we should do that then | 20:07 |
| cnd | gtest is supposed to be the "preferred" testing framework for product strategy | 20:08 |
| dandrader | sure. I was just too lazy to fight with autotools to do that disentanglement work. :) | 20:08 |
| cnd | heh | 20:09 |
| dandrader | was reading canonical-tech mailing list. about the bzr situation: it's a bittersweet feeling. It's sad to see a project being ramped down but it's great to see that Git is eventually coming on board :) | 20:12 |
| dandrader | oops | 20:13 |
| cnd | hmm... google mock is really c++ only | 20:21 |
| cnd | maybe keeping the xinput mock simple and hand made is best | 20:22 |
| cnd | dandrader, I'm wondering if we should do something a bit fancy: | 20:22 |
| cnd | make the mock optionally take evemu recordings | 20:22 |
| cnd | and generate xinput events from them | 20:22 |
| cnd | at compile/runtime we could then switch between integration and unit testing | 20:23 |
| cnd | well, integration with the kernel and X server vs just everything above the X server | 20:23 |
| isforinsects | Are there any tests it would be helpful for me to run on a macbook4,2 for 12.04? | 20:25 |
| dandrader | cnd, what do you mean exactly by "making the mock optionally take evemu recordings". It will read the recordings and produce XInput2 events out of them, thus still doing everything in the same process? | 20:26 |
| dandrader | (probably not but one can always hope) | 20:27 |
| cnd | yes, that's what I mean | 20:27 |
| dandrader | awesome! | 20:27 |
| cnd | it means adding a lot of code to the mock | 20:27 |
| cnd | but it would mean we no longer depend on a kernel and X server unless we want to | 20:27 |
| cnd | isforinsects, you can verify that the unity gestures are working: https://wiki.ubuntu.com/Multitouch#Supported_Gestures | 20:28 |
| dandrader | google mock also reallies heavily in classes having mostly virtual methods (if I'm not mistaken) for the mocking magic to work. I really don't like that requirement | 20:32 |
| cnd | yeah, I think I remember tvoss saying he looked at it too, and it wouldn't work for the utouch stuff | 20:33 |
| isforinsects | cnd: Checked them out, and they are supported. Are those configurable anywhere? | 20:33 |
| cnd | isforinsects, no | 20:33 |
| cnd | hopefully they don't need any configuration :) | 20:33 |
| === dandrader is now known as dandrader|afk | ||
| isforinsects | That's an odd opinion. None of these are things that I find useful. I respect that your opinion might be the majority. but I can imagine that no one else wants desktop pagination, app switching, or tab switching as gestures | 20:36 |
| cnd | isforinsects, oh, do you mean configurable as to what gesture corresponds to what action? | 20:36 |
| cnd | the answer is still that it's not configurable, but really that's a Unity issue | 20:37 |
| cnd | a design issue | 20:37 |
| isforinsects | Oh yeah. If you meant what delta values trigger things, I completely trust other's judgement in that. | 20:37 |
| cnd | ok | 20:37 |
| isforinsects | I've built unity before, do you know where they're defined in the code? | 20:37 |
| cnd | isforinsects, we are basically implementing the unity multitouch specification: https://docs.google.com/a/canonical.com/Doc?docid=0AU5sFuLRpCpBZGZra2pqY2pfMTU3MmhwbXczcWQ1 | 20:39 |
| cnd | if you have input on the designs, and whether there should be configurability, then you will want to ask the unity and/or design team | 20:39 |
| cnd | there's a mailing list for it | 20:39 |
| cnd | the problem is there are lots of lists and I don't know which is correct :) | 20:39 |
| cnd | dandrader is the person working on implementing them though | 20:40 |
| cnd | looks like he just left for the day | 20:40 |
| bregma | cnd, do you have a xorg-gtest repo with your patches already applied (they're not in http://cgit.freedesktop.org/~cndougla/xorg-gtest)? | 22:21 |
| bregma | or is the daily PPA up-to-date with the patches already applied? | 22:21 |
| cnd | oh, I haven't pushed them to my repo | 22:33 |
| cnd | I'll do that right now | 22:33 |
| cnd | bregma, pushed | 22:33 |
| cnd | they're in the fixes branch | 22:33 |
| bregma | thanks | 22:35 |
| bregma | well, I still seem to need the delay in the StartUp() function because the server isn't always ready when I am | 22:41 |
| cnd | bregma, do you mean in the fixture SetUp methods? | 22:53 |
| cnd | if so, what's the output you get | 22:55 |
| cnd | the xorg-gtest environment setup should have waited until a client can open the connection to it | 22:55 |
| bregma | I get tests randomly failing without it, not sure why without deeper delving | 23:03 |
| bregma | if I run each test standalone, it passes | 23:03 |
| bregma | I'll dig deeper | 23:04 |
| cnd | I'm upgrading my transformer and will test there too | 23:07 |
| cnd | if you need a slow machine to cause problems, it should be slow enough :) | 23:07 |
| bregma | heh, the problem seems to be the evemu file creation is taking a long time, it has nothing to do with the X server startup | 23:52 |
| bregma | fortunately, the solution to that is pretty obvious | 23:53 |
| bregma | .. XIHierarchyChanged events | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!