Why complain? Perhaps the code is obsolete and contains nothing useful, but at least we get a chance to look. And if there are useful parts, isn't it nice that they get a chance to be put to use?
This is an enormous improvement over taking obsolete stuff and hiding it forever, or even worse, destroying it! That used to be the coorporate mindset, and is extremely painful for the engineers who worked so hard on the software to see their work abandoned.
Stop complaining about a good thing. Perhaps much more valuable "obsolete" stuff might be released if we show good will (Sun's NeWS was a recent example discussed here).
That's what I meant. The MSoft *controller* understands other systems. But MSoft systems (Win2k) do not understand anything other than MSoft controller. Thus you can have a mix of clients but you *must* have a controller system made by MicroSoft.
The result is that you must make the top item in your server room a MicroSoft system if you want to use MicroSoft products at all. This is an obvious use of monopolistic power to force themselves into a market they don't control.
The obvious evil intention of MicroSoft is probably why this has generated so much foul feelings here and desire to fight them.
This is correct. No version of NeWS contained any Display PostScript code.
The orignal version of NeWS contained many improvements over PostScript. Minor things like the (very nice) ability to use null as a key in a dictionary... Another annoying thing Sun did was they started insisting on exact compatability with PostScript so they could use the NeWS core as a PostScript preview engine, and they started breaking things like this all over the place.
I worked at Sun in 1992 in the dying days of NeWS and wrote some portions of TNT (The NeWS Toolkit). Unfortunately 90% of the work I did was crap needed for X compatability.
NeWS is different and FAR superior to Display PostScript. This is because everything is done using the same API (Postscript). DPS is like OpenGL, it requires you to do all the X crap to set up windows and colormaps and visuals and serves only one purpose: to preview PostScript output.
(The NeXT machine was also better than DPS, but not quite as nice as NeWS).
NeWS main defects were an absurdly complex event model and very poor communication back from the server to the client program. (Another post here is wrong, the postscript always ran on the server.) This resulted in a desire to do everything on the server, and though the NeWS object model is quite clever, I was never really convinced that implemeting the toolkit there is really a good idea.
PostScript has problems, but I used a program called "PDB" (Postscript Done Better), which was really a compiler from a C-like syntax. (To add to Sun's stupidity we were not allowed to use this university-supplied program, because it was open source. I used it anyway and edited the output to remove the telltale comments and formatting.)
In 1986, NeWS could draw arbitary-shaped windows (including holes and multiple pieces), it could transform images with rotations and scaling and dither them to 8 bits, and it could draw outline fonts with arbitary transformations. Applications could run scaled or even rotated (!) and would (well, sort of) work, without the application knowing it! And network usage was a tenth or less than an X11 connection.
NeWS was killed because Sun's management tried to sell it. X11 source code was available for $100 for any use, Sun would not show the source code to anybody. Then when X caught on, NeWS started to slide downhill quickly, starting with an absurd attempt to merge X11 and NeWS (rather than emulating X11 atop NeWS). This was an enormous bloated mess, far slower than the previous server. Unfortunately this is what most people saw.
If Sun had given that source away for free back then, I think it would be Scott McNealy and not Bill Gates testifying against the government today!
Maybe they can still redeem themselves for one of the biggest sins in computer science history. The code is dated but it still exists. Perhaps they can release it for free today?
I was under the impression that it *didn't* work with other kerberos servers. The only standards following is that *it* works as a server. This is back compatability, not standards.
This is like claiming MSWord file format is an open standard because MSWord can import ASCII.
PS: MicroSoft must have the stupidest PR people in the world if they thought this threat was a good idea!
I'm against using text files because textfiles can be fucked up with typos and duplicate data.
Although you made other good points (I really don't see a problem with a single database file, as long as an "include" directive is supported), you must have had your head up your ass when you wrote this.
The fact that "typos" and "duplicate data" is impossible in your "binary format" is why the binary format is unusable. When I cut&paste a record and change a field, when I can write a script or editor macro to create dozens of similar records, when I can comment out a record to disable it and not lose it, and when I insert comments to say exactly why I made these changes, I am purposely making "duplicate data" and "typos". And all of these are reasons I refuse to abandon text files and text editors.
Text files are so convienent that most "binary" files, including the Windows Registry, resort to making some of the fields act like text files, with little languages and parsers. And typos there can crash just as bad.
I have read your proposal for the extensions to X and have a few comments on it. I have worked with X a great deal myself, writing 2-D graphics manipulation programs at Digital Domain, large amounts of GUI code, and a toolkit (www.fltk.org). I would be willing to help out with coding or ideas or anything, as I see the replacement of the bad parts of X as being vital to the future of it.
Certainly we NEED to replace the X rendering engine and this goes a long way. I also don't think any replacement will be accepted unless it is possible to emulate the old system atop the new one, and to emulate the new one (slowly) atop the old one, so that a gradual transition is possible. Adding things to the X protocol looks like the only way to do this.
I don't like the fact that you seem to be concerned with moving the minimal amount of drawing code to the server. I think this is wrong: I want the server to do absolutely as much as possible. We have no idea what may be hardware-accelerated in the future. I am also tired of trying to use a bunch of shared library which don't understand each other and don't cooperate to draw things.
COLOR VALUES:
I disagree with your desire to keep the pixel values and the raster ops visible. These are not needed for any modern graphics system, based on the stencil+fill model. I am also afraid that if they are not gotten rid of completely it will greately decrease performance.
On all hardware I would like to see colors directly specified (at least with 32 bit rgba numbers, perhaps other ways). The driver figures out how to represent these on the hardware. I do not believe the translation is that expensive: it is certainly cheaper for the server to do this translation because it has ONE target format, rather than having the application do it to a arbitrary target specified by the server.
8-bit hardware colormaps can be filled and the closest available color used when the map is full. This is the solution used by all toolkits today and I see no problem with moving this to the server. Filling colormaps is one of the big round-trip time wasters with X. If we added one more call indicating "I don't want this color anymore" then colormap cells can be reused without closing the connection.
For emulating old xlib programs I would have the interface claim that only a TrueColor visual is available with 8 bits of r,g,b. This will allow the deletion of all the old colormap stuff from the X server and allow great freedom in the new implementation. Programs that cannot use TrueColor are not going to be supported (this is already true for XFree86 in 16/32 bit mode so I don't see this as being a problem).
The only useful "raster op" is "XOR" and that is only useful for drawing "overlays". Exposing this prevents the server from taking advantage of real overlay hardware. I would prefer to have "draw in overlay" and "erase from overlay" added to the gc. On simple hardware these both do XOR. On more advanced hardware the overlay is used, and maybe the current color.
ALPHA COMPOSITING:
It may be important to support "premultiplied" alpha compositing, which is A+(1-alpha)*B. This form of image is often generated by 3-D rendering programs. The non-premultiplied version is actually better but the premultiplied form is so common that it must be supported.
I would also like to see non-premultiplied alpha "paint", ie you can set the current foreground color to have alpha. This does not need hardware acceleration but should be in the server.
Far better antialiasing can be achieved by taking into account the actual brightness of pixels on the screen (the screen gamma). The proper way to add screen colors is (A**(1/g)*alpha+B**(1/g)*(1-alpha))**g, where g is the screen gamma (approximately 2). I think this can be done with a lookup table?
COORDINATE SYSTEM:
I think you *should* use IEEE 32-bit numbers and put the "transformation" into the server. You must support Inf and not crash when NaN are passed in.
Using floating point is the only way I see to avoid having two clipping bottlenecks (one in the program to clip to the legal coordinate system and another in the server). Clipping is NOT as cheap as you said, as it involves calculating a new path by intersecting the lines with the edges of the clip area.
Having the transformation in the server is necessary for supporting font rasterizers and to take advantage of hardware acceleration for transforming images.
The translation inaccuracy problems you mentioned are eliminated by having a current transformation, if you seperate the current transformation into an integer translate and a fp matrix. The program can then translate so that 0,0 is on the screen and draw with very high accuracy.
It is not necessary to have a transformation stack, just setting the current transformation directly would be sufficient. However I would not complain if there was a stack.
PATHS:
I do think paths should be in the server, because otherwise people will write wrapper libraries that will be slower than doing it in the server. Like PostScript, paths are built using the current transformation, they do not move when you change transformation. This allows them to be converted immediately into trapazoids.
Characters may be drawn into the path. Since these are antialiased bitmaps from the font renderer this means the path must support antialiased bitmaps. Also current X supports the ability to add 1-bit masks to the clip and it seems likely you will have to support this for back compatability. Therefore it seems likely that the path must be an arbitrary gray-shade image (internally stored much more efficiently as a combination of images and trapazoids). This is a pain but I see no way around it.
Unlike PostScript you can probably require the program to say what it is going to do with the path before it builds it. "Stroke" for instance would be totally different and could ignore bitmaps (or draw a box around them).
"Fill" would fill the path. It may help to insert some OpenGL into here and allow the color to change as the path is built and it then did Gourand shading of the path.
"Clip" would use the path to set the clipping area, intersecting it with the current clip.
It would be real nice if a window could be created with the current path, to replace the "shape extension".
TEXT:
I do not want the Windoze-style 12-parameter call to sepecify a font, and I am afraid this is what you are suggesting. I recommend a call much like this: setfont(gc, const char* name, int attributes, float size). The "name" should be something that we are willing to show a user, like "Helvetica". The attributes are bitflags for bold, italic, etc, but in all cases the same attributes may be achieved by adding " Bold", " Italic", etc to the name and leaving the attribute zero. The size is a convienence, as the current transformation should be used to figure out the letter forms, the size temporarily scales the tranformation by that factor, sets the font, and scales it back.
The PostScript model where the size is the true "point size" MUST be used. This means the size is the minimum line spacing, not the ascent size that has been popularized by broken Windoze and Qt. This is necessary to typeopgraphy and for supporting non-Latin fonts.
Another pet peeve: can I PLEAD with you to support UTF-8 (and ONLY UTF-8) encoding! This is a standard to translate 8-bit bytes into Unicode indicies. I don't care if you draw a box for every Unicode character not in the font, just support the $#$%@ encoding! I believe there is NO need to support plain 8-bit or "wide" characters, but I know others disagree. Illegal UTF-8 sequences (including characters encoded longer than needed) should be represented by using the bytes individually. Change Unicode by replacing 0x80-0xA0 with the MicroSoft character set, because we must face the fact that they have taken control of this standard.
Measuring text for layout is a problem. Any kind of character metricies system prevents the server from doing intelligent kerning or overprinting, it also requires the application to understand UTF-8, which eliminates the whole point of UTF-8! Any other solution would look like HTML, greately limit the amount of formatting control the program has and being very complex. I think we have to give up on eliminating the round trip and recommend instead that the gc have a "current string". The program sets the string to an array of bytes and then can request the metricies of how that string would be formatted (ie the bounding box, etc). The program can then tell the server to draw the string, or it can change the string by either replacing it or truncating it to a substring. This at least eliminates the need to send the string twice and lets the server cache info it got when it measured the string.
IMAGES:
Again, I STRONGLY disagree with the conventional wisdom that the only fast way to do images is to have the program know the details of the hardware. Though true in theory, the pratical solution is to have an ENORMOUS library that can translate all possible pixel formats the program has to all possible ones that any server has. Doing this in the server is MUCH simpler, since it only has one target format, reducing the complexity from N^2 to N.
I would greatly limit the number of source formats to ones that are needed by modern programs. This means ONLY these:
"native" : a single format the server likes, much like X is now. 1-bit black & white 8-bit gray level 8,8,8 full color RGB 8,8,8 full color BGR 8,8,8,8 full color with alpha non-premultiplied RGBA 8,8,8,8 full color with alpha non-premultiplied ABGR 8,8,8,8 full color with alpha premultiplied RGBA 8,8,8,8 full color with alpha premultiplied ABGR
Just so people won't scream about my color limitations, also support 8*2^n bits per color, though this can be done by skipping the low-order bytes for now.
The recommended call is this (or a seperate call for each format):
draw_image(int format, const char* data, x,y,w,h,delta,linedelta)
x,y define a position in the current coordinate system for the upper-left corner. w,h define the width & height of pixels to draw. Delta is the data increment between pixels (this allows other pixel data to be skipped, or the red channel to be drawn monochrome). Linedelta is the data increment between lines, this allows arbitrary subrectangles of an image to be drawn. Both delta and linedelta may be negative to flip or rotate the image.
It may also be useful to send raw jpeg or png data to the server and let it be decoded there. This has obvious benefits for a network, and also eliminates another need for many programs to link in another library.
OTHER FIXES TO X:
Make a new type of "gc" that includes the damn window! It is ridiculous that we have to send both the window and gc to all the calls. Deletion of the window id would also shorten the protocol (it is vital that the window be changable with a setWindow call, the lack of this makes the Win32 gc's nearly useless).
Add a call that can define a huge array of atoms with a single protocol request and a single round trip. This along with the elimination of colormaps would get rid of most of the startup delay of X programs.
Fix the X protocol so there is a symbol sent when an application is waiting for events (actually it would be sent by XFlush if the buffer is not empty). This would allow servers to synchronize updates with vertical retrace, do double buffering, and consolidate mouse events. It would also allow synchonrization with the X window managers: one real annoyance with X is that you cannot map a window and immediately draw into it, this looks horrible to programmers used to Windoze and almost certainly needs to be fixed before they will be willing to work on X.
What bothers me is that the *only* term for "enthusiastic programmer" has been deleted from the language. There is *no* other word to refer to what we do. Or at least I can't think of one.
I think what bothers people here is the rather Orwellian aspect of having themselves deleted from public thought by removing the word used to name them.
This is incorrect. The Athena widget set was supposed to be a demonstration of Xt (the X toolkit intrinsics), which was an attempt to provide a widget framework. Most people think Xt is Motif but in fact the original idea was that Motif, Athena, and other toolkits would be build atop Xt. I remember reading design documents for Xt in 1984, and Athena was already implemented.
I believe the odd behavior of the buttons is because there are no arrows on the scrollbars and they used two mouse buttons to click them up and down. It is also possible that the Lisp machines in use at MIT did this (I do remember they had scrollbars). Somehow the line up/down got mutated to page up/down, this was later and possibly in response to the Mac's page up/down. I would say that those scrollbars were about the worst possible example of user-unintuitivity and it seems hard to believe they still remain (but they do, in Emacs...)
Xt is in fact a horrid mess itself, about 50% responsible for the disasters in Motif. For this reason I totally disagree with people who say a widget-framework should have been built into X. Such a framework would have been some horrid bad design like Xt and we would be forced to use it! X's innovation is not that it is well designed, but that the designers had the sense and humility to realize that perhaps some stuff could be done by the application!
AWT uses native widgets, so they ARE hardware accelerated, since windows video cards optimize for the common widgets.
I'm sorry, but it is you that have no clue. The widgets have been dissected down to rectangles and lines and characters long before they reach the hardware. This in on Win32 and X, and probably every other modern system in existence.
In fact it can be easily shown that a window drawn using simple Win32 GDI calls (like fill rectangle) that looks identical to one drawn with Win32 API widgets will update much faster.
Sigma knows the kernel can be hacked to expose the internals of a driver
Why do they think this won't be done with Windoze? Isn't DeCSS due to somebody examining the inner workings of a Windoze driver?
If MPAA wants CSS to work, they have to do it in the hardware. The video signal would come out a seperate cable that plugs into the display card that inserts it into the display, probably by using color-keying and an origin that is set by software. They also have to get the display card manufacturers to agree to add MacroVision to any video out signal if this input is enabled.
They have to realize that if the method of descrambling the disk, or the descrambled data itself, is ever in bytes in memory that a hacker can read, their code will be cracked. They can't have both cheap hardware and security.
If they do this, they should have absolutely no qualms about open-source drivers, since the driver is no more powerful than a remote control for a DVD player.
Yes, instant-on is *good* for a system that does not crash as often. Mostly the system is unaware that the machine was turned off, so it is actually running for a very long time.
I was wondering why we cannot do that right now. Can't the whole memory be put into the swap partition on shutdown, and some special version of LILO just restore it? I would think the time to swap in 100M from the disk would be pretty small. Biggest problem is that all the hardware has to be reinitialized, I guess new "poweroff/on" signals have to be sent to every process and a whole lot of programs and drivers need to be rewritten to reinit hardware on these signals. I can also see these being so badly written that in fact the "instant-on" is no longer instant, as each takes many seconds to reinit...
This will have almost miniscule effect on rebooting. The typical application spends most of it's time "initializing", not swapping in stuff from disk.
The focus follows mouse can be done by changing something in the registry with reg-edit.
But to refute your point, it does not really work. Clicking on a button in a window raises it, which (for me, at least) defeats most of the usability of focus-follows-mouse. Even stranger, popping up a menu does not raise the window, but it raises when you release the mouse. And what always kills me is that if you click the border to raise the window, and then decide to move the window, it takes your second click as a double-click and maximizes the window! All of these are indications of this being a quick hack stuck atop the system by somebody who cannot rewrite the lower levels correctly.
The byte produced by MicroSoft word is actually in the range 0x80-0x9F. The real Unicode character would be greater than 0xFF. The official Unicode spec says these are the "C1 control characters". MicroSoft has actually invented non-standard meanings for these bytes, since it was much easier than supporting UTF-8 to get these symbols into their 8-bit programs.
However I would not be too hard on MicroSoft, because:
This "C1 reserved area" is an ancient back-compatability hack to avoid accidentally producing control characters on systems that strip off the high bit. We should not be making stupid standards just for back compatability with obsolete equipment!
MicroSoft has used these values to encode typographic symbols that real people really, really, want!. They did not use them for more obscure letters. This encoding serves far more people than almost any of the Unicode pages.
NetScape and Unix still stink when handling UTF-8. They just display question marks. At least MSoft displays a square box, and it even correctly displays all codes that are in the 0-0xff range or are in the Symbols character set.
I very much recommend that the Linux/Unix/Unicode world swallow their pride and adopt the MicroSoft assignments for the characters in the range 0x80-0x9F as part of the Unicode standard, and that everybody (X and the console) fix their fonts to display these characters as soon as possible!!!
I would complain though about MicroSoft's "smart" quotes. It changes apostrophe into a single-close quote character. This is wrong, they should leave it an apostrophe. This breaks all search engines and keywording of files! The text ``this isn't quoted'' should display as ?this isn't quoted' on NetScape, not ?this isn?t quoted?.
Don't be an idiot. It takes FAR LESS code to implement an entire GUI library than to write some sort of layer that can go atop existing libraries. Believe me, I have done both.
I actually would prefer to see Netscape be pixel-identical on every platform (probably with a Windoze-style interface to make the masses happy). If there is "themeing" it should also work the same on all platforms, though I also think that Slashdot geeks way overestimate the appeal of themes to the average user (Windoze has had the ability to change the window color since version 3.0, yet almost no non-geek users do this. Customization is limited to changing the desktop image. If you don't believe me, take a look at a real business office and the Windoze machines on each person's desk).
Judging by the comments ("html rendering is fast but the menus are slow") it sounds like Mozilla/Netscape botched this. There is no excuse for the slow gui. I thought they were using GTK, which is pretty fast. However it now sounds like they put some sort of wrapper above it so they can use something different on Windoze and that resulted in this horrid behavior.
Re:COmpetition? There is no competition!
on
1.4-1.6 GHz Alphas
·
· Score: 1
Our 3 year old alphas (only 300mhz) are easily within 2% of our newest 550mhz Pentium machines. This is for floating-point-intensive work, but also lots of file i/o. The code is compiled with both gcc and MSVC++ (both 3 years old as well), compared with code compiled with a very new MSVC++ on the Intel machines.
I also got a chance to try a 1ghz Alpha, running Linux. Code compiled with (new) gcc was easily 3-4 times faster than a 550 mhz Intel code compiled with the newest MSVC++.
Re:How do we explain the problem to the public?
on
More on LinDVD
·
· Score: 1
Threaten them with the types of things the companies can do, even if they use Windoze, because they have complete control over the playback programs.
1. They can force you to watch (or wait through) the FBI notice and the "coming attractions", as fast-forward won't work.
2. They can make the disk not play back unless your modem is used to call their company and a small fee is deducted from your visa account for each play.
3. You cannot play Japanese disks on your American machine, and vice/versa. You cannot trade your disks with your friends in Europe.
4. You cannot record any of the disk to a vcr, or edit it into your home movies as a gag.
There is no "right hand rule". If we were left-handed we would probably define the angular momentum vector as pointing in the opposite direction and there would be a "left hand rule".
Angular momemntum is just a convienent way to represent the constantly-changing linear momentum of all the particles in the top. If the forces holding the top together were to suddenly fail so that it turned into particles, they would all travel in straight lines outward in their current linear momentum, none of the particles would have any "memory" of some angular momentum.
A clockwise spinning top will precess in exactly the same way (except mirrored) as a counter-clockwise spinning top. There is nothing different. If we used a "left hand rule math" we would get the *SAME* precession (no, it would NOT go in the opposite direction unless the top was also going in the opposite direction).
Psueudo-science is often based on taking some technical shortcut term and pretending it is literal.
I would say a problem with the Unix design was that they insisted on a "what key does this" control, rather than a "what does this key do" control.
The terminal driver only allowed one code to delete backwards a character, so it had to be either ^H or ^? (or #, which I have never seen, but I do remember teletypes where it was '_' (underscore) which actually was a backarrow in the earliest versions of ASCII).
If the keyboard driver instead translated keys to "what they do", it would have been trivial to have both ^H and ^? work.
Quite seriously, they should chuck all this obsolete stuff from the terminal driver. Just hard-code everything into the driver so it works for the maximum number of people. The most common usages don't intersect (for instance nobody uses ^H for anything other than backspace) so just merge the most common settings. Off the top of my head:
^C, ^\ - interrupt
^H, ^? - backspace
^U, ^[ - erase the line
^D, ^Z - eof
^V, ^Q - quote next
^W - erase backwards word
^R, ^L - redraw the line
I would almost suggest that the terminals be in raw mode all the time and that we rely on readline libraries, but I can see this breaking things. Another possibility is to put this sort of editing into the FILE library.
Under XFree86 the numeric keypad works just like you define it if NumLock is turned off. I don't think I have seen any programs where this did not work, I'd like you to point one out. I just tried Netscape right now.
There is a failure though when NumLock is on. The idea of "NumLock" is pretty bogus, when you think about it, it dates back to the original IBM PC, where they were too cheap to put seperate function keys. In X this the NumLock bit is stored as a shift flag, but the basic X design was that the shift flags were things like Shift, Alt, and Ctrl: the fact that they were on probably meant something, and the user was holding them down on purpose. Therefore a lot of programs think that *any* shift key being on makes the keys being typed "special" and that they should be not be treated as letters. This is the source of the common X bug, especially with Motif programs, where *nothing* works when NumLock is turned on. Modern X programs seem to ignore all shift bits that they are not interested in, this is a better solution.
Anyways it would be nice if this problem goes away, but I think it should go away by getting rid of the whole "NumLock" concept, I mean it is painfully obsolete and just a hack for a forgotten keyboard layout. If the function keys are in the "ideal arrangement" there, then the main arrow and functions should be in that arrangement. We should get rid of NumLock.
And on Win32, bit 24 of the lParam of the keyboard event can be used to tell the normal function keys from the "NumLock-off" ones.
I don't want a "Linux" keyboard either, with Penguins on the keyboard. Am I supposed to tell people to type "Penguin-X"?
How about a "Hackers" keyboard that has (in order of importance):
1. Put the word "Meta" on the "windoze" keys
2. Put the word "Ctrl" on the "caps lock" key.
3. Put the word "Super" on the two current control keys.
4. Put the word "Menu" or "Hyper" on the "windoze menu key".
5. Get rid of the arrow, home, etc symbols on the numeric keypad, and make the key marked with "NumLock" say something else (comma?).
6. Make the three keys with PrintScrn, etc say F13, F14, F15.
7. Make all the labels on the function keys, especially the Fn keys, MUCH larger, at least as large as the capital letters, so they can be read at a distance. Get rid of all the arrow logos on the tab, shift, and Enter keys. The arrow keys should have nice bold triangles on them.
8. Make the labels for the leds be 1,2,3 or A,B,C, or something. Since I have deleted numlock, caps lock, and scrolllock, they don't need to show keyboard state, so this allows them to be more easily used by a program.
9. If you want to call it a "Linux" keyboard, print your company logo and "Linux Keyboard" in the corner.
Some X programming is necessary to make this work, especially to get rid of "num lock", but no hardware changes are necessary except for changing labels, so a keyboard manufacturer could probably do this easily. If the keyboard manufacturer is willing to do hardware modifications than some of the buttons can be electronically switched and new scan codes produced for all the keys with new labels. You could also delete the keys I called "Super" and "Hyper" above and make the space key much wider. You could also delete the LED's entirely. And use an upside-down T for the arrows (Windoze users would appreciate this, too!).
Direct PostScript as implemented on the NeXT is an excellent example of what is needed. (Do not confuse this with X DPS, which is more like an extension and does not solve anything, on the Next everything, including window creation, was in the postscript stream).
Main changes I would make to the NeWS:
1. Add 3d (openGL) and antialiasing
2. Do alpha correctly by making alpha part of the current color, rather than having the "compositing modes".
3. Get rid of "layer numbers" in the server. This was the only bit of GUI in the server, and there was absolutely no reason for it, as the toolkit could emulate it easily.
Document and support the postscript interface, rather than trying to force everybody to use NeXTStep (ie same complaint I have about Qt or MFC being the interface).
A perhaps better example is NeWS. In this the windowing was much better integrated into the PostScript. They did depend too much on executing the GUI on the server, though, but otherwise was a much cleaner design.
In both cases lots of operations were noticably faster than X, despite the "overhead" of the buffering and the PostScript interpreter. And NeWS allowed me to rotate and scale an application and it still worked! Nobody is even trying that now...
We need to replace X. Anybody who thinks otherwise is totally ignorant of how bad it is.
But I don't want to see a "toolkit" interface as the low-level API. This will completely freeze all gui devlopment. It will also make Linux much harder to "hacker" program and will make it less fun. If I am forced to use Qt, I might as well use MFC and Direct X.
What we need is a true replacement for X that keeps the (few) good ideas of X:
A networked, buffered protocol. Despite claims above, this is more efficient than a call-based API. There has to be context switches, unless we want to allow the programs to write and peek at each other's windows and to be able to clobber the video registers. The way to keep the context switches down is to buffer requests. Nice simple buffering at a low level, and we get an efficient interface, and we get networked transparency for "free" (rather than having to add it on, as MicroSoft is feverishly trying to do right now...)
The server does not have to do any "GUI" things. X design is 20 years old, yet it is obvious that it can draw all the GUI components ever invented (like we can copy Windoze quite exactly, and that was not a design criteria when X was made). I do not want a server that has any concept of a "menu" or "button". That is bloat. Put it in the user-level library (much like Qt and GTK are now). I really really fear Qt becoming the standard interface, even MicroSoft was smart enough to not cram MFC down everybody.
The server does need advanced graphics capabilities. Here the opposite is obvious: X obviously cannot duplicate new ideas. We have seen antialiasing for years now and X cannot do it. 3D requires a whole new interface (OpenGL) that does not interact well with the rest (it does not use X gc's or colors, for instance). And way too many programs "work" by creating a local image buffer, doing all the work there (thus losing all hardware acceleration), and drawing the image.
I envision a server much like X, but with graphics capabilities like a combination of PostScript and OpenGL (plus antialiased everything, like Flash, and 4-channel images, and transparent paint, and UTF-8 text).
It seperates programs into arbitrary-shaped "windows" (perhaps with transparency) and does not allow one program to draw in another's "window" or intercept events to another's "window". But except for that it is "GUI stupid". It must deliver raw events to the clients and make absolutely no assumptions about anything, for instance a "window" does not mean it has a border.
Once again, I don't blame the "network transparency" or the client/server architecture.
The problem is HORRIBLE Xlib design.
Lets see how you draw a red dot on the screen in Xlib:
1. fill in an XColor structure with the r,g,b and call XAllocColor (1 round trip to server). (this could fail, in which case you have to do hundreds of round trips to find the closest color or make a new colormap, but I'll ingore that to be fair).
2. Create a "gc" (probably 0 round trips in modern Xlib? But info is sent to the server).
3. Set the foreground color in that gc (probably done locally).
4. Do XPutPixel, passing that gc and the window over the wire. (more info sent to server)
Now lets see what the calls would be in an interface designed by a semi-talented monkey:
1. "set_color(r,g,b)": info sent to server. Size of info: 3 bytes.
2. "draw_pixel(x,y)": info sent to server, size of info: 2 numbers.
3. DONE! Total number of round trips: ZERO. And I suspect the amount of info is about 1/4 as much sent over the wire, so the buffer fills up only 1/4 as often. Overall improvement in efficiency: perhaps 10,000 or more, depending on the overhead of a round trip.
Slashdot Mirror
Notepad has a file size limit that can probably be considered a bug.
This is an enormous improvement over taking obsolete stuff and hiding it forever, or even worse, destroying it! That used to be the coorporate mindset, and is extremely painful for the engineers who worked so hard on the software to see their work abandoned.
Stop complaining about a good thing. Perhaps much more valuable "obsolete" stuff might be released if we show good will (Sun's NeWS was a recent example discussed here).
The result is that you must make the top item in your server room a MicroSoft system if you want to use MicroSoft products at all. This is an obvious use of monopolistic power to force themselves into a market they don't control.
The obvious evil intention of MicroSoft is probably why this has generated so much foul feelings here and desire to fight them.
The orignal version of NeWS contained many improvements over PostScript. Minor things like the (very nice) ability to use null as a key in a dictionary... Another annoying thing Sun did was they started insisting on exact compatability with PostScript so they could use the NeWS core as a PostScript preview engine, and they started breaking things like this all over the place.
NeWS is different and FAR superior to Display PostScript. This is because everything is done using the same API (Postscript). DPS is like OpenGL, it requires you to do all the X crap to set up windows and colormaps and visuals and serves only one purpose: to preview PostScript output.
(The NeXT machine was also better than DPS, but not quite as nice as NeWS).
NeWS main defects were an absurdly complex event model and very poor communication back from the server to the client program. (Another post here is wrong, the postscript always ran on the server.) This resulted in a desire to do everything on the server, and though the NeWS object model is quite clever, I was never really convinced that implemeting the toolkit there is really a good idea.
PostScript has problems, but I used a program called "PDB" (Postscript Done Better), which was really a compiler from a C-like syntax. (To add to Sun's stupidity we were not allowed to use this university-supplied program, because it was open source. I used it anyway and edited the output to remove the telltale comments and formatting.)
In 1986, NeWS could draw arbitary-shaped windows (including holes and multiple pieces), it could transform images with rotations and scaling and dither them to 8 bits, and it could draw outline fonts with arbitary transformations. Applications could run scaled or even rotated (!) and would (well, sort of) work, without the application knowing it! And network usage was a tenth or less than an X11 connection.
NeWS was killed because Sun's management tried to sell it. X11 source code was available for $100 for any use, Sun would not show the source code to anybody. Then when X caught on, NeWS started to slide downhill quickly, starting with an absurd attempt to merge X11 and NeWS (rather than emulating X11 atop NeWS). This was an enormous bloated mess, far slower than the previous server. Unfortunately this is what most people saw.
If Sun had given that source away for free back then, I think it would be Scott McNealy and not Bill Gates testifying against the government today!
Maybe they can still redeem themselves for one of the biggest sins in computer science history. The code is dated but it still exists. Perhaps they can release it for free today?
This is like claiming MSWord file format is an open standard because MSWord can import ASCII.
PS: MicroSoft must have the stupidest PR people in the world if they thought this threat was a good idea!
Although you made other good points (I really don't see a problem with a single database file, as long as an "include" directive is supported), you must have had your head up your ass when you wrote this.
The fact that "typos" and "duplicate data" is impossible in your "binary format" is why the binary format is unusable. When I cut&paste a record and change a field, when I can write a script or editor macro to create dozens of similar records, when I can comment out a record to disable it and not lose it, and when I insert comments to say exactly why I made these changes, I am purposely making "duplicate data" and "typos". And all of these are reasons I refuse to abandon text files and text editors.
Text files are so convienent that most "binary" files, including the Windows Registry, resort to making some of the fields act like text files, with little languages and parsers. And typos there can crash just as bad.
I have read your proposal for the extensions to X and have a few
comments on it. I have worked with X a great deal myself, writing 2-D
graphics manipulation programs at Digital Domain, large amounts of GUI
code, and a toolkit (www.fltk.org). I would be willing to help out
with coding or ideas or anything, as I see the replacement of the bad
parts of X as being vital to the future of it.
Certainly we NEED to replace the X rendering engine and this goes a
long way. I also don't think any replacement will be accepted unless
it is possible to emulate the old system atop the new one, and to
emulate the new one (slowly) atop the old one, so that a gradual
transition is possible. Adding things to the X protocol looks like
the only way to do this.
I don't like the fact that you seem to be concerned with moving the
minimal amount of drawing code to the server. I think this is wrong:
I want the server to do absolutely as much as possible. We have no
idea what may be hardware-accelerated in the future. I am also tired
of trying to use a bunch of shared library which don't understand each
other and don't cooperate to draw things.
COLOR VALUES:
I disagree with your desire to keep the pixel values and the raster
ops visible. These are not needed for any modern graphics system,
based on the stencil+fill model. I am also afraid that if they are
not gotten rid of completely it will greately decrease performance.
On all hardware I would like to see colors directly specified (at
least with 32 bit rgba numbers, perhaps other ways). The driver
figures out how to represent these on the hardware. I do not believe
the translation is that expensive: it is certainly cheaper for the
server to do this translation because it has ONE target format, rather
than having the application do it to a arbitrary target specified by
the server.
8-bit hardware colormaps can be filled and the closest available color
used when the map is full. This is the solution used by all toolkits
today and I see no problem with moving this to the server. Filling
colormaps is one of the big round-trip time wasters with X. If we
added one more call indicating "I don't want this color anymore" then
colormap cells can be reused without closing the connection.
For emulating old xlib programs I would have the interface claim that
only a TrueColor visual is available with 8 bits of r,g,b. This will
allow the deletion of all the old colormap stuff from the X server and
allow great freedom in the new implementation. Programs that cannot
use TrueColor are not going to be supported (this is already true for
XFree86 in 16/32 bit mode so I don't see this as being a problem).
The only useful "raster op" is "XOR" and that is only useful for
drawing "overlays". Exposing this prevents the server from taking
advantage of real overlay hardware. I would prefer to have "draw in
overlay" and "erase from overlay" added to the gc. On simple hardware
these both do XOR. On more advanced hardware the overlay is used, and
maybe the current color.
ALPHA COMPOSITING:
It may be important to support "premultiplied" alpha compositing,
which is A+(1-alpha)*B. This form of image is often generated by 3-D
rendering programs. The non-premultiplied version is actually better
but the premultiplied form is so common that it must be supported.
I would also like to see non-premultiplied alpha "paint", ie you can
set the current foreground color to have alpha. This does not need
hardware acceleration but should be in the server.
Far better antialiasing can be achieved by taking into account the
actual brightness of pixels on the screen (the screen gamma). The
proper way to add screen colors is (A**(1/g)*alpha+B**(1/g)*(1-alpha))**g,
where g is the screen gamma (approximately 2). I think this can be
done with a lookup table?
COORDINATE SYSTEM:
I think you *should* use IEEE 32-bit numbers and put the
"transformation" into the server. You must support Inf and not crash
when NaN are passed in.
Using floating point is the only way I see to avoid having two
clipping bottlenecks (one in the program to clip to the legal
coordinate system and another in the server). Clipping is NOT as
cheap as you said, as it involves calculating a new path by
intersecting the lines with the edges of the clip area.
Having the transformation in the server is necessary for supporting
font rasterizers and to take advantage of hardware acceleration for
transforming images.
The translation inaccuracy problems you mentioned are eliminated by
having a current transformation, if you seperate the current
transformation into an integer translate and a fp matrix. The program
can then translate so that 0,0 is on the screen and draw with very
high accuracy.
It is not necessary to have a transformation stack, just setting the
current transformation directly would be sufficient. However I would
not complain if there was a stack.
PATHS:
I do think paths should be in the server, because otherwise people
will write wrapper libraries that will be slower than doing it in the
server. Like PostScript, paths are built using the current
transformation, they do not move when you change transformation. This
allows them to be converted immediately into trapazoids.
Characters may be drawn into the path. Since these are antialiased
bitmaps from the font renderer this means the path must support
antialiased bitmaps. Also current X supports the ability to add 1-bit
masks to the clip and it seems likely you will have to support this
for back compatability. Therefore it seems likely that the path must
be an arbitrary gray-shade image (internally stored much more
efficiently as a combination of images and trapazoids). This is a
pain but I see no way around it.
Unlike PostScript you can probably require the program to say what it
is going to do with the path before it builds it. "Stroke" for
instance would be totally different and could ignore bitmaps (or draw
a box around them).
"Fill" would fill the path. It may help to insert some OpenGL into
here and allow the color to change as the path is built and it then
did Gourand shading of the path.
"Clip" would use the path to set the clipping area, intersecting it
with the current clip.
It would be real nice if a window could be created with the current
path, to replace the "shape extension".
TEXT:
I do not want the Windoze-style 12-parameter call to sepecify a font,
and I am afraid this is what you are suggesting. I recommend a call
much like this: setfont(gc, const char* name, int attributes, float size).
The "name" should be something that we are willing to show a user,
like "Helvetica". The attributes are bitflags for bold, italic, etc,
but in all cases the same attributes may be achieved by adding "
Bold", " Italic", etc to the name and leaving the attribute zero. The
size is a convienence, as the current transformation should be used to
figure out the letter forms, the size temporarily scales the
tranformation by that factor, sets the font, and scales it back.
The PostScript model where the size is the true "point size" MUST be
used. This means the size is the minimum line spacing, not the ascent
size that has been popularized by broken Windoze and Qt. This is
necessary to typeopgraphy and for supporting non-Latin fonts.
Another pet peeve: can I PLEAD with you to support UTF-8 (and ONLY
UTF-8) encoding! This is a standard to translate 8-bit bytes into
Unicode indicies. I don't care if you draw a box for every Unicode
character not in the font, just support the $#$%@ encoding! I believe
there is NO need to support plain 8-bit or "wide" characters, but I
know others disagree. Illegal UTF-8 sequences (including characters
encoded longer than needed) should be represented by using the bytes
individually. Change Unicode by replacing 0x80-0xA0 with the
MicroSoft character set, because we must face the fact that they have
taken control of this standard.
Measuring text for layout is a problem. Any kind of character
metricies system prevents the server from doing intelligent kerning or
overprinting, it also requires the application to understand UTF-8,
which eliminates the whole point of UTF-8! Any other solution would
look like HTML, greately limit the amount of formatting control the
program has and being very complex. I think we have to give up on
eliminating the round trip and recommend instead that the gc have a
"current string". The program sets the string to an array of bytes
and then can request the metricies of how that string would be
formatted (ie the bounding box, etc). The program can then tell the
server to draw the string, or it can change the string by either
replacing it or truncating it to a substring. This at least
eliminates the need to send the string twice and lets the server cache
info it got when it measured the string.
IMAGES:
Again, I STRONGLY disagree with the conventional wisdom that the only
fast way to do images is to have the program know the details of the
hardware. Though true in theory, the pratical solution is to have an
ENORMOUS library that can translate all possible pixel formats the
program has to all possible ones that any server has. Doing this in
the server is MUCH simpler, since it only has one target format,
reducing the complexity from N^2 to N.
I would greatly limit the number of source formats to ones that are
needed by modern programs. This means ONLY these:
"native" : a single format the server likes, much like X is now.
1-bit black & white
8-bit gray level
8,8,8 full color RGB
8,8,8 full color BGR
8,8,8,8 full color with alpha non-premultiplied RGBA
8,8,8,8 full color with alpha non-premultiplied ABGR
8,8,8,8 full color with alpha premultiplied RGBA
8,8,8,8 full color with alpha premultiplied ABGR
Just so people won't scream about my color limitations, also support
8*2^n bits per color, though this can be done by skipping the
low-order bytes for now.
The recommended call is this (or a seperate call for each format):
draw_image(int format, const char* data, x,y,w,h,delta,linedelta)
x,y define a position in the current coordinate system for the
upper-left corner. w,h define the width & height of pixels to draw.
Delta is the data increment between pixels (this allows other pixel
data to be skipped, or the red channel to be drawn monochrome).
Linedelta is the data increment between lines, this allows arbitrary
subrectangles of an image to be drawn. Both delta and linedelta may
be negative to flip or rotate the image.
It may also be useful to send raw jpeg or png data to the server and
let it be decoded there. This has obvious benefits for a network, and
also eliminates another need for many programs to link in another
library.
OTHER FIXES TO X:
Make a new type of "gc" that includes the damn window! It is
ridiculous that we have to send both the window and gc to all the
calls. Deletion of the window id would also shorten the protocol (it
is vital that the window be changable with a setWindow call, the lack
of this makes the Win32 gc's nearly useless).
Add a call that can define a huge array of atoms with a single
protocol request and a single round trip. This along with the
elimination of colormaps would get rid of most of the startup delay of
X programs.
Fix the X protocol so there is a symbol sent when an application is
waiting for events (actually it would be sent by XFlush if the buffer
is not empty). This would allow servers to synchronize updates with
vertical retrace, do double buffering, and consolidate mouse events.
It would also allow synchonrization with the X window managers: one
real annoyance with X is that you cannot map a window and immediately
draw into it, this looks horrible to programmers used to Windoze and
almost certainly needs to be fixed before they will be willing to work
on X.
I think what bothers people here is the rather Orwellian aspect of having themselves deleted from public thought by removing the word used to name them.
I believe the odd behavior of the buttons is because there are no arrows on the scrollbars and they used two mouse buttons to click them up and down. It is also possible that the Lisp machines in use at MIT did this (I do remember they had scrollbars). Somehow the line up/down got mutated to page up/down, this was later and possibly in response to the Mac's page up/down. I would say that those scrollbars were about the worst possible example of user-unintuitivity and it seems hard to believe they still remain (but they do, in Emacs...)
Xt is in fact a horrid mess itself, about 50% responsible for the disasters in Motif. For this reason I totally disagree with people who say a widget-framework should have been built into X. Such a framework would have been some horrid bad design like Xt and we would be forced to use it! X's innovation is not that it is well designed, but that the designers had the sense and humility to realize that perhaps some stuff could be done by the application!
I'm sorry, but it is you that have no clue. The widgets have been dissected down to rectangles and lines and characters long before they reach the hardware. This in on Win32 and X, and probably every other modern system in existence.
In fact it can be easily shown that a window drawn using simple Win32 GDI calls (like fill rectangle) that looks identical to one drawn with Win32 API widgets will update much faster.
Why do they think this won't be done with Windoze? Isn't DeCSS due to somebody examining the inner workings of a Windoze driver?
If MPAA wants CSS to work, they have to do it in the hardware. The video signal would come out a seperate cable that plugs into the display card that inserts it into the display, probably by using color-keying and an origin that is set by software. They also have to get the display card manufacturers to agree to add MacroVision to any video out signal if this input is enabled.
They have to realize that if the method of descrambling the disk, or the descrambled data itself, is ever in bytes in memory that a hacker can read, their code will be cracked. They can't have both cheap hardware and security.
If they do this, they should have absolutely no qualms about open-source drivers, since the driver is no more powerful than a remote control for a DVD player.
I was wondering why we cannot do that right now. Can't the whole memory be put into the swap partition on shutdown, and some special version of LILO just restore it? I would think the time to swap in 100M from the disk would be pretty small. Biggest problem is that all the hardware has to be reinitialized, I guess new "poweroff/on" signals have to be sent to every process and a whole lot of programs and drivers need to be rewritten to reinit hardware on these signals. I can also see these being so badly written that in fact the "instant-on" is no longer instant, as each takes many seconds to reinit...
This will have almost miniscule effect on rebooting. The typical application spends most of it's time "initializing", not swapping in stuff from disk.
But to refute your point, it does not really work. Clicking on a button in a window raises it, which (for me, at least) defeats most of the usability of focus-follows-mouse. Even stranger, popping up a menu does not raise the window, but it raises when you release the mouse. And what always kills me is that if you click the border to raise the window, and then decide to move the window, it takes your second click as a double-click and maximizes the window! All of these are indications of this being a quick hack stuck atop the system by somebody who cannot rewrite the lower levels correctly.
The byte produced by MicroSoft word is actually in the range 0x80-0x9F. The real Unicode character would be greater than 0xFF. The official Unicode spec says these are the "C1 control characters". MicroSoft has actually invented non-standard meanings for these bytes, since it was much easier than supporting UTF-8 to get these symbols into their 8-bit programs.
However I would not be too hard on MicroSoft, because:
This "C1 reserved area" is an ancient back-compatability hack to avoid accidentally producing control characters on systems that strip off the high bit. We should not be making stupid standards just for back compatability with obsolete equipment!
MicroSoft has used these values to encode typographic symbols that real people really, really, want!. They did not use them for more obscure letters. This encoding serves far more people than almost any of the Unicode pages.
NetScape and Unix still stink when handling UTF-8. They just display question marks. At least MSoft displays a square box, and it even correctly displays all codes that are in the 0-0xff range or are in the Symbols character set.
I very much recommend that the Linux/Unix/Unicode world swallow their pride and adopt the MicroSoft assignments for the characters in the range 0x80-0x9F as part of the Unicode standard, and that everybody (X and the console) fix their fonts to display these characters as soon as possible!!!
I would complain though about MicroSoft's "smart" quotes. It changes apostrophe into a single-close quote character. This is wrong, they should leave it an apostrophe. This breaks all search engines and keywording of files! The text ``this isn't quoted'' should display as ?this isn't quoted' on NetScape, not ?this isn?t quoted?.
I actually would prefer to see Netscape be pixel-identical on every platform (probably with a Windoze-style interface to make the masses happy). If there is "themeing" it should also work the same on all platforms, though I also think that Slashdot geeks way overestimate the appeal of themes to the average user (Windoze has had the ability to change the window color since version 3.0, yet almost no non-geek users do this. Customization is limited to changing the desktop image. If you don't believe me, take a look at a real business office and the Windoze machines on each person's desk).
Judging by the comments ("html rendering is fast but the menus are slow") it sounds like Mozilla/Netscape botched this. There is no excuse for the slow gui. I thought they were using GTK, which is pretty fast. However it now sounds like they put some sort of wrapper above it so they can use something different on Windoze and that resulted in this horrid behavior.
I also got a chance to try a 1ghz Alpha, running Linux. Code compiled with (new) gcc was easily 3-4 times faster than a 550 mhz Intel code compiled with the newest MSVC++.
1. They can force you to watch (or wait through) the FBI notice and the "coming attractions", as fast-forward won't work.
2. They can make the disk not play back unless your modem is used to call their company and a small fee is deducted from your visa account for each play.
3. You cannot play Japanese disks on your American machine, and vice/versa. You cannot trade your disks with your friends in Europe.
4. You cannot record any of the disk to a vcr, or edit it into your home movies as a gag.
I'm sure there are many other things...
Angular momemntum is just a convienent way to represent the constantly-changing linear momentum of all the particles in the top. If the forces holding the top together were to suddenly fail so that it turned into particles, they would all travel in straight lines outward in their current linear momentum, none of the particles would have any "memory" of some angular momentum.
A clockwise spinning top will precess in exactly the same way (except mirrored) as a counter-clockwise spinning top. There is nothing different. If we used a "left hand rule math" we would get the *SAME* precession (no, it would NOT go in the opposite direction unless the top was also going in the opposite direction).
Psueudo-science is often based on taking some technical shortcut term and pretending it is literal.
The terminal driver only allowed one code to delete backwards a character, so it had to be either ^H or ^? (or #, which I have never seen, but I do remember teletypes where it was '_' (underscore) which actually was a backarrow in the earliest versions of ASCII).
If the keyboard driver instead translated keys to "what they do", it would have been trivial to have both ^H and ^? work.
Quite seriously, they should chuck all this obsolete stuff from the terminal driver. Just hard-code everything into the driver so it works for the maximum number of people. The most common usages don't intersect (for instance nobody uses ^H for anything other than backspace) so just merge the most common settings. Off the top of my head:
I would almost suggest that the terminals be in raw mode all the time and that we rely on readline libraries, but I can see this breaking things. Another possibility is to put this sort of editing into the FILE library.
There is a failure though when NumLock is on. The idea of "NumLock" is pretty bogus, when you think about it, it dates back to the original IBM PC, where they were too cheap to put seperate function keys. In X this the NumLock bit is stored as a shift flag, but the basic X design was that the shift flags were things like Shift, Alt, and Ctrl: the fact that they were on probably meant something, and the user was holding them down on purpose. Therefore a lot of programs think that *any* shift key being on makes the keys being typed "special" and that they should be not be treated as letters. This is the source of the common X bug, especially with Motif programs, where *nothing* works when NumLock is turned on. Modern X programs seem to ignore all shift bits that they are not interested in, this is a better solution.
Anyways it would be nice if this problem goes away, but I think it should go away by getting rid of the whole "NumLock" concept, I mean it is painfully obsolete and just a hack for a forgotten keyboard layout. If the function keys are in the "ideal arrangement" there, then the main arrow and functions should be in that arrangement. We should get rid of NumLock.
And on Win32, bit 24 of the lParam of the keyboard event can be used to tell the normal function keys from the "NumLock-off" ones.
How about a "Hackers" keyboard that has (in order of importance):
1. Put the word "Meta" on the "windoze" keys
2. Put the word "Ctrl" on the "caps lock" key.
3. Put the word "Super" on the two current control keys.
4. Put the word "Menu" or "Hyper" on the "windoze menu key".
5. Get rid of the arrow, home, etc symbols on the numeric keypad, and make the key marked with "NumLock" say something else (comma?).
6. Make the three keys with PrintScrn, etc say F13, F14, F15.
7. Make all the labels on the function keys, especially the Fn keys, MUCH larger, at least as large as the capital letters, so they can be read at a distance. Get rid of all the arrow logos on the tab, shift, and Enter keys. The arrow keys should have nice bold triangles on them.
8. Make the labels for the leds be 1,2,3 or A,B,C, or something. Since I have deleted numlock, caps lock, and scrolllock, they don't need to show keyboard state, so this allows them to be more easily used by a program.
9. If you want to call it a "Linux" keyboard, print your company logo and "Linux Keyboard" in the corner.
Some X programming is necessary to make this work, especially to get rid of "num lock", but no hardware changes are necessary except for changing labels, so a keyboard manufacturer could probably do this easily. If the keyboard manufacturer is willing to do hardware modifications than some of the buttons can be electronically switched and new scan codes produced for all the keys with new labels. You could also delete the keys I called "Super" and "Hyper" above and make the space key much wider. You could also delete the LED's entirely. And use an upside-down T for the arrows (Windoze users would appreciate this, too!).
Main changes I would make to the NeWS:
1. Add 3d (openGL) and antialiasing
2. Do alpha correctly by making alpha part of the current color, rather than having the "compositing modes".
3. Get rid of "layer numbers" in the server. This was the only bit of GUI in the server, and there was absolutely no reason for it, as the toolkit could emulate it easily.
Document and support the postscript interface, rather than trying to force everybody to use NeXTStep (ie same complaint I have about Qt or MFC being the interface).
A perhaps better example is NeWS. In this the windowing was much better integrated into the PostScript. They did depend too much on executing the GUI on the server, though, but otherwise was a much cleaner design.
In both cases lots of operations were noticably faster than X, despite the "overhead" of the buffering and the PostScript interpreter. And NeWS allowed me to rotate and scale an application and it still worked! Nobody is even trying that now...
But I don't want to see a "toolkit" interface as the low-level API. This will completely freeze all gui devlopment. It will also make Linux much harder to "hacker" program and will make it less fun. If I am forced to use Qt, I might as well use MFC and Direct X.
What we need is a true replacement for X that keeps the (few) good ideas of X:
A networked, buffered protocol. Despite claims above, this is more efficient than a call-based API. There has to be context switches, unless we want to allow the programs to write and peek at each other's windows and to be able to clobber the video registers. The way to keep the context switches down is to buffer requests. Nice simple buffering at a low level, and we get an efficient interface, and we get networked transparency for "free" (rather than having to add it on, as MicroSoft is feverishly trying to do right now...)
The server does not have to do any "GUI" things. X design is 20 years old, yet it is obvious that it can draw all the GUI components ever invented (like we can copy Windoze quite exactly, and that was not a design criteria when X was made). I do not want a server that has any concept of a "menu" or "button". That is bloat. Put it in the user-level library (much like Qt and GTK are now). I really really fear Qt becoming the standard interface, even MicroSoft was smart enough to not cram MFC down everybody.
The server does need advanced graphics capabilities. Here the opposite is obvious: X obviously cannot duplicate new ideas. We have seen antialiasing for years now and X cannot do it. 3D requires a whole new interface (OpenGL) that does not interact well with the rest (it does not use X gc's or colors, for instance). And way too many programs "work" by creating a local image buffer, doing all the work there (thus losing all hardware acceleration), and drawing the image.
I envision a server much like X, but with graphics capabilities like a combination of PostScript and OpenGL (plus antialiased everything, like Flash, and 4-channel images, and transparent paint, and UTF-8 text).
It seperates programs into arbitrary-shaped "windows" (perhaps with transparency) and does not allow one program to draw in another's "window" or intercept events to another's "window". But except for that it is "GUI stupid". It must deliver raw events to the clients and make absolutely no assumptions about anything, for instance a "window" does not mean it has a border.
The problem is HORRIBLE Xlib design.
Lets see how you draw a red dot on the screen in Xlib:
1. fill in an XColor structure with the r,g,b and call XAllocColor (1 round trip to server). (this could fail, in which case you have to do hundreds of round trips to find the closest color or make a new colormap, but I'll ingore that to be fair).
2. Create a "gc" (probably 0 round trips in modern Xlib? But info is sent to the server).
3. Set the foreground color in that gc (probably done locally).
4. Do XPutPixel, passing that gc and the window over the wire. (more info sent to server)
Now lets see what the calls would be in an interface designed by a semi-talented monkey:
1. "set_color(r,g,b)": info sent to server. Size of info: 3 bytes.
2. "draw_pixel(x,y)": info sent to server, size of info: 2 numbers.
3. DONE! Total number of round trips: ZERO. And I suspect the amount of info is about 1/4 as much sent over the wire, so the buffer fills up only 1/4 as often. Overall improvement in efficiency: perhaps 10,000 or more, depending on the overhead of a round trip.