Linked by martini on Tue 23rd Oct 2012 22:02 UTC
X11, Window Managers Wayland 1.0 was officialy released on October 22. Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol. The compositor can be a standalone display server running on Linux kernel modesetting and evdev input devices, an X application, or a wayland client itself. The clients can be traditional applications, X servers (rootless or fullscreen) or other display servers.
Thread beginning with comment 539991
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by stabbyjones
by silix on Thu 25th Oct 2012 13:43 UTC in reply to "RE[2]: Comment by stabbyjones"
silix
Member since:
2006-03-01

Weston (like Windows now) will ping the application and if it doesn't answer will takeover the window, which will allow you to still manage the window.

the compositor is implemented to forward input events to the focused application (but before doing so owns them and can act on them arbitrarily)...
thus we could bypass heuristics and let the application normally operate on input events, but have a key combination (CTRL+ALT+... or anything you want) make the compositor kick in anyway and handle the button press on its own, without forwarding it
protocols (ping/replies) to detect busy applications seems a bit of overdesign...
as do describing the titlebar and the button position - since the compositor already has the last word wrt what is drawn on screen, and since an application's decoration to him is just another surface to composite on screen,
it could decide whether to draw the application's decoration (better, let the application draw it on its own), draw its own (which may amount to some window management buttons in a small box recognizably belonging to the compositor) on top of the application, or even replace the application drawn one - what's really needed is flagging a surface belonging to some app, as its decoration

one could argue that this leads to visual incosistencies and ugliness - not if the compositor and aplpication use the exact same decoration rendering, eg via a shared library
in that case, the compositor may draw its own decoration (or decoration part, eg the titlebar and buttons) without it being distinguishable from the normally app-drawn one..

It's an either/or situation, both have advantages and drawback:

it doesnt have to be either/or, imho...

Edited 2012-10-25 13:57 UTC

Reply Parent Score: 3

RE[4]: Comment by stabbyjones
by renox on Fri 26th Oct 2012 08:37 in reply to "RE[3]: Comment by stabbyjones"
renox Member since:
2005-07-06

I'm not sure if I totally get what you describe for resizing.. So I'll try to rephrase it: currently the application provide one buffer for the complete window (decoration plus content), you're suggesting that the application sends two buffer one for the inside and one for the decoration, so that if the server detect that the client isn't answering fast enough it can do itself the resizing?
I don't think that it would work very well..

Reply Parent Score: 2

RE[5]: Comment by stabbyjones
by silix on Fri 26th Oct 2012 11:18 in reply to "RE[4]: Comment by stabbyjones"
silix Member since:
2006-03-01

currently the application provide one buffer for the complete window (decoration plus content),

only one surface for the whole window?

correct me if i'm wrong, but i got it that surfaces are fully redrawn in response to events they are the target for
and every visual object gets assigned its own surface so as to avoid redrawing everything and all (title-/menu-/scroll-/tool-bars, widgets) whenever something happens somewhere else (especially in the actual work area, eg the canvas in a paint program)
which seemed quite inefficient..

that's why i was thinking that the compositor could do anything including replace the application's decoration on the fly - never mind...
but still, it can superimpose its own (or at least a box with its own control widgets) aligned to the app's window, without requiring a titlebar description protocol...

you're suggesting that the application sends two buffer one for the inside and one for the decoration

rather than suggesting, i was more like expecting it to be so (actually not just two, but possibly one surface per widget or - for "frame" like decorations - frame edge)
moreover, since i thought the point of compositing was to leverage the gpu's hw rendering capabilities, and surfaces are actually handles to objects in gpu memory (thus shareable at hw level), the application wouldnt "send" anything (at least not to the compositor, but to the gpu, and only when the surface needs redraw)
and, even when the decoration is affected, only that would need to be "sent"

if the server detect that the client isn't answering fast enough it can do itself the resizing?

the point was that the server shouldnt try to "detect" anything
not by pinging the application and using round trips, anyway - one could reply to a ping from the compositor in a separate thread, and the application would appear responsive even though the gui loop is busy...

giving the user the possibility to toggle to an alternate mode in which control (minimize, close etc) buttons are provided by the compositor, at any time, would be much more useful than any heuristic...

Reply Parent Score: 2