=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
alan_ganpok: @lp:1603086 I don't see any modify_surface happening with gedit on xenial. Have I misunderstood something?08:26
alan_gHmm. I don't see a client API for that update either. So that explains why the server doesn't see a call.08:42
anpokalan_g: aerhm just recreating the same surface spec .. and submitting that..09:47
anpokthere is a chance that the old gdk backend is not doing that..09:49
alan_ganpok: AFAICK gedit/gtk-mir creates a "normal" window (which has no placement properties) and has no way (in the mir_toolkit API) to place or move that.09:51
alan_gWhich API call is "and submitting that"?09:54
alan_gI don't see that call to my server - I guess that's a gtk-mir change?09:57
anpokand I dont see the second position update09:58
alan_gBut there's no API to position mir_surface_type_normal anyway09:58
anpokOk my bug description is invalid09:58
* alan_g thinks this feature would be better implemented as a bufferstream09:59
anpokI thought about that too09:59
anpokbut that means gtk needs to be aware that the gdk backend does that.. because then the tooltip is no longer a gdk window09:59
anpokand the input events need to be somewhat dispatched between those two..10:00
aquarius_heya, Mir peeps. I know there's been some discussion in the past about remote desktop viewing for Mir -- implementing VNC, possibly via shaders to send damage? -- and I wondered whether that discussion's moved on since last year?10:00
anpokalan_g: could it be that we ignore the x/y position request in tooltips for some reason?10:01
alan_g1. it's mir_surface_type_normal; 2. mir_surface_type_tip doesn't have position properties10:01
anpokit has a rectangle?10:02
anpokalan_g: my version sends type_tooltip - I guess because I managed to delay the construction long enough so that all necessary properties are in..10:02
alan_gThat's the "zone" - "A tooltip, whenever you are hovering over a particular zone."10:02
anpoklend me a hand, that needs a triple face palm10:03
alan_gYes, I think this API is confused10:03
anpokaquarius_: we havent done much in that area, but now there is an API that might help. But it has not been used for that purpose yet.10:04
anpokaquarius_: the wifi display support is implementing by configuring a virtual display output on the server.. the content of that virtual output then grabbed via the mirclient api for screencasting and sent off to the hardware encoder..10:06
alan_gaquarius_: nothing explicit. But some of the design discussions I've had with greyback about tracking damage for wireless display could apply. (But we're a long way from implementing any of that)10:06
anpokhmm if it is supposed to show up when the ponter hovers that zone - shouldnt it also be displayed .. somewhere close to that?10:07
alan_ganpok: Yes. *I* think this area of the spec is dubious. I also think we need a mir_surface_spec_set_attachment(MirRectangle* attachment_rect, MirEdgeAttachment edge)10:09
alan_gBut it doesn't help me test when gtk-mir sends the wrong surface type10:10
anpokI could give you my debs10:10
* alan_g doesn't really want to mess with his system any more than he has already10:11
alan_gActually, do you have a ppa to shove them on?10:11
anpokthere is a trello card for configuring edge attachments..10:11
alan_gnm is easy enough to write a test client. And we really should have an acceptance test10:13
anpokjust figuring out how to upload that..10:13
alan_gDon't waste time on it. I'd rather have a proper test.10:17
alan_gAnyway, we don't do tooltips according to the spec either. Try mir_demo_client_tooltip in any of our servers.10:21
=== chihchun is now known as chihchun_afk
alan_ganpok: I think we need new bugs. In the revised description this is no longer about repositioning a tooltip, but about creating one and correctly implementing the hover zone. (Should the server be managing that anyway?)10:34
anpokI doubt the server has to handle the zone10:35
alan_gUnless... maybe it is to ensure that we don't place the tooltip over it?10:36
alan_gQ: should the server or the toolkit identify "hover"?10:37
aquarius_anpok, alan_g: thank you! Using the stuff that wifi display uses makes sense, although that's presumably just output, and a vnc server would need to plug into the input queue as well?10:53
alan_gaquarius_: well, you were the one to mention shaders and damage. ;) Adding an input source ought to be (relatively) simple.10:56
=== hikiko is now known as hikiko|ln
aquarius_alan_g, I'm basing the shader stuff on duflu's comment in https://lists.ubuntu.com/archives/mir-devel/2015-March/001080.html :-)10:57
aquarius_myself personally, I only have the dimmest understanding of what a shader even is :)10:57
alan_gI find it best to stay that way10:58
=== hikiko|ln is now known as hikiko
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== chihchun_afk is now known as chihchun
=== dandrader is now known as dandrader|afk
=== chihchun is now known as chihchun_afk
=== dandrader|afk is now known as dandrader

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!