[00:03] mt::TouchEventMatches(*key_event) spot the error [00:03] :p [00:03] it somehow seems more obvious out of ocntext [00:26] That's how these things work. === tmpRAOF is now known as RAOF [02:01] Are there any special requirements for a client to connect to the Unity 8 Mir socket? [02:02] I'm trying to run a test client and getting a broken pipe [02:02] (error) [02:08] robert_ancell: Not entirely sure. Unity8 has always been a bit different to plain Mir [02:09] robert_ancell: A broken pipe might suggest there's a protocol compatibility break and you're mixing two different Mir versions..? [02:10] ok, very weird. Xmir has an argument --desktop_file_hint which seems to make the connection allowed. But Xmir doesn't actually use this argument at all. If I run my test program with --desktop_file_hint it works. [02:10] Some AppArmor thing must be checking the argument list... [02:11] robert_ancell: I remember now -- Unity8 does very odd things like checking the client's argv (!) [02:11] That must be a "to be fixed" :) [02:11] robert_ancell: It's definitely strange, but someone wrote that on purpose. Not sure if it's a permanent thing [02:12] robert_ancell: The client(s) don't even need to support the --desktop_file_hint argument, just to be given it so the server Unity8 can see it in /proc//cmdline (IIRC) [02:13] Yeah, my test program doesn't parse argv at all [02:14] robert_ancell: At least one reason would be that Unity8 still uses the window title (app name) from desktop files. But it can and should use the surface name() instead === chihchun_afk is now known as chihchun === chunsang is now known as chunsang-away === chunsang-away is now known as chunsang === chihchun is now known as chihchun_afk [08:52] * duflu finally kills all latency and makes the hardware cursor stick to things === chihchun_afk is now known as chihchun [12:05] alan_g: hm i just started to merge placement applying shell into DeclarativePlacementStrategy... moved the test suite back to throwback and now plan to reuse DefaultWindowManager.. stop me now! [12:59] anpok: stop it. We need to get stuff out of throwback, not add it [13:09] ok [13:10] anpok: did you forget "bzr mv tests/acceptance-tests/throwback/test_client_input.cpp tests/acceptance-tests/test_client_input.cpp"? They look rather alike [13:11] alan_g: hm I slowly started to with test_client_input.cpp and added stuff to it stepwise in previous mps [13:11] -to [13:12] and removed stuff from throwback .. then 'moved' the rest with the last mp [13:12] OK, just wondering === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === dandrader is now known as dandrader|lunch === alan_g is now known as alan_g|EOW === dandrader|lunch is now known as dandrader === dandrader is now known as dandrader|afk === mhall119 is now known as mhall119|afk === dandrader|afk is now known as dandrader [19:36] racarr, i'm thinking about mf::BufferStream... was that split from mc::BufferStream or was it new when it was added? [19:37] * kdub ponders if its wise to just merge mf and mc BufferStream [19:39] and I guess what I'm really pondering is if its wise to make the interfaces in mc::BufferStream public === mhall119|afk is now known as mhall119 [19:55] kdub: I guess it was new when added? The only idea with it was to avoid [19:55] exposing all the stuff on mc::BufferStream where not necessary [19:55] as some of it is a little scary [19:55] right, its still scary [19:56] I think I've thought of another way to keep it internal, doesn't seem wise to make mc::BufferStream public without some intensive cleanup [19:56] Yeah [19:57] but, mf::BufferStream is handy [19:58] * kdub has even had the thought that its a semi-internal-client (to bring that concept back :P) [20:00] Hmm thats interesting [20:00] and capture the request management stuff in [20:00] some sort of client abstraction? [20:01] which 'request management stuff'? [20:01] drop_old_buffers, drop_client_requests, force_requests_to_complete [20:02] ah, well those are the server's levers [20:02] that the client shouldn't push [20:02] what do you mean by mf::BufferStream as an internal client then? [20:04] just in the sense that a server can write to a surface via the public api in the same sort of way that the removed 'internal client' could [20:06] not that i'm bringing that back anytime soon :) [20:07] Ah