Linked by martini on Tue 23rd Oct 2012 22:02 UTC
Permalink for comment 539991
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2006-03-01
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 doesnt have to be either/or, imho...
Edited 2012-10-25 13:57 UTC