[00:03] <racarr> mt::TouchEventMatches(*key_event) spot the error
[00:03] <racarr> :p
[00:03] <racarr> it somehow seems more obvious out of ocntext
[00:26] <tmpRAOF> That's how these things work.
[02:01] <robert_ancell> Are there any special requirements for a client to connect to the Unity 8 Mir socket?
[02:02] <robert_ancell> I'm trying to run a test client and getting a broken pipe
[02:02] <robert_ancell> (error)
[02:08] <duflu> robert_ancell: Not entirely sure. Unity8 has always been a bit different to plain Mir
[02:09] <duflu> robert_ancell: A broken pipe might suggest there's a protocol compatibility break and you're mixing two different Mir versions..?
[02:10] <robert_ancell> 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] <robert_ancell> Some AppArmor thing must be checking the argument list...
[02:11] <duflu> robert_ancell: I remember now -- Unity8 does very odd things like checking the client's argv (!)
[02:11] <robert_ancell> That must be a "to be fixed" :)
[02:11] <duflu> robert_ancell: It's definitely strange, but someone wrote that on purpose. Not sure if it's a permanent thing
[02:12] <duflu> 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/<pid>/cmdline (IIRC)
[02:13] <robert_ancell> Yeah, my test program doesn't parse argv at all
[02:14] <duflu> 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
[08:52]  * duflu finally kills all latency and makes the hardware cursor stick to things
[12:05] <anpok_> 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] <alan_g> anpok: stop it. We need to get stuff out of throwback, not add it
[13:09] <anpok> ok
[13:10] <alan_g> 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] <anpok> alan_g: hm I slowly started to with test_client_input.cpp and added stuff to it stepwise in previous mps
[13:11] <anpok> -to
[13:12] <anpok> and removed stuff from throwback .. then 'moved' the rest with the last mp
[13:12] <alan_g> OK, just wondering
[19:36] <kdub> 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] <kdub> and I guess what I'm really pondering is if its wise to make the interfaces in mc::BufferStream public
[19:55] <racarr> kdub: I guess it was new when added? The only idea with it was to avoid
[19:55] <racarr> exposing all the stuff on mc::BufferStream where not necessary
[19:55] <racarr> as some of it is a little scary
[19:55] <kdub> right, its still scary
[19:56] <kdub> 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] <racarr> Yeah
[19:57] <kdub> 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] <racarr> Hmm thats interesting
[20:00] <racarr> and capture the request management stuff in
[20:00] <racarr> some sort of client abstraction?
[20:01] <kdub> which 'request management stuff'?
[20:01] <racarr> drop_old_buffers, drop_client_requests, force_requests_to_complete
[20:02] <kdub> ah, well those are the server's levers
[20:02] <kdub> that the client shouldn't push
[20:02] <racarr> what do you mean by mf::BufferStream as an internal client then?
[20:04] <kdub> 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] <kdub> not that i'm bringing that back anytime soon :)
[20:07] <racarr> Ah