On 14/04/15 01:38 AM, Giulio Camuffo wrote: > 2015-04-14 6:33 GMT+03:00 Derek Foreman <der...@osg.samsung.com>: >> On 13/04/15 07:31 PM, Daniel Stone wrote: >>> Hi, >>> >>> On 14 April 2015 at 01:02, Bryce Harrington <br...@osg.samsung.com> wrote: >>>> For purposes of discussion, an example might be rotated windows. The >>>> set geometry api takes x, y, height, and width. How would you specify >>>> rotation angle? >>> >>> The window doesn't know it's rotated. The rotation occurs as part of >>> the translation into global co-ordinate space (perhaps more than one, >>> perhaps multiple instances, etc), which the client is unaware of. If >>> it wasn't unaware of it, things like input would also be broken. >> >> It's intended to allow for the usual level of EFL/Enlightenment eye candy. >> >> I don't think having a window perpetually at a 35 degree angle is the >> intended use case - having the app know that the screen has been rotated >> so it can participate in a glorious animation sequence while its window >> is transitioning from 0 to 90 degree rotation is. > > When the output is rotated you get a geometry event with the transform > so you can animate all you want, so that use case is already covered.
Eeeh, sort of. That's kind of an after the fact signal. As an example I suspect I'm going to overuse in the coming days: If the compositor is doing some kind of window animation the drop shadows will all be wrong until the final frame when it sends the output update. For a full screen application I think that event is enough though. For a really nice example of this done right, look at an iPad's settings application after you rotate the tablet. Everything slides nicely into place. Of course, that's a full screen app... For a screen full of app windows that want to all do that at the same time things get complicated. The app would have to make a big window (axis aligned bounding box of the rotating window) and shape away parts of it with alpha? This is of course possible, but I think it could be "better" if the compositor helped out a bit... Either by informing the app of its orientation while performing the rotation, or allowing the app to set its window rotation so it could handle it itself. > >> >>>> While window rotation was used more as an example of how built-in >>>> assumptions in the API could unintentionally constrain D-E's, than as a >>>> seriously needed feature, they did describe a number of ideas for rather >>>> elaborate window behaviors: >>>> >>>> * Rotation animations with frame updates to allow widget re-layouts >>>> while the window is rotating. >>> >>> So not just animating the transition, but requesting the client >>> animate the content as well? That's extremely esoteric, and seems like >>> it belongs in a separate extension - which is possible. >> >> Nod, that may be the way we go. Raster's already expressed an interest >> in having our own efl-shell protocol for all our needs. Bryce and I are >> trying to sift through internal requirements and figure out what, if >> anything, can be shared. >> >>>> * Arbitrary shaped (non-rectangular) windows. Dynamically shaped >>>> windows. >>> >>> Entirely possible: input/opaque regions can be of arbitrary shape. >>> >>>> * Non-linear surface movement/resizing animations and transition >>>> effects. >>> >>> This seems like a compositor thing? >>> >>>> There was lots of interest in hearing more about Wayland's plans for >>>> text-cursor-position and input-method, which are necessary for Asian >>>> languages. >>> >>> It's sadly not been unmaintained for a while. >> >> I've been poking at it a bit lately and have a stack of bug fixes. I >> also think the compositor should be involved in the hide/show decision >> instead of leaving it entirely up to the client (give the client >> hide/show/auto settings...). I've got some work done in that direction >> but it's not ready for the light of day yet. >> >> I suspect this could end up in a thread of its own though. Assuming >> text protocols are still something we want in core wayland - Jasper >> seemed to indicate gnome's going its own way in this regard... >> >>>> A particular question was how clients could coordinate with >>>> the virtual keyboard input window so that it doesn't overlay where text >>>> is being inserted. >>> >>> See the text_cursor_position protocol. >> >> More than that there was talk of wanting a way for a client such as a >> vkbd to get occlusion regions for the whole screen to help it lay things >> out. >> >> And for clients in general to be able to request their own occluded >> regions so they could attempt to layout things around occluded areas. >> >>>> Security is also a top concern here, to ensure >>>> unauthorized clients can't steal keyboard input if (when) the virtual >>>> keyboard client crashes. >>> >>> The compositor is responsible for starting the input method client >>> (VKB) and directing input. Weston is already very good at isolating >>> these clients from the rest; any other compositor should follow >>> Weston's model here. >> >> I'm not sure this is a solved problem. If I read the code correctly, >> only one VKB can exist, and it would have to provide both overlay and >> keyboard functionality. It may be that we want different installable >> keyboards and overlays that can be configured at run time. >> >> I think the details of authenticating the correct keyboard should >> probably be left out of the protocol, but limiting to a single input >> provider that must do both overlay and keyboard may be worth changing at >> the protocol level? >> >> Similarly, it may be that each seat wants a different VKB provider? >> >>>> Regarding splitting out libweston, they suggested looking if a >>>> finer-grained split could be done. For example, they would be >>>> interested in utilizing a common monitor configuration codebase rather >>>> than maintaining their own. OTOH, I suspect we can do a better >>>> (simpler) API than RANDR, that doesn't expose quite so many moving parts >>>> to the D-E's, which may better address the crux of the problem here... >>> >>> RandR is a disaster of an API to expose to clients. I would suggest >>> that anything more than a list of monitors (not outputs/connectors) >>> with their resolutions, relative monitor positioning, and the ability >>> to change/disable the above, is asking for trouble. >> >> I do like the idea of hiding the concept of outputs and connectors very >> much. :) >> >> This still gets ugly in a hurry. Someone's obviously going to want to >> add a mode that doesn't show up in their EDID block... >> >>>> One area we could improve on X for output configuration is in how >>>> displays are selected for a given application's surface. A suggestion >>>> was type descriptors for outputs, such as "laptop display", >>>> "television", "projector", etc. so that surfaces could express an output >>>> type affinity. Then a movie application could request its full screen >>>> playback surface be preferentially placed on a TV-type output, while >>>> configuration tools would request being shown on a laptop-screen-type >>>> output. >>> >>> A neat idea, but a separate extension to be sure. Flipping things >>> around a bit, you might say that the application declares its type, >>> and the compositor applies smart placement depending on its type. >> >> That's much the way the internal discussion went. :) >> >>>> For screensaver inhibition, it was suggested that this be tracked >>>> per-surface, so that when the surface terminates the inhibition is >>>> removed (this is essentially what xdg-screensaver tries to do, although >>>> is specific to the client process rather than window iirc). >>> >>> Very much so. >>> >>>> They also >>>> suggested per-output blanking support so e.g. laptop lvds could be >>>> blanked but the projector be inhibited, or when watching a movie on >>>> dual-head, hyst the non-movie head powersaves off. They also suggested >>>> having a 'dim' functionality which would put the display to maximum >>>> dimness rather than blanking it completely; I'm not sure on the use case >>>> here or how easy it'd be to implement. >>> >>> If you have a per-surface inhibition API, per-output blanking becomes >>> an implementation detail. >> >> Right. And Jasper and I can continue to turn it off. :) >> >> I think the non-standard bit from this paragraph is wanting to have >> dimability (totally a real word) and blanking be separately controlled >> by a client. >> >>>> I had hoped to discuss collaboration on testing, but without specifics >>>> there didn't seem to be strong interest. One question was about >>>> collecting protocol dumps for doing stability testing or performance >>>> comparison/optimization with; while we're not doing that currently, that >>>> sounded straightforward and like it could be useful to investigate more. >>> >>> I'd like to see FITS revived, or the better bits of it moved into >>> Weston's test suite. Protocol dumps aren't particularly useful as >>> they're very dependent on things like exact file descriptors; >>> replaying a protocol dump is basically exactly what a test client >>> does. We can measure how quickly those run. >> >> Bryce is coming from the cairo world where cairo-trace dumps are a great >> way to see where an app is sucking. I don't know if WESGR fills (or >> intends to fill) this role. >> >> I think the important thing here is taking a full up application that's >> perhaps not performing as intended and having a way to diagnose that. >> Whether that's part of weston or some external protocol analyzer tool >> seems fairly unimportant though... >> >> That said, yeah... reviving FITS and or moving the better parts of it >> into weston's test suite seems like a great idea to me. :) >> _______________________________________________ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel