i have a hard time liking wayland because they're taking away remoting, which was one of my favorite parts of x.
I will abandon Linux on desktop after ~20 years if that happens. Once upon a time we had a browser with real color management (firefox)... and lost it. Now it seems that time has come to other things as well.
Not sure about the current state but there was some initiative to implement it. And as far as I know, the deliberately lean protocol will easily allow for this extension, that’s the cool part of Wayland.
Having a bunch of pixels with no knowledge of which color space they're in is useless.
Wayland thinks color management belongs in the app.
The main difference, though, is not this disagreement, but your righteous insistence that your opinion is not an opinion but a very simple obvious fact. I can tell you from having been part of many dev teams of many major app having to do color management that such apps really, really like to be in control.
So no, the lack of color management in wayland is not such an obvious wrong decision. It's debatable, with pros and cons.
At least since it wants to touch pixel data. Alternatively they could have given up on that and never introduced wl_buffer, leaving all the buffer management and drawing up to the client.
edit: At least HDR has finally made Wayland devs wake up and smell the coffee. A good write-up here[1], with ongoing talk in the merge request[2].
Lots of good work going on there, but should be part of core and not an extension. Maybe it's time for Wayland2 soon?
[1]: https://ppaalanen.blogspot.com/2020/11/developing-wayland-co...
[2]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
It is hard to get everything right at once, so starting small is not bad, imo. Wayland has a really sane way of extension querying so it is not like clients will suffer due to these — they are already written in a way to query the capabilities.
> Wayland has a really sane way of extension querying so it is not like clients will suffer due to these
A client shouldn't be able to use Wayland without considering the color space of the pixels it's providing. By not having it in core from day one, there's already apps out there which will need patching to work properly.
Here's[1] a random Wayland hello world example I found. It memcpy's the image it wants to display into a wl_buffer. What color space is that pixel data in? How can this work correctly without changes when the Wayland color management protocol lands?
[1]: https://github.com/emersion/hello-wayland/blob/master/main.c...
Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly. The existing buffer protocol could also be extended to contain information about the color space used for server-side handling of this information, though as the other commenter mentioned, it is best handled by the client, the protocol has to display it only.
On the other hand X was created ages ago. Wayland was released in 2008.
> Clients that query for this yet theoretical only color space extension can then ask the server for the color balance of the given screen and fill their buffers accordingly.
Ok, lets say that's how it's done. I set my display to AdobeRGB or BT.2020. My legacy hello world application knows nothing of this just copies its data into the buffer blissfully ignorant of this. If Wayland does nothing more than to display the pixels, the hello world image will look like crap.
Ok, let's say we patch the hello world application, and all the other existing Wayland applications, to respect the output color space. Now I plug in a second monitor which is sRGB, and drag the hello world application over on it. If the hello world application does nothing more, it looks like crap again.
For this to work, it has to be notified it's on a new screen, and fill in new pixel values for the new screen. And every application must handle this or it will look like crap.
But more asking than telling, why wouldn’t defaulting to sRGB for unlabeled buffers work? The compositor knows that this monitor is in C color space, and it knows how to convert between the two, than a simple shader can trivially convert the sRGB hello world app to the monitor’s color space - even in the multiple monitor with different spaces case.
Of course that might not be the intention of the client, but if they didn’t bother with it than they likely are okay with whatever is the default.
If Wayland is to do color management, that's a reasonable approach. Doesn't work at all if the client is supposed to do it.
But are you sure Wayland uses sRGB now? I couldn't find any information regarding the implicit color space currently used by Wayland...
> but if they didn’t bother with it than they likely are okay with whatever is the default
Not like they had a choice now is it?
However you're still in a bit of a mess due to lack of an explicitly documented implicit color space. And it's still a bit of a footgun for developers who don't know they need to care about this.
It's a bit like XML files without the encoding attribute. Except for text you can try to analyze the bytes and find a likely encoding, no such thing for pixel data.
That's a strange way to look at it. It's more like the Wayland folks decided that basically everything of import is out of scope of the protocol. This way any graphical system built on top of Wayland is ridiculously inelegant, but hey, at least there is no responsibility on Wayland itself.
I remember that episode... at some point it was basically impossible to display an image that uses the exact same color as some color used in your CSS. Lot's of logos with just the wrong. I'm sure the web platform could be extended to properly support color management in some way, but what Firefox did back than wasn't it.
In my opinion X12 should be even more modular and should have even more standardized interfaces. E.g. window decorations should not be tied to a window manager. There should be a standardized way to do toolkits/widgets where the backend and rendering can be swapped at runtime. It should be possible to run headless GUI programs that can be attached and reattached to any running instance of a display server.
So kind of the opposite of what Wayland is doing.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
John Steinhart though X-Windows could have been a hell of a lot more modular and less complex, and could have been much more simply and modularly designed and better implemented with "less than a dozen API calls":
https://news.ycombinator.com/item?id=17056516
DonHopkins on May 12, 2018 | parent | context | favorite | on: Build your own X: project-based programming tutori...
Hasn't somebody reimplemented X11 in JavaScript/canvas/websockets yet?
There was an X11 server for Lisp Machines! Not sure who wrote it, but it was probably written inside or at least nearby the X Consortium, and I remember Robert Scheifler used it regularly.
https://news.ycombinator.com/item?id=6864364
"For example the TI Explorer Lisp Machine came with an X11 server written in Lisp. On my Symbolics Lisp Machine I used the usual MIT X11 server written in C - this was possible because the Symbolics Lisp machine had a C compiler." -lispm
John Steinhart wrote XTool, a nice snappy reimplementation of X11 on top of SunView! ;)
https://minnie.tuhs.org//pipermail/tuhs/2017-September/01047...
https://news.ycombinator.com/item?id=15325226
https://web.archive.org/web/20171028110659/https://minnie.tu...
>XTool was very small and fast compared to the X sample server because I wrote the server from scratch. I think that I'm the only person to write an X server outside of the X Consortium. One of the things that I learned by doing it was that the X Consortium folks were wrong when they said that the documentation was the standard, not the sample server. There were significant differences between the two.
>The only really worthwhile thing about X was the distributed extension registration mechanism. All of the input, graphics and other crap should be moved to extension #1. That way, it won't be mandatory in conforming implementations once that stuff was obsolete. As you probably know, that's where we are today; nobody uses that stuff but it's like the corner of an Intel chip that implements the original instruction set. As an aside, I upset many when working on OpenDoc for Apple and saying the same thing there.
>The atom/property mechanism allows clients to allocate memory in the server that can never be freed. Some way to free memory needs to be added.
>The bit encodings should be part of a separate language binding, not part of the functional description.
[...]
>X suffers from the same problems as the original Mac API. Scheifler et. al. didn't really do any system level design and modelling. I know this because I discussed it with Scheifler at an ANSI meeting in Tulsa, the only place that I have travelled to on business that had no redeeming qualities. He said "I don't believe in models because they predispose the implementation."
>Had he done some real design work and looked at what others were doing he might have realized that at its core, X was a distributed database system in which operations on some of the databases have visual side-effects. I forget the exact number, but X includes around 20 different databases: atoms, properties, contexts, selections, keymaps, etc. each with their own set of API calls. As a result, the X API is wide and shallow like the Mac, and full of interesting race conditions to boot. The whole thing could have been done with less than a dozen API calls.
[...]
> Anyone is free to extend the protocol with whatever they want
The protocol itself is very opnionated and strict in some places (especially concerning things like vsync) and completely undefined in other areas where standardization is essential (access control).
https://en.wikipedia.org/wiki/NeWS
NeWS was architecturally similar to what is now called AJAX, except that NeWS coherently:
- used PostScript code instead of JavaScript for programming.
- used PostScript graphics instead of DHTML and CSS for rendering.
- used PostScript data instead of XML and JSON for data representation.
https://donhopkins.medium.com/the-x-windows-disaster-128d398...
I'm no fan of JavaScript, but even I would prefer it to PostScript.
And I actually like FORTH.
Arthur van Hoff wrote "PdB" for people who prefer object oriented C syntax to PostScript. I wrote some PdB code for HyperLook, although I preferred writing directly in PostScript.
https://news.ycombinator.com/item?id=25432748
DonHopkins on Dec 15, 2020 | parent | context | favorite | on: Source of the famous “Now you have two problems” q...
Leigh Klotz has written more PostScript than Jamie too, while working at Xerox! But "KLOTZ IS A LOGO PRIMITIVE [BEEP BEEP BEEP]". He wrote a 6502 assembler in Logo!
https://news.ycombinator.com/item?id=13524588
Leigh Klotz's comment on the regex article:
>OK, I think I’ve written more PostScript by hand than Jamie, so I assume he thinks I’m not reading this. Back in the old days, I designed a system that used incredible amounts of PostScript. One thing that made it easier for us was a C-like syntax to PS compiler, done by a fellow at the Turning Institute. We licensed it and used it heavily, and I extended it a bit to be able to handle uneven stack-armed IF, and added varieties of inheritance. The project was called PdB and eventually it folded, and the author left and went to First Person Software, where he wrote a very similar language syntax for something called Oak, and it compiled to bytecodes instead of PostScript. Oak got renamed Java.
>So there.
>And yes, we did have two problems…
>— comment by Leigh L. Klotz, Jr. on June 7th, 2008 at 3:22am JST (12 years, 6 months ago) — comment permalink
Arthur van Hoff (the author of PdB and the original Java compiler written in Java) has also written more PostScript than Jamie, especially if you count the PostScript written by programs he wrote, like PdB and GoodNeWS/HyperNeWS/HyperLook.
Here's the README file (and distribution) of PdB, Arthur van Hoff's object oriented C to PostScript compiler:
https://github.com/IanDarwin/OpenLookCDROM/blob/master/NeWS/...
Also a paper by Arthur van Hoff about "Syntactic Extensions to PdB to Support TNT Classing Mechanisms":
https://www.donhopkins.com/home/archive/NeWS/PdB.txt
Some before and after examples, like menu.h menu.pdb menu.PS:
https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.h: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.pdb: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
menu.PS: https://www.donhopkins.com/home/archive/HyperLook/Turing/hn3...
GoodNeWS/HyperNeWS/HyperLook:
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
pvg on Dec 15, 2020 | prev [–]
Arthur van Hoff (the author of PdB and the original Java compiler written in Java) And the original AWT, if this is to be a full Airing of Sins.
DonHopkins on Dec 15, 2020 | parent [–]
Agreed, AWT was a horrible compromise in an impossible situation! But he made up for it by creating "Bongo" at Marimba.
Bongo is to Java+HyperCard as HyperLook is to PostScript+HyperCard.
https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...
>Arthur van Hoff [...]
>Marimba Castanet and Bongo
>Eventually Arthur left Sun to found Marimba, where he developed the widely used Castanet push distribution technology, and the under-appreciated Bongo user interface editing tool: a HypeLook-like user interface editor written in Java, that solved the runtime scripting extension problem by actually calling the Java compiler to dynamically compile and link Java scripts.
>Nobody else had ever done anything remotely like Bongo before in Java. Dynamic scripting with Java was unheard of at the time, but since he had written the compiler, he knew the API and how the plumbing worked, so had no qualms about calling the Java compiler at runtime every time you hit the “Apply” button of a script editor.
>Danny Goodman’s “Official Marimba Guide to Bongo”
https://www.amazon.com/Official-Marimba-Guide-Bongo-Goodman/...
>Danny Goodman, the author of the definitive HyperCard book, “The Complete HyperCard Handbook”, went on to write the “Official Marimba Guide to Bongo”, a great book about Bongo, described as the “reincarnation of HyperCard on the Internet”.
>[TODO: Write about Bongo’s relationship to HyperCard, HyperLook and Java.]
>Java applets are everywhere on Web pages these days, but if you’ve made the move to Java from a contemporary programming environment you’ve probably been dismayed by its relative immaturity. The Official Marimba Guide to Bongo covers Marimba’s Bongo environment, which is designed to allow rapid development of Java user interfaces. The book shows you how to use the large library of graphics “widgets” supplied with Bongo, how to wire them together with simple scripting, and how to integrate other Java applets. It also explains how Bongo can be used to build channels for Marimba’s Castanet system. -Amazon.com Review
>Java users should be rejoicing at the promise of programming aid Bongo, which is is the reincarnation of HyperCard on the Internet. It is fitting that the first major book about Bongo comes from Goodman, the author of the definitive HyperCard book of days gone by (The Complete HyperCard Handbook, Random, 1994). His background is as a journalist, not a technologist, and readers will make good use of this first-rate introduction. This book will circulate. -Library Journal Review
Unfortunately Marimba's Bongo got overshadowed by Sun's announcement of "Java Beans" which Sun was pushing with much fanfare and handwaving as an alternative to "ActiveX", but which eventually turned out to actually be just a server side data modeling technology, not a client gui framework.
https://news.ycombinator.com/item?id=21784027
[...]
Marimba developed Bongo, a Java-based gui toolkit / user interface editor / graphical environment, inspired by HyperCard (and HyperLook), which they used to develop and distribute interactive user interfaces over Castanet.
https://people.apache.org/~jim/NewArchitect/webtech/1997/10/...
>Feel the Beat with Marimba's Bongo, By Chris Baron
>In 1996, four programmers from the original Java-development team left Sun to form Marimba and produce industrial-strength Java-development tools for user interface and application administration. Bongo, one of Marimba's two shipping products, allows developers to create either a Java-application interface or a standalone Java-based application called a "presentation." A Bongo presentation resembles a HyperCard stack -- it allows developers to quickly create an application with a sophisticated user interface, but without the tedious programming of directly coding in Java or C/C++. Bongo's nonprogramming, visual approach makes it ideal for producing simple applications that don't involve a lot of processing, such as product demonstrations, user-interface prototypes, and training applications. Bongo is fully integrated with Castanet, Marimba's other product, a technology for remotely installing and updating Java applications.
Bongo was unique at the time in that it actually let you edit and dynamically compile scripts for event handlers and "live code" at run-time (in contrast with other tools that required you to recompile and re-run the application to make changes to the user interface), which was made possible by calling back to the Java compiler (which Arthur had written before at Sun, so he knew how to integrate the compiler at runtime like a modern IDE would do). Without the ability to dynamically edit scripts at runtime (easy with an interpreted language like HyperTalk or PostScript or JavaScript, but trickier for a compiled language like Java), you can't hold a candle to HyperCard, because interactive scripting is an essential feature.
Danny Goodman, who wrote the book on HyperCard, also wrote a book about Bongo. Arthur later founded Flipboard and JauntVR, and now works at Apple.
Here's a paper I wrote comparing Bongo with IFC (Netscape's much-ballyhooped Java Internet Foundation Classes). (Notice how IFC = Internet Foundation Classes was Netscape's answer to MFC = Microsoft Foundation Classes. Never define your product's name in terms of a reaction to your widely successful competitor's name. cough SunSoft cough)
NetScape's Internet Foundation Classes and Marimba's Bongo
https://donhopkins.com/home/interval/ifc-vs-bongo.html
>In summary, I think it was too early to write a Java toolkit before JDK 1.1, so IFC has gone and done a lot of its own stuff, which will have to be drastically changed to take advantage of the new stuff. Bongo is not as far down the road of painting itself into a corner like that, and if some effort is put into it, to bring it up to date with the new facilities in Java, I think it will be a better framework than IFC. Java Beans remains a big unknown, that I don't have a lot of faith in. Arthur says Java Beans does too much, and I'm afraid it may try to push competing frameworks like IFC and Bongo out of the limelight, instead of just providing a low level substrate on top of which they can interoperate (like the TNT ClassCanvas). If Bongo can pull off ActiveX integration with style and grace, then it wins hands down, because I doubt IFC can, and I don't trust Sun to deliver on their promises to do that with Java Beans.
More:
https://news.ycombinator.com/item?id=19837817
>Wow, a blast from the past! 1996, what a year that was. [...]
HyperNeWS was definitely one of the neatest systems I have ever worked with.
Edit: I also really liked PostScript.
http://www.scotranslate.com/translate/scottish/pure-dead-bri...
>pure dead brilliant - Scottish to English : The English translation of "pure dead brilliant" is 1. exceptional 2. fantastic
I think it's what we were trying to accomplish. My work with Forth was on Apple II computers while my contact with PostScript was to make printers do things they weren't supposed to do - such as printing fractals - because, for some time, they were the most powerful computers we had at the office.
Apart from that, the syntax seemed awkward for things more complicated than rendering text in predefined positions, but, then, I didn't have any development tools similar to what was available with NeWS (when NeWS was still hot).
The original LaserWriter was actually a more powerful computer than the Macs that used it, at the time of its release.
Debugging on a laser printer definitely was a challenged, and used lots of paper.
You're right that NeWS made it a lot easier to debug PostScript code interactively without killing trees. It had a command line debugger, but was great for making visual interfaces too! Here's a visual PostScript programming and debugging environment I made with NeWS:
The Shape of PSIBER Space: PostScript Interactive Bug Eradication Routines — October 1989
Abstract
The PSIBER Space Deck is an interactive visual user interface to a graphical programming environment, the NeWS window system. It lets you display, manipulate, and navigate the data structures, programs, and processes living in the virtual memory space of NeWS. It is useful as a debugging tool, and as a hands on way to learn about programming in PostScript and NeWS.
https://donhopkins.medium.com/the-shape-of-psiber-space-octo...
"Before co-founding Marimba, [Kim] Polese spent more than seven years with Sun Microsystems and was the founding product manager for Java when it launched in 1995. She also influenced the transition of its internal name of "Oak" to "Java".[11]
"Prior to joining Sun, Polese worked on expert systems at IntelliCorp Inc., helping Fortune 500 companies apply artificial intelligence to solving complex business challenges."
Anybody remember "expert systems"?
if not, would be interesting if there were a protocol for programs to securely serve up front end resources and api endpoints for javascript guis along with a protocol for telling your machine to pop a window and display that gui.
so like the equivalent of an xserver that programs can connect to that pops browser windows and secure plumbing to support it.
export WEBDISPLAY=localhost:0 myjavascriptterminalemulator &
Wayland just realized that remoting is not an operation that has to be integrated into the protocol. It can be done by third-party applications better through proper compression techniques.
If you want to make a separate window manager, it is likely that the result is going to be incompatible with most existing clients. But this seems par for the course for almost every Wayland extension so far (see Gnome...).
And beside gnome and kde there is a third big group of wayland compositors based on wlroots which does support some form of common set of extensions not in core, effectively making you write only the wm part.
Because this prevents creation of a separate window manager program. You can do all of this with the core protocol in X11. You can't do any of it in Wayland almost by design. The entire idea of a client getting simultaneous access to the objects of another client is not in the protocol. You cannot render in another process surface. You cannot even iterate over its windows! The role of the compositor is hardcoded in the protocol design.
The closest thing you can do is to write some type of modular compositor which speaks _yet another_ protocol with the window manager module (or even exists within the same process). But this is not like in X11, where you plug new things (e.g. a new WM, a new pager) without having to restart the X server, much less having to change it.
see how it looks: https://streamable.com/t9foij
I tried steamlink on the same network to put games on my TV, and it is barely useable with absolutely horrendous image compression (got a GTX1080 GPU so that's likely not the culprit)
RDP also sends draw calls, and as such cannot be compared to VNC or similar. It's not even a remotely close comparison in terms of fluidity. I haven't compared it to Qt over X11, but I wouldn't be surprised if RDP wins over an internet link.
The lack of a proper RDP alternative is the primary reason I don't use Linux as my main driver. I keep checking every 12 months or so, but alas.
on linux with native linux apps ?
Point was that RDP in its natural environment can forward draw calls, and as such is more like X than VNC.
RDP is to X as PowerShell is to bash: better than the Unix standard thing because it isn't weighed down by Unix community baggage.
Also, you were right on RDP, but something less is more.
If any, I prefer plan9/9front's drawterm/cpu which runs circles over Unix/Linux VNC and RDP. By a huge mile.
And 9p>>>>>>>> NFS/SMB. For anything else, use FS' permissions FFS, and choose wisely what you share.
What you could do today with PSH and iPython Perl folks did that before with far more modules thanks to CPAN and C bindings.
How can this [1] code possibly be faster than modern hardware accelerated blitting? I don't see a line of SIMD in there.
[1]: https://github.com/9fans/drawterm/blob/master/libmemdraw/dra...