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