| === 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_g | anpok: @lp:1603086 I don't see any modify_surface happening with gedit on xenial. Have I misunderstood something? | 08:26 |
|---|---|---|
| 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. | 08:42 |
| anpok | alan_g: aerhm just recreating the same surface spec .. and submitting that.. | 09:47 |
| anpok | there is a chance that the old gdk backend is not doing that.. | 09:49 |
| 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:51 |
| alan_g | Which API call is "and submitting that"? | 09:54 |
| anpok | mir_surface_apply_spec | 09:54 |
| alan_g | I don't see that call to my server - I guess that's a gtk-mir change? | 09:57 |
| anpok | hm | 09:57 |
| 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:58 |
| * 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 | 09:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| 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:07 |
| 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:09 |
| 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:10 |
| * 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:11 |
| anpok | nope | 10:12 |
| 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:13 |
| alan_g | Don't waste time on it. I'd rather have a proper test. | 10:17 |
| alan_g | Anyway, we don't do tooltips according to the spec either. Try mir_demo_client_tooltip in any of our servers. | 10:21 |
| alan_g | /sigh | 10:22 |
| === chihchun is now known as chihchun_afk | ||
| 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:34 |
| anpok | I doubt the server has to handle the zone | 10:35 |
| alan_g | Unless... maybe it is to ensure that we don't place the tooltip over it? | 10:36 |
| anpok | oh | 10:37 |
| alan_g | Q: 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_g | aquarius_: 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_g | I find it best to stay that way | 10: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!