| duflu | robert_ancell: Did you notice I had a go at the strings-on-the-protocol issue? https://code.launchpad.net/~vanvugt/mir/method-index/+merge/159782 | 03:27 |
|---|---|---|
| robert_ancell | duflu, yeah, I've got a branch where I converted it to an enum | 03:27 |
| robert_ancell | duflu, the RPC code is yuck though and we could probably get away without it | 03:27 |
| duflu | robert_ancell: Yeah I think we would need to avoid strings... if we were to go to a more efficient transport in future. But not yet | 03:28 |
| robert_ancell | I am so sick of seeing "Internal compiler error: Error reporting routines re-entered. | 03:29 |
| robert_ancell | " | 03:29 |
| * duflu has never seen it | 03:29 | |
| * RAOF wonders if he should try defaulting to gcc 4.8, which doesn't suffer that. | 03:43 | |
| robert_ancell | RAOF, yes, we should if 4.8 is available and not broken | 03:46 |
| RAOF | 4.8 is available in raring, will be default in S, and isn't broken (in that way ☺) | 03:46 |
| robert_ancell | RAOF, are you sure it is in raring - it's not showing for me | 03:48 |
| RAOF | It's packaged as gcc-snapshot | 03:49 |
| robert_ancell | hmm, that doesn't sound like something we should depend on. We can shift when we go to S I guess | 03:49 |
| robert_ancell | RAOF, btw, is XMir working? I tried it on Friday and was getting the "no screens" error | 03:50 |
| RAOF | I wasn't suggesting that we default to it in the build, but locally you could easily install and use it, and not get stupid ICEs. | 03:50 |
| RAOF | XMir worked last time I tried. | 03:51 |
| RAOF | Oh, no it didn't; I need to fold in a new package. You probably don't have an xmir server installed. | 03:51 |
| robert_ancell | RAOF, I did downgrade to the latest XMir package but it wasn't connecting | 03:51 |
| RAOF | Hm. *That* did work on my machine. Let me check... | 03:52 |
| RAOF | Bah! I wish launchpad was updated to something more recent than Hardy. | 05:36 |
| RAOF | Then I could use a bzr builder recipe version 0.4, which means I could use {debver:packaging} in the version, which means I wouldn't have to change the recipe each time someone uploads xserver-xorg-video-intel to Ubuntu! | 05:38 |
| === seb128_ is now known as seb128 | ||
| === mmrazik is now known as mmrazik|otp | ||
| === mmrazik|otp is now known as mmrazik | ||
| === alan_g is now known as alan_g|afk | ||
| === alan_g|afk is now known as alan_g | ||
| kdub | good morning, status, friday worked on hwc1.0 for galaxy nexus, will continue with that today. going pretty well | 15:05 |
| kgunn | kdub: mornin' | 15:12 |
| alan_g | Good morning | 15:14 |
| alf_ | status: some performance investigations, but mostly getting laptop ready for sprint | 15:23 |
| alan_g | status: having a look through our generated documentation (and learning a bit more about doxygen) | 15:29 |
| alan_g | BTW does anyone know how frequently http://unity.ubuntu.com/mir/index.html is updated? It seems to be some days behind the trunk. | 15:30 |
| racarr_ | Morning | 15:34 |
| racarr_ | Working on touch/pointer input | 15:34 |
| === racarr_ is now known as racarr | ||
| racarr | alf_: I am workingon a software cursor and need some APIs to | 15:37 |
| racarr | damage the compositor | 15:37 |
| racarr | seperate through the renderables | 15:38 |
| racarr | to trigger rendering | 15:38 |
| racarr | any ideas? | 15:38 |
| alan_g | racarr: I think alf_ was the last one to rework that area. | 15:39 |
| alf_ | racarr: alan_g: so basically two options: 1. Pass an object to the compositor and register a notification internally (like we do for renderables currently) 2. Expose e.g. Compositor::damage() and call it when the cursor moves (that is make the cursor depend on the compositor) | 15:42 |
| racarr | Compositor::damage seems more appropriate for me because in this case | 15:42 |
| racarr | the shell is rendering the software cursor | 15:42 |
| racarr | via overriding the compositing strategy | 15:42 |
| racarr | Fixed gmock warnings on reflow-input-focus-selection | 15:44 |
| racarr | alan_g: So the crash in demo shell | 15:45 |
| racarr | is the shared_ptr to the Eventfilter which is returned via initializer_list from the server configuration | 15:46 |
| racarr | is released in the process of being passed from DefaultServerConfiguration to InputConfiguration | 15:46 |
| racarr | I can't understand it to the point where I think it might be a G++ bug | 15:46 |
| racarr | :/ | 15:46 |
| alan_g | racarr: That sounds wrong. Give me 10 and I'll have a look. | 15:47 |
| racarr | thanks :) | 15:47 |
| racarr | I think it's actually lost in the constructor of eventfilter chain (when passingfrom DefaultInputConfiguration to EventFilterChain) | 15:51 |
| racarr | but either way it makes no sense :( | 15:51 |
| kdub | alan_g, maybe thomi would know about how often the doc site is updated, i'll ask when he signs on later | 15:55 |
| alan_g | racarr: you're saying the shared_ptr to the initializer list is OK, but the one *in* the initializer list gets reset? | 16:06 |
| racarr | alan_g: Err there is a shared_ptr to the initializer list? | 16:09 |
| racarr | isn't it passed by value | 16:09 |
| racarr | what I mean is, the_input_configuration calls the_event_filters and in gdb you can observe the_event_filters returns an initializer list | 16:10 |
| racarr | with a shared_ptr as it's first member | 16:10 |
| racarr | and m_ptr as non zer0 | 16:10 |
| alan_g | racarr: sorry, misreading the code | 16:10 |
| racarr | then it gets passed to the input configuration constructor | 16:10 |
| racarr | and it also non zero | 16:10 |
| racarr | when it's passed to the EventFilterChain constructor | 16:10 |
| racarr | the initializer list is empty | 16:10 |
| racarr | and the EventFilterChain later attempts to call a method on the event filter (0x0) | 16:10 |
| racarr | well, it's not empty | 16:10 |
| racarr | it contains one member, a shared_ptr with m_ptr = 0 | 16:11 |
| racarr | alan_g: Just pushed a revision (604) which you can see fixes it by moving ownership to main | 16:16 |
| racarr | but why? | 16:16 |
| alan_g | racarr: It still doesn't make sense | 16:22 |
| racarr | alan_g: I think it has to be a GCC bug :/ I du nno | 16:28 |
| racarr | I went through with valgrind etc... | 16:28 |
| alan_g | racarr: the initializer list captures by reference, but and the reference is to a temporary std::shared_ptr<mi::EventFilter> created in the function call. Because app_switcher is a std::shared_ptr<me::ApplicationSwitcher> and needs conversion to std::shared_ptr<mi::EventFilter>. | 16:28 |
| racarr | but the initializer list | 16:29 |
| racarr | should own that reference | 16:29 |
| racarr | until it passes it to the vector of std::shared_ptr<EventFilter in EventFilterChain right? | 16:29 |
| alan_g | racarr: temporaries don't exist after you leave the enclosing scope | 16:31 |
| alan_g | I.e. return from the_event_filters() | 16:31 |
| racarr | alan_g: Then why doesn't it work if I make | 16:32 |
| racarr | the_event_filters a const member of DemoServerConfiguration | 16:32 |
| racarr | err | 16:32 |
| racarr | make std::initializer_list event_filters | 16:32 |
| racarr | a const member | 16:32 |
| racarr | and initialize it at construction time | 16:32 |
| alan_g | Because, when you exit the constructor the temporary it references goes out of scope | 16:33 |
| racarr | (not as in r604 where the list is created in main) | 16:33 |
| racarr | Hmm | 16:33 |
| alan_g | If you had a std::shared_ptr<EventFilter> member you could pass a reference to that around in the initializer list | 16:34 |
| racarr | that's what I was just going to say | 16:34 |
| racarr | do you think its better to keep it like r604 | 16:34 |
| racarr | or to keep the app_switcher in the config like it was in 603 and just use | 16:34 |
| racarr | shared_ptr EventFilter | 16:34 |
| alan_g | Using initializer lists like this might be a bad idea. ;) (I don't have the experience of them to be sure yet) | 16:35 |
| racarr | that's what I was wondering... | 16:36 |
| racarr | so I just tried | 16:36 |
| racarr | constructing the app_switcher from main | 16:36 |
| racarr | passing itto the demo server configuration (as mi::EventFilter | 16:37 |
| racarr | saving it as a shared_ptr on the demo server configuratino and returning { event_filter } | 16:37 |
| racarr | same problem | 16:37 |
| racarr | I think r604 is the way to go :p | 16:39 |
| alan_g | saving it as a shared_ptr on the demo server configuration ought to work - you didn't save a reference by mistake did you? | 16:41 |
| racarr | no, const value | 16:42 |
| === smspillaz is now known as notsmspillaz | ||
| === notsmspillaz is now known as smspillaz | ||
| === alan_g_ is now known as alan_g | ||
| bschaefer | Right now for KeyEvents I don't see a define/const saying if the key event is pressed or released for the event...besides checking if the event.action is true/false, have I missed something? | 17:39 |
| bschaefer | err, event.action 1 or 0 | 17:39 |
| bschaefer | all I see is: test/mir_test/event_factory.h:29:enum class EventAction | 17:42 |
| bschaefer | which isn't exposed to the C apis :( | 17:42 |
| racarr | bschaefer: For now you can see them in | 17:54 |
| racarr | 3rd_party/android-input/android_pristine/frameworks/native/include/android/input.h | 17:55 |
| racarr | AKEY_EVENT_ACTION | 17:55 |
| racarr | will try and get them added to a header in trunk | 17:55 |
| racarr | I tried once but people argued about if they were needed yet until I gave up :p | 17:55 |
| bschaefer | racarr, cool, yeah I had to print them out to figure out what was down/up so I can hold up and actually using a name fo ir | 17:55 |
| racarr | :) | 17:56 |
| bschaefer | racarr, yeah, well the action is an int32_t which...you can't do a nice enum with that :( | 17:56 |
| bschaefer | racarr, thanks! Also one more question while you're around :) | 17:56 |
| racarr | Sure | 17:57 |
| bschaefer | racarr, soo for the cursor, how is mir going to be handling the 'themeing' of the cursor? | 17:57 |
| bschaefer | or will that be left up to the client I suppose | 17:58 |
| racarr | I don't entirely know ;) | 17:59 |
| racarr | I guess the shell will eb responsible for the general themeing of the cursor | 17:59 |
| racarr | but there are times where the clients need to request stuff, etc. or i.e. needs to change from cursor to text cursor... | 17:59 |
| racarr | ill get back to you :p thanks for bringing that up | 17:59 |
| bschaefer | yeah, I was just digging through what Ill have to do for the mouse, and saw that SDL was making the own theme based on the video :) | 17:59 |
| racarr | bschaefer: I have a branch with a software cursor in mir but it's not uite ready to propose | 18:00 |
| bschaefer | yeah, X11 does it a bit different where you just request the cursor? (I think) and wayland was doing it a bit differently | 18:00 |
| racarr | and you need this branch to | 18:00 |
| racarr | https://code.launchpad.net/~robertcarr/mir/enable-pointer-touch-input/+merge/160153 | 18:00 |
| bschaefer | racarr, sweet, I can give it run! | 18:00 |
| racarr | receive motion events/pointer events | 18:00 |
| bschaefer | nice, I should able to mock a cursor for now and get events working :) | 18:01 |
| bschaefer | racarr, thanks! | 18:01 |
| racarr | Cool! Let me know if it works :) | 18:01 |
| bschaefer | racarr, will do! So far key events work well :) | 18:01 |
| racarr | hurrah | 18:01 |
| bschaefer | using scan codes from the events there was already a mapping of the xfree86_scancode_table2 | 18:01 |
| bschaefer | which was nice | 18:02 |
| racarr | Hmm | 18:02 |
| racarr | but then how are you getting things like | 18:02 |
| racarr | $ | 18:02 |
| racarr | as shift + 4 | 18:02 |
| racarr | or does SDL do its own mapping | 18:02 |
| bschaefer | SDL has its own mapping, but yeah I want to write some tests where it'll make sure all are working | 18:03 |
| * bschaefer checks mod events | 18:03 | |
| bschaefer | racarr, you're right, not working :) | 18:06 |
| racarr | I don't know how SDL expects it to work but my guess would be you need the keycodes -> SDL keycodes | 18:07 |
| racarr | unless SDL can listen to shift down or modifiers or whatever itself | 18:07 |
| racarr | and do the mapping | 18:07 |
| racarr | but seems best to use the mapping from mir | 18:07 |
| R__ | you guys ported SDL to mir then? | 18:07 |
| R__ | or in the process? | 18:07 |
| bschaefer | right, I need to use xkb and set the modifier, im thinking something like: xkb_state_update_mask | 18:07 |
| bschaefer | R__, in the process | 18:08 |
| R__ | I hear SDL 2.0 is getting the final blessing in May | 18:08 |
| bschaefer | racarr, theres a mapping form Mir already? Or are you talking about the xkb state from Mir? | 18:08 |
| R__ | think you'll get it merged? | 18:08 |
| bschaefer | R__, that would be nice :), well...lets hope! | 18:08 |
| bschaefer | racarr, and right, the SDL keycodes Ill have to do my own mapping now for the '$' stuff, but as along as I can get the correct keysym I should be fine | 18:10 |
| * bschaefer looks into it | 18:10 | |
| racarr | bschaefer: Well I mean the mir key"code" | 18:10 |
| bschaefer | thanks for pointing that out! | 18:10 |
| racarr | is a keysym | 18:10 |
| bschaefer | right | 18:10 |
| racarr | so if shift was down and 4 is hit the key code | 18:10 |
| racarr | will be XKB_KEY_dollar | 18:10 |
| bschaefer | oo alright, so ill have to make my own mapping of the special mod + <key> symbols | 18:11 |
| bschaefer | unless they are around somewhere | 18:11 |
| racarr | ? | 18:13 |
| racarr | the values for MirEvent::keycode are all in | 18:13 |
| racarr | xkbcommon/xkbcommon-keysyms.h | 18:13 |
| racarr | so I am guessing you can translate from like | 18:13 |
| racarr | XKB_KEY_dollar to SDL_KEY_dollar and thats all that is needed | 18:13 |
| racarr | unless that was what you meant by your own mapping :) | 18:14 |
| bschaefer | racarr, well I was just saying Ill have to do my own mapping of that stuff | 18:14 |
| bschaefer | yup | 18:14 |
| racarr | should see how the wayland backend works | 18:14 |
| bschaefer | racarr, unless theres like a magic -48 :) | 18:14 |
| racarr | they are probably doing xkb in the client | 18:14 |
| racarr | but there must be a translation somewhere | 18:14 |
| racarr | bschaefer: Not normally, though almost all xkb keysyms are unicode characters | 18:14 |
| racarr | so maybe SDL is the same way | 18:14 |
| bschaefer | right, well whats strange is they only use the scan codes for input | 18:14 |
| bschaefer | and then SDL_SendKeyboardText(text); | 18:15 |
| bschaefer | for everything else | 18:15 |
| bschaefer | soo, from what I see wayland doesn't handle sending: SDL_SendKeyboardKey of mod + <key> | 18:15 |
| bschaefer | racarr, but I need to do some more digging, im fairly new to xkb as well :) | 18:15 |
| racarr | you can use xkb_keysym_to_utf8 | 18:19 |
| racarr | to send text | 18:19 |
| racarr | it wont always return a value | 18:19 |
| racarr | i.e. KEY_left | 18:19 |
| bschaefer | yup, thats what I was planning | 18:20 |
| bschaefer | but im getting curious to why SDL_SendKeyboardKey seems to only be used w/o modifiers. From what I see they all use something similar to the scan code mapping | 18:21 |
| bschaefer | interesting... | 18:21 |
| racarr | well maybe you send shift down to SDL and then send 4 to sdl and it maps itself | 18:23 |
| racarr | I dunno | 18:23 |
| racarr | would be a little weird but not the weirdest! | 18:23 |
| racarr | but then who knows why its not working | 18:23 |
| bschaefer | that would weird, but nice ;) | 18:23 |
| bschaefer | but im not setting the mod in sdl, soo thats what im looking for | 18:23 |
| bschaefer | hmm: SDL_SetModState(SDL_Keymod modstate); | 18:23 |
| * bschaefer tires to use that | 18:23 | |
| racarr | bschaefer: You can find themodifier states in...qtubuntu/src/platforms/base/input.cc lol | 18:27 |
| racarr | I'm not sure where else oO | 18:27 |
| bschaefer | mir/include/shared/mir_toolkit/events.h is what im more or less stuck with :) | 18:28 |
| bschaefer | SDL is in C | 18:28 |
| bschaefer | and lol, a .cc file | 18:28 |
| * bschaefer looks | 18:28 | |
| racarr | bschaefer: No but I mean you can | 18:28 |
| racarr | copy them for now | 18:28 |
| racarr | and they will end up in events.h soon | 18:28 |
| bschaefer | yeah, i thought you were pointing to a header at first | 18:28 |
| bschaefer | cool, I can look at doing some of that work as well | 18:29 |
| racarr | nope just a hipster C++ file | 18:29 |
| bschaefer | haha | 18:29 |
| racarr | awesome yes :) propose away | 18:29 |
| bschaefer | racarr, thanks for all the info! That'll give me a bunch to do today :), ill also test out your cursor branch later! | 18:30 |
| racarr | Great :) np I am happy someone else is testing input | 18:33 |
| thomi | hi kdub | 19:58 |
| thomi | kdub: the docs should be uypdated daily - are they not? | 19:58 |
| thomi | kdub: more specifically, they should get updated every time something gets merged into trunk | 19:59 |
| racarr | Back from lunch :) | 20:02 |
| racarr | thomi: https://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/474/console halp | 20:07 |
| racarr | 404? | 20:07 |
| thomi | racarr: how long ago did the build fail? | 20:07 |
| racarr | uh within an hour | 20:08 |
| thomi | racarr: it takes a few minutes to publish | 20:08 |
| racarr | but I had the same problem on the first build that failed earlier | 20:08 |
| thomi | should work, let me see | 20:08 |
| thomi | racarr: got the MP link handy? | 20:09 |
| racarr | https://code.launchpad.net/~robertcarr/mir/enable-pointer-touch-input/+merge/160153 | 20:09 |
| racarr | thomi: ^ | 20:09 |
| racarr | Had just run off to get it then I got distracted by firefox | 20:09 |
| thomi | heh | 20:11 |
| thomi | that's really odd | 20:12 |
| thomi | neither the private nor the public jenkins have got to job 474 | 20:12 |
| racarr | what about their sentient jenkins love child? | 20:13 |
| racarr | hmm | 20:13 |
| racarr | I dunno. | 20:13 |
| racarr | I could resubmit the branch | 20:13 |
| thomi | racarr: do you have VPN access? | 20:13 |
| racarr | probably resets some state | 20:13 |
| racarr | yeah | 20:13 |
| thomi | racarr: the job ran | 20:14 |
| thomi | look here: http://10.97.2.10:8080/job/mir-quantal-amd64-ci/474/console | 20:14 |
| thomi | there's your problem ^^ a failed test | 20:14 |
| thomi | 93/112 Test #93: memcheck(integration-tests.AndroidInputManagerAndEventFilterDispatcherSetup.*) ...***Failed 3.98 sec | 20:14 |
| thomi | *sad trombone* | 20:14 |
| racarr | Ahhh | 20:15 |
| racarr | that isn't much of an Ahh because who knows why the test fails ;) | 20:15 |
| racarr | lets look | 20:15 |
| racarr | hmm | 20:17 |
| racarr | gtest-repeat=100 is ok locally but | 20:17 |
| racarr | that would be too easy if it were reproducable ;) | 20:17 |
| racarr | I can't reproduce the memory errors either | 20:18 |
| racarr | wish it had --track-origins=yes | 20:18 |
| racarr | (though that is slow :() | 20:18 |
| kgunn | racarr: hey, so i was chatting with dandrader | 20:20 |
| kgunn | about possibly working on input filtering from the shell | 20:20 |
| kgunn | e.g. filter edge events, pass the rest to whatever qt app is "beneath" the shell | 20:21 |
| thomi | racarr: there seems to be an issue with publishing job data from the private jenkins, we're looking into it. Until we fix it, you can just look at the private jenkins server instead | 20:21 |
| kgunn | in order to minimize any throw away & work on real integration issues | 20:21 |
| kgunn | can't we run mir w/ ubuntu touch on top ? | 20:22 |
| kgunn | we're not too early to try are we? | 20:22 |
| kgunn | racarr: kdub ^ | 20:22 |
| racarr | kgunn: Just 3 minutes :) 5 things at once | 20:22 |
| kgunn | ;) | 20:22 |
| racarr | need to write down what I am doing or I will forget something | 20:23 |
| racarr | Ok hi! | 20:25 |
| racarr | hi dandrader :) | 20:25 |
| racarr | I am going to go backwards | 20:25 |
| dandrader | racarr, hi | 20:25 |
| racarr | we can run mir w/ ubuntu touch on top, with the stuff kdub has set up (and this is continually tried) but this setup is using | 20:25 |
| * kgunn dandrader in for some racarr entertainment :) | 20:25 | |
| racarr | surface flinger with input only windows shadowing the mir surfaces | 20:26 |
| racarr | and mir input shut down | 20:26 |
| racarr | err.. | 20:26 |
| racarr | well basically? Kevin can correct me | 20:26 |
| racarr | but mir input is shut down so that configuration isn't ready for event filtering stuff | 20:26 |
| racarr | I do not think we are too early to start trying to run ubuntu touch on mir | 20:27 |
| racarr | I mean it is possible to take a Launcher.qml today and write a few hundred lines of C++ to run it in process and get it events | 20:27 |
| racarr | an event filter can be plugged in for edge events, etc for the gestures | 20:28 |
| racarr | normal events (i.e. clicked on a button) | 20:28 |
| racarr | can just go over the normal input dispatch | 20:28 |
| racarr | even though it's inprocess, it will be kind of wasteful it gets something going | 20:29 |
| racarr | There is one blocker of some sort | 20:30 |
| racarr | no in process EGL support on android | 20:30 |
| racarr | not sure how much work that is | 20:30 |
| racarr | kdub: ^ ? | 20:30 |
| kgunn | racarr: mmm, so we'd be better off just to create some event filtering scheme in absence of mir | 20:30 |
| racarr | But I mean, we can get things going on GBM | 20:30 |
| racarr | kgunn: Hmm I'm not sure I mean I think this week/next week | 20:31 |
| kdub | should have put the lunch nick on! | 20:31 |
| racarr | is the time to really get this off the ground | 20:31 |
| racarr | I'm trying to tie up a lot of loose ends now in demo shell + touch/crsor input stuff, and the basically what Mir can offer the shell for event filtering is | 20:32 |
| kgunn | racarr: right...timing...so we're kind of close enough we might need to sus up mir input w/ touch on top first | 20:32 |
| kdub | thomi, unity.ubuntu.com/mir seems to be out of sync with the doc folder | 20:32 |
| racarr | a global event filter, where it sees the raw stream and can alter/filter it/whatever | 20:32 |
| dandrader | one thing is that I would like an event canceling mechanism. | 20:32 |
| racarr | and for shell surface clients (i.e. launcher dash, etc) | 20:33 |
| racarr | they can receive events much like a regular client would (through Qt) and | 20:33 |
| racarr | handle them or not | 20:33 |
| dandrader | e.g. both shell and client application get touch events and once (if) shell recognizes a gesture it wants (out of the current touches) if would grab the gesture and the client app would be a event/gesture/touches canceled event | 20:34 |
| kgunn | dandrader: mmm, are you sure? have you considered shell _being_ the filter for both ?...i know you said replay touches expensive but shouldn't it be "gestures" not touches by then? | 20:35 |
| racarr | hmm. sounds tricky | 20:35 |
| thomi | kdub: ok, thanks - will investigate today. | 20:35 |
| racarr | what if the client has already processed the event? It can't | 20:35 |
| racarr | necessarily rewind what it has done | 20:35 |
| racarr | so there are lots of situations there where | 20:35 |
| racarr | the right thing happening is left open to a race of whomever recognizes the gesture first | 20:36 |
| racarr | there are a few cases events can be cancelled | 20:36 |
| racarr | i.e. removed by the event filter, cancelled before dispatch (by a sort of dispatch filter)...but this could allow events to go through to certain surfaces or certain shell surfaces while not allowing dispatch to | 20:36 |
| racarr | occur. | 20:37 |
| racarr | Then when events are unhandled | 20:37 |
| racarr | they can be cancelled or retargeted | 20:37 |
| racarr | I think...hmm. I think in the future if we want to get in to this sort of give client and shell event and let gesture recognizing decide who gets it | 20:38 |
| racarr | we can extend the idea of event handling with some sort of score. | 20:38 |
| dandrader | what I mean is the rationale explained here: http://lwn.net/Articles/485484/ | 20:39 |
| racarr | dandrader: This is describing sequential delivery though right? like the shell has a chance to see it and back up the stream | 20:40 |
| dandrader | although it requires an application have logic to undo whatever it has done with the events of a touch point that got cancelled (because the shell grabbed it) | 20:40 |
| racarr | then unflood them | 20:40 |
| racarr | Yes. if we could count on applications | 20:41 |
| racarr | to have that logic it would be a very cool solution | 20:41 |
| racarr | but I'm not sure it's possible. | 20:41 |
| dandrader | it's all about removing the latency involved in replaying a bunch of touch events to an application after gesture recognition is done by the shell and shell decides it does not want this touch point | 20:41 |
| kgunn | dandrader: dumb question...so is there something on the qt i/f where an app says "handled" wrt touch events/gestures? | 20:43 |
| kgunn | kgunn: it would seem you either make the shell the master, filter & replay...or you have some other detached monitoring object you can have shell & app | 20:43 |
| kgunn | dandrader: both indicate to...."i've got it" | 20:44 |
| kgunn | and avoid the replay | 20:44 |
| kgunn | while at the same time avoiding having both shell | 20:45 |
| kgunn | & app operate on the same event stream | 20:45 |
| dandrader | a similar (but simpler) situation happens when you flick a list of buttons in a touchscreen. you press over a button and it goes to pressed state, but once you start dragging your finger vertically the flickable component takes over the touch point and the button receives a cancellation event. so the button gets "unpressed" instead of released (and therefore clicked) and the list scrolls | 20:47 |
| dandrader | kgunn, no qt doesn't have that. if I understood you correctly | 20:51 |
| dandrader | but, well, gotta go. let's continue the discussion tomorrow | 20:51 |
| racarr | We can allow qt in the shell to have it perhaps though | 20:54 |
| bschaefer | racarr, sweet, receiving mouse events :) | 20:56 |
| bschaefer | racarr, also, it looks like you don't have to do the modifiers, as you are suppose to do that on the user side i guess... | 20:56 |
| bschaefer | check if the event.mod & LSHIFT && SDLK_4 works for me for '$'...strange though... | 20:57 |
| bschaefer | as how I was checking the "$" before was even failing in X11 | 20:58 |
| kdub | from the android side, if the first edition of ubuntu touch with mir underneath doesn't rely on qt, then we're ok from the graphics side | 21:00 |
| kdub | android 'in process egl' is slated in the blueprints for ubuntu-13.07: | 21:01 |
| thomi | kdub: docs uploading fixed - they should be up to date now (well, once the web cache times out anyway) - let me know if you see anything else amiss | 21:06 |
| kdub | thomi, cool, thanks! | 21:06 |
| racarr | test was failing due to uninitialize memory accidentally enabling | 21:29 |
| racarr | pointer acceleration | 21:29 |
| racarr | haha! | 21:29 |
| racarr | Comment on https://code.launchpad.net/~robertcarr/platform-api/mirclient/+merge/160217 would be really appreciated | 21:44 |
| racarr | if it seems confusing, please harass me and ask questions because a qt backend supporting input is something we need to move forward on quickly if we want to get the most out of next week :) | 21:45 |
| racarr | Also does anyone have time to check https://code.launchpad.net/~robertcarr/mir/demo-shell/+merge/159253 out? alf is on vacation so it needs another review | 21:46 |
| kdub | racarr, i'll review | 21:55 |
| racarr | kdub: thanks :) | 21:58 |
| racarr | kdub: The crash in demo shell | 22:50 |
| racarr | was due to initializer_list secretly capturing by reference | 22:50 |
| racarr | so we had an me::ApplicationSwitcher | 22:50 |
| racarr | and a temporary mi::EventFilter shared_ptr was created | 22:50 |
| racarr | for the initializer_list | 22:50 |
| racarr | then it was destroyed when the scope exited and | 22:51 |
| racarr | initializer list has a bogus reference | 22:51 |
| racarr | initializer_list is weird :p | 22:51 |
| racarr | it's fixed now due to owning the list in main | 22:51 |
| racarr | Anyone have any problem with me switching this to approved: https://code.launchpad.net/~robertcarr/mir/reflow-input-focus-selection/+merge/159225 | 23:08 |
| racarr | approve from alan + an old (addressed) needs fixing from alf | 23:08 |
| kdub | racarr, looking it over... one min | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!