[08:26] <alan_g> anpok: @lp:1603086 I don't see any modify_surface happening with gedit on xenial. Have I misunderstood something?
[08:42] <alan_g> Hmm. I don't see a client API for that update either. So that explains why the server doesn't see a call.
[09:47] <anpok> alan_g: aerhm just recreating the same surface spec .. and submitting that..
[09:49] <anpok> there is a chance that the old gdk backend is not doing that..
[09:51] <alan_g> anpok: 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_g> *AFAICS
[09:54] <alan_g> Which API call is "and submitting that"?
[09:54] <anpok> mir_surface_apply_spec
[09:57] <alan_g> I don't see that call to my server - I guess that's a gtk-mir change?
[09:57] <anpok> hm
[09:58] <anpok> and I dont see the second position update
[09:58] <alan_g> But there's no API to position mir_surface_type_normal anyway
[09:58] <anpok> Ok my bug description is invalid
[09:59]  * alan_g thinks this feature would be better implemented as a bufferstream
[09:59] <anpok> I thought about that too
[09:59] <anpok> but that means gtk needs to be aware that the gdk backend does that.. because then the tooltip is no longer a gdk window
[10:00] <anpok> and 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:01] <anpok> alan_g: could it be that we ignore the x/y position request in tooltips for some reason?
[10:01] <alan_g> 1. it's mir_surface_type_normal; 2. mir_surface_type_tip doesn't have position properties
[10:02] <anpok> it has a rectangle?
[10:02] <anpok> alan_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_g> That's the "zone" - "A tooltip, whenever you are hovering over a particular zone."
[10:03] <anpok> oh
[10:03] <anpok> lend me a hand, that needs a triple face palm
[10:03] <alan_g> Yes, I think this API is confused
[10:04] <anpok> aquarius_: 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:06] <anpok> aquarius_: 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_g> aquarius_: 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:07] <anpok> hmm if it is supposed to show up when the ponter hovers that zone - shouldnt it also be displayed .. somewhere close to that?
[10:07] <anpok> pointer
[10:09] <alan_g> anpok: 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:10] <alan_g> But it doesn't help me test when gtk-mir sends the wrong surface type
[10:10] <anpok> yup
[10:10] <anpok> I could give you my debs
[10:10] <anpok> amd64?
[10:11]  * alan_g doesn't really want to mess with his system any more than he has already
[10:11] <anpok> hmm
[10:11] <alan_g> Actually, do you have a ppa to shove them on?
[10:11] <anpok> there is a trello card for configuring edge attachments..
[10:12] <anpok> nope
[10:13] <alan_g> nm is easy enough to write a test client. And we really should have an acceptance test
[10:13] <anpok> just figuring out how to upload that..
[10:17] <alan_g> Don't waste time on it. I'd rather have a proper test.
[10:21] <alan_g> Anyway, we don't do tooltips according to the spec either. Try mir_demo_client_tooltip in any of our servers.
[10:22] <alan_g> /sigh
[10:34] <alan_g> anpok: 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:35] <anpok> I doubt the server has to handle the zone
[10:36] <alan_g> Unless... maybe it is to ensure that we don't place the tooltip over it?
[10:37] <anpok> oh
[10:37] <alan_g> Q: should the server or the toolkit identify "hover"?
[10:53] <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:56] <alan_g> aquarius_: well, you were the one to mention shaders and damage. ;) Adding an input source ought to be (relatively) simple.
[10:57] <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:58] <alan_g> I find it best to stay that way