- Do not add new functionality unless you know of some real application that will require it.
- It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
- The only thing worse than generalizing from one example is generalizing from no examples at all.
- If a problem is not completely understood, it is probably best to provide no solution at all.
- If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also worse is better.)
- Isolate complexity as much as possible.
- Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
Parent is probably thinking about the books in this series: https://www.amazon.com/Programming-Manual-Version-Definitive... , although the "official" X11 documentation, in the form of man pages and other docs, was pretty damn good (albeit I don't think it was 11 volumes).
Just seeing that cover brings the taste of coffee and very late nights spent at the lab back when going to bed at 2 AM and waking up at 8 AM to go to class was pretty easy.
There was a whole series. I don't remember how many volumes it had, it may have been 12 but I'm not sure. It covered a lot more than just the protocol, and it was extraordinarily comprehensive. It included pretty much everything you needed to know in order to write X11-related code.
I used to hate those eleven bloody manuals back in the day and didn't lose a single chance to complain about how the whole thing is a big designed-by-committee mess.
Count your blessings though: Wayland has pretty much no up-to-date documentation about anything except the most trivial concepts. The only reason I can do anything with it today is that I had the chance to learn it as part of my job, so I could invest 8+ hours/day in it for several weeks and read heaps upon heaps of source code (of variable quality), ask stupid questions on IRC and mailing lists, and not the least of all, attend some workshops that my employer was glad to pay for (and thank God they were 'cause there's no way I'd have spent that kind of money to learn about Wayland).
I mean, I definitely don't want to go back to writing code with the kind of technology that you can write a 12-volume manual about. Just thinking about Xlib makes me shudder. But I sure wish I had 12 volumes of information about Wayland...
I know about that book, and it certainly fills a big void (but it is an early draft -- 3-4 years ago, when I had to learn it, this wasn't around). It's good introductory material, IMHO, and it says a lot about the priorities of the companies involved in Wayland (and FOSS in general) that it's pretty much the only one of its kind, and written by a volunteer. If Wayland ever really becomes a successful desktop technology, Drew DeVault will have played an extraordinarily important role in it.
It's nowhere near the kind of documentation that X11 had, but there is also no way that is ever going to happen without serious commercial backing. The team that worked on the The Definitive Guides to the X Window System book series was probably larger than all the teams that worked on all FOSS Wayland compositors in existence -- and could work on it full-time.
I know what you mean, I learned it around 1.5 years ago and there was almost no written material at all. The way I did it was to source dive into libwayland and weston for a couple weeks. There is no coalition of big Unix vendors all putting money into it trying to build their own desktop platforms this time. It's all the embedded people shipping small devices running mostly static software stacks.
12 comments
[ 3.8 ms ] story [ 40.9 ms ] thread- It is as important to decide what a system is not as to decide what it is. Do not serve all the world's needs; rather, make the system extensible so that additional needs can be met in an upwardly compatible fashion.
- The only thing worse than generalizing from one example is generalizing from no examples at all.
- If a problem is not completely understood, it is probably best to provide no solution at all.
- If you can get 90 percent of the desired effect for 10 percent of the work, use the simpler solution. (See also worse is better.)
- Isolate complexity as much as possible.
- Provide mechanism rather than policy. In particular, place user interface policy in the clients' hands.
Just seeing that cover brings the taste of coffee and very late nights spent at the lab back when going to bed at 2 AM and waking up at 8 AM to go to class was pretty easy.
There was a whole series. I don't remember how many volumes it had, it may have been 12 but I'm not sure. It covered a lot more than just the protocol, and it was extraordinarily comprehensive. It included pretty much everything you needed to know in order to write X11-related code.
Count your blessings though: Wayland has pretty much no up-to-date documentation about anything except the most trivial concepts. The only reason I can do anything with it today is that I had the chance to learn it as part of my job, so I could invest 8+ hours/day in it for several weeks and read heaps upon heaps of source code (of variable quality), ask stupid questions on IRC and mailing lists, and not the least of all, attend some workshops that my employer was glad to pay for (and thank God they were 'cause there's no way I'd have spent that kind of money to learn about Wayland).
I mean, I definitely don't want to go back to writing code with the kind of technology that you can write a 12-volume manual about. Just thinking about Xlib makes me shudder. But I sure wish I had 12 volumes of information about Wayland...
It's nowhere near the kind of documentation that X11 had, but there is also no way that is ever going to happen without serious commercial backing. The team that worked on the The Definitive Guides to the X Window System book series was probably larger than all the teams that worked on all FOSS Wayland compositors in existence -- and could work on it full-time.
ICCCM, where are you going, stop, stop now, you have no access he-