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 539796
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Comment by stabbyjones
by ssokolow on Wed 24th Oct 2012 01:14 UTC in reply to "Comment by stabbyjones"
ssokolow
Member since:
2010-01-21

Now that I've seen they're aiming for network transparency in some form I would really like to try it out when it starts hitting repos.

As long as I can ssh a nautilus window from home at work I'll give wayland a go.
While X is better than it was when I started using Linux, it doesn't get enough money/attention to keep up.

Hopefully wayland can keep it simple.


Agreed. With network transparency on the plans, I'm cautiously optimistic but I'll wait until I can see how good a job KWin does of ignoring clients' attempts to use client-side window decorations.

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.

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.

Edited 2012-10-24 01:21 UTC

Reply Parent Score: 3

RE[2]: Comment by stabbyjones
by renox on Wed 24th Oct 2012 11:28 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[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[2]: Comment by stabbyjones
by butters on Wed 24th Oct 2012 14:44 in reply to "RE: Comment by stabbyjones"
butters Member since:
2005-07-08

I'm not optimistic about network transparency in Wayland unless it coincides with a major push to bring network transparency to D-Bus. In fact, one could argue that Wayland should be built on top of a network-transparent message bus.

The client-server paradigm is the original sin of UNIX and everything/everybody that was influenced by it. Clients often want to talk to one another. Servers often want to talk to one another. Servers often want to make requests on clients. In modern software systems, the distinction between clients and servers often breaks down or creates artificial limitations.

This is why D-Bus (or COM in the Windows world) has become such an important architectural element of modern operating systems. Of course, it was implemented in userspace, and it wasn't until years later that anyone even thought to suggest that maybe the Linux kernel should have a native pub-sub socket type -- so ingrained is the client-server mindset.

We live in a peer-to-peer world, with peer-to-peer programming models and a fantastic peer-to-peer network architecture, and the extent to which we shoehorn this all into the client-server paradigm is shameful.

Just look at how web frameworks have evolved as crude and awkward bastardizations of the MVC pattern, which doesn't really translate from object-oriented programming to a client-server protocol like HTTP.

In both X11 and Wayland, clients aren't really pure clients, because they respond to requests from the server to handle input and exposure events. So what we're really talking about are applications of the generalized peer-to-peer message bus.

We need a first-class, network-transparent, pub-sub, multicast socket implementation in the kernel. D-Bus would be a thin abstraction of that, and since the kernel implementation would replace two expensive copy operations with a cheap page table mapping, Wayland could ride on the D-Bus without performance issues, gaining network transparency as a matter of course.

Reply Parent Score: 4

RE[3]: Comment by stabbyjones
by zima on Fri 26th Oct 2012 07:55 in reply to "RE[2]: Comment by stabbyjones"
zima Member since:
2005-07-06

So, Plan9 ideas to the rescue?

Reply Parent Score: 2