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.
Permalink for comment 539991
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