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 539861
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Comment by stabbyjones
by renox on Wed 24th Oct 2012 11:28 UTC in reply to "RE: Comment by stabbyjones"
renox
Member since:
2005-07-06

I've seen far too much pain and suffering from Windows, where a busy app can block itself from being moved, resized, refocused, or minimized.

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.

As is, it feels as if Linux might be the only platform REgressing rather than PROgressing when it comes to not trusting applications to be perfect.


It's an either/or situation, both have advantages and drawback:
-client side decoration: looks better but can be a problem if the application is blocked and resizing can be "jerky" if the application is slow.
-server side decoration: resizing the window is smooth but the content of the window can be ugly if the application is slow, less pretty for transformed windows.

Reply Parent Score: 4

RE[3]: Comment by stabbyjones
by ssokolow on Thu 25th Oct 2012 04:29 in reply to "RE[2]: Comment by stabbyjones"
ssokolow Member since:
2010-01-21

It's an either/or situation, both have advantages and drawback:
-client side decoration: looks better but can be a problem if the application is blocked and resizing can be "jerky" if the application is slow.
-server side decoration: resizing the window is smooth but the content of the window can be ugly if the application is slow, less pretty for transformed windows.


I never really minded the desync between window borders and window contents. I considered it a necessary (and possibly even desirable) alternative to the risk of jerky resizing.

(For similar reasons to why I prefer tactile switches on a keyboard when feasible. User feedback must NEVER desync to a degree the user notices, even if that means ugliness. On a keyboard, desync means the user never builds the habit of trusting their muscle memory and must visually double-check their actions, resulting in slower interactions. With a mouse, desync means waiting to see if the system will "catch up" beyond what they intended, rather than just committing to the action as it looks at that instant.)

Hence why I'll be giving KDE 4 (or at least KWin) another chance unless I see another featureful WM promise Weston support with the option to force server-side decorations.

Let's just hope that someone will be able to patch whatever client-side decoration system wins out so that it can do the "use D-Bus to request WinDeco widgets from the WM" thing if it needs them.

(As with Canonical's AppIndicators, I think the idea of using D-Bus to have the WM draw in-border widgets is a good one and a big step forward for UI consistency... I just refuse to use apps which only support libindicator because I insist that left-click toggle application visibility and right-click show a context menu on my tray icons.)

Edited 2012-10-25 04:36 UTC

Reply Parent Score: 3

RE[4]: Comment by stabbyjones
by ssokolow on Thu 25th Oct 2012 07:38 in reply to "RE[3]: Comment by stabbyjones"
ssokolow Member since:
2010-01-21

unless I see another featureful WM promise Weston support


Ugh. You know you're posting too late at night when you conflate a protocol with its reference implementation.

"...promise Wayland support..."

Reply Parent Score: 2

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

I never really minded the desync between window borders and window contents. I considered it a necessary (and possibly even desirable) alternative to the risk of jerky resizing.


Agreed, then again IMHO what follows CSD is a BeOS-like design to have one thread of each application dedicated to the GUI, so that you can be reasonably sure that resizing will be smooth.
This is unlikely that this'll happen on Linux as it would be a big change but who knows?

Reply Parent Score: 2

RE[3]: Comment by stabbyjones
by silix on Thu 25th Oct 2012 13:43 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