| racarr | mt::TouchEventMatches(*key_event) spot the error | 00:03 |
|---|---|---|
| racarr | :p | 00:03 |
| racarr | it somehow seems more obvious out of ocntext | 00:03 |
| tmpRAOF | That's how these things work. | 00:26 |
| === tmpRAOF is now known as RAOF | ||
| robert_ancell | Are there any special requirements for a client to connect to the Unity 8 Mir socket? | 02:01 |
| robert_ancell | I'm trying to run a test client and getting a broken pipe | 02:02 |
| robert_ancell | (error) | 02:02 |
| duflu | robert_ancell: Not entirely sure. Unity8 has always been a bit different to plain Mir | 02:08 |
| duflu | robert_ancell: A broken pipe might suggest there's a protocol compatibility break and you're mixing two different Mir versions..? | 02:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| robert_ancell | Yeah, my test program doesn't parse argv at all | 02:13 |
| 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 | 02:14 |
| === 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 | ||
| * duflu finally kills all latency and makes the hardware cursor stick to things | 08:52 | |
| === chihchun_afk is now known as chihchun | ||
| 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:05 |
| alan_g | anpok: stop it. We need to get stuff out of throwback, not add it | 12:59 |
| anpok | ok | 13:09 |
| 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:10 |
| 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:11 |
| anpok | and removed stuff from throwback .. then 'moved' the rest with the last mp | 13:12 |
| alan_g | OK, just wondering | 13:12 |
| === 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 | ||
| kdub | racarr, i'm thinking about mf::BufferStream... was that split from mc::BufferStream or was it new when it was added? | 19:36 |
| * kdub ponders if its wise to just merge mf and mc BufferStream | 19:37 | |
| kdub | and I guess what I'm really pondering is if its wise to make the interfaces in mc::BufferStream public | 19:39 |
| === mhall119|afk is now known as mhall119 | ||
| 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:55 |
| 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:56 |
| kdub | but, mf::BufferStream is handy | 19:57 |
| * kdub has even had the thought that its a semi-internal-client (to bring that concept back :P) | 19:58 | |
| racarr | Hmm thats interesting | 20:00 |
| racarr | and capture the request management stuff in | 20:00 |
| racarr | some sort of client abstraction? | 20:00 |
| kdub | which 'request management stuff'? | 20:01 |
| racarr | drop_old_buffers, drop_client_requests, force_requests_to_complete | 20:01 |
| 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:02 |
| 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:04 |
| kdub | not that i'm bringing that back anytime soon :) | 20:06 |
| racarr | Ah | 20:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!