Wayland - Beyond X (The H)

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

> 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.

to post comments

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.