Wayland - Beyond X (The H)

Posted Feb 14, 2012 18:57 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Wayland - Beyond X (The H) by rqosa
Parent article: Wayland - Beyond X (The H)

I don't think anyone is dropping support for X11 although X11 will probably go on life support with few enhancements and bugfixes only. X is used on all the proprietary systems and I don't see it "going away" any time soon just because something new shows up.

to post comments

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:49 UTC (Tue) by rqosa (subscriber, #24136) [Link] (11 responses)

> I don't think anyone is dropping support for X11

By "anyone", do you mean the toolkits (GTK+, Qt, EFL, etc.)? Because that's the real problem here — using Wayland only as a drop-in replacement for window managers probably wouldn't be a very disruptive change for end-users (at least for those who have hardware that's new/fast enough to do GPU-accelerated compositing), but using Wayland as a rendering back-end for widget toolkits is bad for end-users who depend on NX / xpra / remote X11 (unless the toolkits continue to support X11 alongside Wayland).

Wayland - Beyond X (The H)

Posted Feb 14, 2012 20:56 UTC (Tue) by raven667 (subscriber, #5198) [Link] (10 responses)

Yes, that's what I mean, I don't expect X11 support to be dropped from GTK+, Qt, EFL, etc. just because those toolkits gain a Wayland output. In fact one could take advantage of Wayland when it's ready even without any direct toolkit support because X11 runs just fine on Wayland. I wouldn't be surprised if there is a long period of time where apps/toolkits are mix-n-match between X11 and Wayland native.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:13 UTC (Tue) by dlang (guest, #313) [Link]

running X apps on Wayland isn't the concern, everyone sees that this is possible today and so it's not something to bother anyone.

the problem if running a Wayland app on X (especially on a remote X display)

It's the new, small toolkits that people expect to be the problem, those are more likely to be Wayland only.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 21:51 UTC (Tue) by rqosa (subscriber, #24136) [Link] (8 responses)

> I wouldn't be surprised if there is a long period of time where apps/toolkits are mix-n-match between X11 and Wayland native.

But if the toolkits are going to drop X11 eventually, then they'd better replace it with something other than native Wayland, because a remote-proxy for native Wayland apps just can't have good performance.

Wayland - Beyond X (The H)

Posted Feb 14, 2012 22:50 UTC (Tue) by jonabbey (guest, #2736) [Link] (7 responses)

NeWS on top of Wayland? ;-)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:02 UTC (Tue) by nix (subscriber, #2304) [Link] (6 responses)

I support this feature. I would support it even more if someone would come up with a NeWS with a sane language in the server, rather than DPS :)

Wayland - Beyond X (The H)

Posted Feb 14, 2012 23:47 UTC (Tue) by rqosa (subscriber, #24136) [Link]

> NeWS with a sane language in the server

Maybe something like server-side QML / Qt Quick? (With the "server" also being a Wayland client, running on the same host as the Wayland server.)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:19 UTC (Wed) by HelloWorld (guest, #56129) [Link] (3 responses)

What's wrong with Display PostScript? After all, the Code is not meant to be written or read by humans.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:50 UTC (Wed) by rqosa (subscriber, #24136) [Link] (2 responses)

Actually, NeWS application and/or toolkit developers were required to write PostScript code. I don't know all that much about it, but the way NeWS applications were split into server-side PostScript code and client-side C code seems kind of similar to modern "declarative UI" systems like in Qt, where there is a separation between the UI components (implemented in QML/JavaScript) and the application logic (implemented in C++). (Or for that matter, similar to Web applications using XMLHttpRequest and client-side JavaScript.)

(Note: the language is PostScript, not Display PostScript; DPS was not part of NeWS, but was an X protocol extension that allowed for server-side PostScript interpretation similar to what NeWS did.)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 1:58 UTC (Wed) by HelloWorld (guest, #56129) [Link] (1 responses)

> Actually, NeWS application and/or toolkit developers were required to write PostScript code.
Really? My understanding was that toolkit developers had to write code that would then generate the PostScript code that would do the actual drawing, right? That is something very different from writing the PostScript code itself.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 2:21 UTC (Wed) by rqosa (subscriber, #24136) [Link]

Well, at least according to the Wikipedia article, "it was possible to write simple PostScript code that would result in a running, onscreen, interactive program", and "widgets ran all of their behaviour in the NeWS interpreter, and only required communications to an outside program (or more NeWS code) when the widget demanded it". And it goes on to describe the client/server architecture of modern web applications as being similar to that of NeWS, except with the JavaScript janguage in place of PostScript, DOM / HTML / the CSS box model in place of PostScript drawing commands, and JSON or XML in place of PostScript data expressions.

So, it would seem that toolkit and/or application developers did need to write PostScript, in the same way that web developers need to write JavaScript (and that Qt Quick app developers need to write QML/JavaScript).

Wayland - Beyond X (The H)

Posted Feb 16, 2012 19:11 UTC (Thu) by fuhchee (guest, #40059) [Link]

Javascript, certainly.