Re: especially when one considers that the GIMP toolkit (GTK+ & Co.), allows one application to be written for X and Win32 with minimal OS-specific code.
That's what I meant. Despite the huge differences, it is possible to hide the difference between X and Win32 GDI by using a toolkit. But the lack of a simple thing like symbolic links on NT is impossible to get around.
Symbolic links would allow us to set up local and remote files on our NT machines to have the same names as our Unix machines, and eliminate the need for drive letters, and thus allow much greater Unix/NT interoperability. Unfortunately MicroSoft is well aware of this fact and will refuse to support symbolic links as long as they possibly can.
Is this able to read/write files that are used by the Win32 programs?
Apparently the official NT version is completetly unable to do this, which means it "works with NT" about as well as a Linux box with no physical connection between it and the NT box.
If so, is there official transformations between Unix file names and Win32 file names (ie does A:foo in Win32 turn into perhaps/A/foo in Unix?) What about case dependence (a posix requirement)?
Agreement on these transformations would go a long way to allowing the writing of software that ports between NT and Unix. For my work the file name problem and lack of symbolic links are causing far more difficulty than the fact that X and Win32 GDI are completely different.
He copied a very nice and clean layout. And he grabbed some images and repainted them with his own logos. If I needed a nice pastel shaded rectangle I would probably grab one as well.
It's not like he's trying to hide where it came from. He has a dancing penguin, a "powered by Linux", and many other cartoon penguins on there. It is very likely that people reading this page have seen linux.com, or might find it rather quickly.
I see this as a good thing for amateur artists. It allows unambigous proof that somebody appreciated your work. The value of this positive feedback is probably more than the monetary value of the micropayments.
Isn't it likely that all the broadcasts are so compressed and encrypted that they are indistinguishable from noise?
It appears that is the way we are heading, in a matter of decades. It could be that detectable signals are only sent for a very very short period in the time of a civilization.
They are talking about a render farm, not desktop machines.
Using desktop machines for render farm is very good. And yes, currently, the desktop machines have to be NT to get the GUI software. At where I work we are using both Linux renderfarms and NT desktop machines for running batch processing with no problems. Most rendering software is available for both. We use tcsh on the NT machines so the batch processing looks the same.
Yea, yea. I am not an idiot, despite your apparent belief. Obviously any interface saves a context switch if it is in the kernel. In fact the best way to reduce context switches is to put everything including the user program in the kernel. Whoa! I've just invented CP/M!
I think everybody else here equates "kernel implementation" with "lots of different little calls to the kernel" while "not in kernel" typically means "buffered". You may be confusing this with NT where "not in the kernel" meant "many little calls that do 2 context switches" (or as I have argued, with X, which due to bad design has managed to reduce a buffered implementation to a many-call implementation)
Obviously a buffered implementation can be put in the kernel, thus saving a context switch. But this is a trivial savings compared to the savings of millions of context switches that the buffer itself provides. Most of your suggested techniques for speeding up a kernel implementation amount to implementing buffer operations in a user-level library.
But a buffer is not what NT does, and is not what any of the proponents of a "kernel implementation" are thinking of.
3. Client/server architectures for graphics will always be slow. The fundamental issues are:
(a) A client/server architecture requires several context switches for each call to the graphics system..
Not true of X as originally envisioned. X is supposed to buffer possibly thousands of calls into a single context switch. This can reduce the context switches considerably below the one-per-call required by a kernel implementation.
The biggest problem with X is the huge number of calls requiring synchronization because the program has to get a response before doing the next call. For instance to draw in red, the program has to send the "allocate a color cell with red" call, wait for the response with the number of the color cell, and then use that number. This introduces a synchornization that can slow it down by several orders of magnitude. There is no reason the interface could not be "allocate a color cell with red and I will call it N from now on" and that can immediately be followed by a "use N as the color call". Some intelligent design like this would solve a lot of X's problems.
Buffers do have a few problems:
Although very fast at throughput, they have latency problems, as nothing is drawn until the buffer is filled and sent. Trying to solve the latency loses the advantage of buffers in the first place. But I think latency problems will show up in the code anyway, so I would prefer that the graphics not try to solve this at all, but concentrate on fast throughput. Also check interactive net games, which have been fighting real latency problems for years, for better solutions.
The other problem is the overhead of filling the buffer and then parsing it. But this is a completely false assumption. The savings of being able to send a pre-filled buffer (ie a canned sequence) with a single call, and the amazing simplicity of sending possibly millions of graphics calls to a coprocessor, greatly outweigh any overhead of buffering.
To complete the setup of the server, and create the storage space to STORE your data (read: You can't.. can NOT.. skip this step and expect it to work right, er, at all.) you have to login as 'sa' with no password.
Can anybody confirm this, and confirm that this is not true of pirana? Ie: is SQL useless unless the user logs in at least once, and is pirana usable without using the password.
Amoung all the noise here, this is the first coherent response that indicates that in fact the two pieces of software might be different.
What the average person calls "Windows NT" is NOT "Posix Compliant". The so-called "Posix subsystem" is what is "posix compliant". Among many other fun facts about this subsystem is that it cannot read or even see files that were written by normal NT programs!
Running Linux under VMWARE on NT would be equivalent to this so-called "Posix compiance".
The real shame is that MicroSoft probably would not be exposed to the wrath of the CS community if they had done even rudimentary Posix-compliance correctly in NT. All they needed were raw byte file names (ie case-dependent file names), raw byte files (ie get rid of "text mode" and ^M^J newlines), use forward slashes (they do already, but fix the documentation!), some hack so you don't need colons to name objects (like having/A/foo or//disk/A/foo mean the same as A:foo), and make all of their NT "objects and services" accessible as named files so at least access() works on them, support symbolic links, and all processes have a working stdin/out. All of this would have been trivial to do and if they had done this I believe Linux would be nowhere today since they would have produced a friendly programming environment rather than the horror they did.
I fail to see the difference between DirectX and OpenGL. If your card supports something that is not in DirectX, you are in exactly the same position as OpenGL.
Perhaps you may want to rephrase your argument to "Direct X supports a more powerful graphics api" which would make sense.
Neither DirectX or OpenGL or X or BeOS support graphics APIs that have not been invented yet!
I find it hard to believe they wrote something as ludricous as "2x as fast as NT". This paper is not going to help Linux at all. Lets see some reasonable arguments!
Some tests I ran (network intensive reading and writing of files) did run more than twice as fast on Linux as on NT on identical hardware.
Some other tests (compute intensive) ran as much as 10% slower, possibly due to poorer optimization of the gcc compiler.
I recommend you go back to school and figure out the difference between the words "install" and "use".
The "average" person cannot "install Linux". The average person cannot "install Windows". They can't install BeOS or Solaris, which are commercial products in a similar position to Linux. They can't install their DSS dish without the guy from the the store doing the alignment. They can't install a toilet without asking a plumber to do it.
This has nothing to do with whether they can use the product.
The point is not to compare current programming languages and cli interfaces (which are very primative) to current GUI, but to compare the possibilities of language interfaces.
The only good example we have of powerful language interfaces is humans talking to each other.
In your example of picking a color, the interface would be the user saying "Can I change the color over here" (and here they point, which is arguably GUI, but that point operation is still in a serial stream with their talking) "to be red, kind of like this color?". At worst the program should then respond "no, my engineer was too stupid to allow that color to be changed". Or you can ask "what are all the colors that can be changed?" and get a response, and stop it and say "yea, that one, change it...".
Everybody here should DEMAND that Sun open-source the original Gosling NeWS server source. It is still better than X or NeXTStep or DPS despite being 15 years old.
They could also release the X11-NeWS merge which was the official product, but that was really mess. I would prefer seeing pure NeWS underlying it with an emulation library for X11 that talks to NeWS. The fact that modern programs no longer assumme colormaps should get rid of the worst problems with X11 emulation (the emulator will just claim that a true-color visual is the only one available).
Merging in the FreeType font renderer and some anti-aliasing code from libart and it would kick MicroSoft's (and Java's) ass.
Apparently use of the tld for actually routing information is completely dead, so there is no technical reason for any set of tlds.
All claimnants can register "a.b" where a and b are arbitrary words. Either a or b or both may be a trademark or other word they own, but the combination a.b cannot be trademarked (if it is they must use a_b.c).
To preserve existing value, browsers will automatically replace 'a' (no periods in it) with 'a.com', to give these existing names much more value.
Entity 'a' can sue anybody using 'a.b' or 'b.a' if: the displayed page is blank, contains or links any kind of indication that the name is for sale, or contains content that can reasonably be confused as actually being from 'a'. Otherwise names can be bought and sold on the open market.
I would expect there to quickly be a lot of 'b' words in common use, like.cars and.movie. Some will be as valuable as.com and will be fought bitterly over. But the individual can just pick random b words.
MicroSoft is free to register "microsoft.sucks" and every other word they want. It costs them and they never will pick all the possible words, since this proposal squares the size of the name space.
I think you are right, I was confused by Slashdot again. It should show comments less than my threshold if there are responses greater than my threshold! The current way is misleading as to what is a response.
I consider the drawing support to be a problem with X. One we have been living with for far too long.
Trying to solve it in fltk would bloat it up. And a worse problem: any solution we did would not match solutions used by other programmers, so when somebody says "use the font called 'Helvetica'" they may get different results depending on the program.
I programmed the NeXT for about 2 years, starting on the emulated version that ran on a Sun workstation, and then on an actual cube.
Though NeXTStep certainly is interesting, I do not join in the uniform praise for it that everybody else seems to have. I am also worried that the problems with NeXTStep are being duplicated in BeOS, OS X, and (somwhat) in Gnome and KDE.
Good points:
The postscript interface to the display. It included Adobe's "DPS", but it should not be confused with DPS on X. The important difference is that all commands (such as to create a window) were in PostScript. It is difficult to describe how incredible an advantage it is to only have to think about a single "context" to get all your work done. X is a total hassle where you have to manage windows, gc's, OpenGL glxContexts, DPS contexts, and perhaps the new "Xpicture" objects. NeWS also had this, and in fact integrated it better: the window-creation commands described the window shape using PostScript paths and transformations.
The PostScript printer really worked, far better than the mess that is on Linux now. You could, with incredible reliability, do popen("lpr") and send any postscript you wanted, and it would queue and print!
Problems:
The lack of a hard disk on the base model was a real problem. Basically the optical disk had to be used as a hard disk. Jobs thought people would own their copy of the system and stick them in disk-less machines on a campus to enable them, this is in fact insane if you think about the need to store location-specific configuration imformation like the name of the printer server!
(The machine I used had a hard disk, in that case the optical was an excellent back-up device)
NeXTStep wad very slow to start any applications. It had to completely build every single control panel that would ever be used when it started up. At the time I thought this intolerable, but I guess it has become standard on Windows and Mac.
This meant terminal.app was slow to start. Very frustrating for Unix users who wanted to create and destroy these rapidly. For this reason the first software we worked on was a replacement for the terminal (the marketing name was Communicae), and our intention was to bypass as much of NeXTStep as possible. I also wanted to get rid of the menu (which is pretty useless for a terminal) and it appeared to be impossible to make a menu-less NeXTStep program.
This ran into the most serious problem. Though enough information was provided so that we could create plain windows with PostScript, getting them to cooperate with the NeXTStep programs required tracing down (often with disassembly) a lot of undocumented stuff. The NeXT programs refused to click on top of my windows, and many many other problems.
This was an absolute pain in the ass, and NeXT's attitude that we were nuts for avoiding their wonderful code did not help. There are very good reasons for using low-level programming, for instance to get maximum speed, to try new GUI ideas, and (most important nowadays) to write cross-platform code.
I want to plead to the OS-X (and BeOS) designers to not repeat this mistake: please document how to bypass the toolkit!. If you don't, people are going to write incredible kludges to achieve it, and you will have a worse problem remaining compatable in the future. And if you suceed in making it impossible to bypass the toolkit, you will completely cut off any company that is interested in porting software from Windows or Unix but not willing to commit a lot of resources yet...
I also think NeXTStep had some design problems, and am scared at how many of them are being copied today:
Steve Job's hatred for the second mouse button resulted in insane design decisions. The NeXT had two buttons, and there was an option to treat them the same or different. Unbelivably, this modified the server (rather than just set something that NeXTStep read). A program using NeXTStep (or even bypassing it) could not tell the two buttons apart, unless the configuration setting was changed!
"Layers" This is being copied by Gnome, and sort of copied by the "Dock" being used by Windows and OSX and Gnome. "Layers" are why the menus and toolbars are atop the programs and have to "hide" when the program is "inactive" (not to be confused with child/transient-for windows, which are atop a *specific* window). "Layers" are also why the dock is atop all the windows, making a large amount of screen space useless (all modern systems "solve" this problem by providing the auto-hide option).
Let me plead again with the designers: let me click any window atop any other unrelated window! It is not that hard, in fact it simplifies the interface considerably!
And don't give me the excuse "but that will make the dock (or menu) hard to get to". That problem applies to every window on your screen, and you should be working on improving window navigation, not arrogantly claiming that some windows are "important".
Jobs and many other UI designers seem convinced that showing a '/' character in a filename is user-unfriendly, and go through all kinds of weird hoops to avoid it. The Mac and Windows use newlines (and you have to hold a damn mouse button down to see it), while NeXTStep (and OSX) have this column arrangement where you have to scroll horizontally to see where you are! Comon, guys, it really is not that bad to display a slash! In fact the average user sees them all the time on the net! And if you did, it would be much easier and clearer how to cut & paste or drag & drop a filename!
I did not like Objective-C syntax for methods, it was totally different than the syntax for a function call. This made it impossible to switch an interface between C functions and methods, even with macros. People say it was like that to "look like SmallTalk" but that is bogus, as SmallTalk has *only* that syntax. The dual syntax was so the parser could be cheap, no other reason!
Also the first versions were too dynamic: if you mistyped the name of a method you would not find out until you ran the program and it tried to call it! Extremely bad for code such as error handlers that may never be called. They tried to fix this and had lots of trouble with already-existing code that relied on it (because you could create methods at run-time!).
There is no reason for Linux to duplicate DLL hell from Windows.
And everybody asks "what kind of interface is friendly for the user" and talks about installation wizards and other crap. What is "friendly" is when there is a little box in their file browser that is the "program" and they click on it to "run" it and they NEVER have to "install" it.
Static linking will 100% allow this for programs that don't have to mess with system resources like drivers or continuously-running services. For programs that do have to mess with the system, I recommend that the program have compiled into it the ability to execute a setuid utility (that asks the user for the root password) that can run a script to "install" the program.
And he did not mean static linking libc or Xlib or other things that are obviously part of the system, he was talking about static linking those hundreds of Gnome libraries that are making it almost impossible to get Gnome to work!
"install" can just put a symbolic link into some directory pointing at the actual executable to run. Deleting the package will still successfully remove all the files, though it will leave a broken link. Still much preferrable to the existing shotgun "installation".
But rather then trying to figure out how to break this excellent idea so it works with old tools, why not fix the old tools. What we want is the existence of a file to "install" it.
For the shell: modify it (or the exec system call) so you can execute a "package" and run the application. Tell everybody to put ~/bin in their path. And then tell everybody that sticking the package in ~/bin will allow them to run it from the shell.
For things like the Gnome start menu: fix gnome to look for packages in ~/bin and extract the necessary information (help, icon, etc) from it. Then again, putting the package there will suddenly make them appear on the menus.
To "install" a package so all users can see it, become superuser, and move (or link) the package to/System/bin.
To "uninstall" a package, just delete the file (modify rm so it does rm -R on them automatically).
A package that has to change the system somehow (like install a service) will pop up a question box when run saying "do you want to install this". If the user says yes it then runs some kind of "install shell" program. This is a setuid program that asks for the root password in a pop-up window and if the user types in the correct thing it then runs the script.
Cheap solution: user must put the "file" (jar/.app/whatever) into ~/bin to see it without installation (and their path must contain ~/bin).
Making shells see the command is the same as making the Gnome command see the command or the Windows start menu see the command. Some thing needs to be done other than simply putting the file on the file system.
Re:Dynamic resizing of the X display
on
XFree & Rendering
·
· Score: 2
This is a good idea. The window manager can then do any effect that's wanted (including keeping the current behavior of not moving any windows). A useful intermediate effect would be to not move anything, but change the size of any "maximized" windows.
It is true that programs will not know the screen size correctly unless they pay attention to this event. But this is probably not going to break things too badly. Programs just use it to set maximum window size and to force menus/etc to be on-screen. In many cases the window manager will override them anyways.
Actually you are right. Premultiplied alpha compositing can be done with math like the following (G is gamma, F is premulitiplied foreground, B is background, A is alpha, a^b is pow(a,b)):
(F^G*A^(G-1)+B^G*(1-A))^(1/G)
And it does seem that without hardware support this can be really slow. It might be best to do whatever the hardware does as fast as possible, but not define the exact results of alpha compositing so that such changes are doable.
It also appears that your "mask" is in fact a non-premultiplied alpha channel. Thus both are provided by the design.
I am still really confused by the design, though. Is a "picture" in effect a graphics context?
I also want to state why I feel it is very important that the extension do everything with a single graphics context. Many people have said "use GLX" or "use DPS". But I need the ability to write a library that does something like take a gc and set the foreground color to a special value. This is not possible when there are 3 (or 4) different types of gc.
An alternative is to add the missing stuff to GLX: add antialisaed fonts, clipping, and perhaps a few other things to OpenGL and it can be used for all the graphics, and only a single gc object needs to be worried about (though I would also like the ability to switch the gc between windows).
Slashdot Mirror
That's what I meant. Despite the huge differences, it is possible to hide the difference between X and Win32 GDI by using a toolkit. But the lack of a simple thing like symbolic links on NT is impossible to get around.
Symbolic links would allow us to set up local and remote files on our NT machines to have the same names as our Unix machines, and eliminate the need for drive letters, and thus allow much greater Unix/NT interoperability. Unfortunately MicroSoft is well aware of this fact and will refuse to support symbolic links as long as they possibly can.
Apparently the official NT version is completetly unable to do this, which means it "works with NT" about as well as a Linux box with no physical connection between it and the NT box.
If so, is there official transformations between Unix file names and Win32 file names (ie does A:foo in Win32 turn into perhaps /A/foo in Unix?) What about case dependence (a posix requirement)?
Agreement on these transformations would go a long way to allowing the writing of software that ports between NT and Unix. For my work the file name problem and lack of symbolic links are causing far more difficulty than the fact that X and Win32 GDI are completely different.
It's not like he's trying to hide where it came from. He has a dancing penguin, a "powered by Linux", and many other cartoon penguins on there. It is very likely that people reading this page have seen linux.com, or might find it rather quickly.
I see this as a good thing for amateur artists. It allows unambigous proof that somebody appreciated your work. The value of this positive feedback is probably more than the monetary value of the micropayments.
It appears that is the way we are heading, in a matter of decades. It could be that detectable signals are only sent for a very very short period in the time of a civilization.
Using desktop machines for render farm is very good. And yes, currently, the desktop machines have to be NT to get the GUI software. At where I work we are using both Linux renderfarms and NT desktop machines for running batch processing with no problems. Most rendering software is available for both. We use tcsh on the NT machines so the batch processing looks the same.
I think everybody else here equates "kernel implementation" with "lots of different little calls to the kernel" while "not in kernel" typically means "buffered". You may be confusing this with NT where "not in the kernel" meant "many little calls that do 2 context switches" (or as I have argued, with X, which due to bad design has managed to reduce a buffered implementation to a many-call implementation)
Obviously a buffered implementation can be put in the kernel, thus saving a context switch. But this is a trivial savings compared to the savings of millions of context switches that the buffer itself provides. Most of your suggested techniques for speeding up a kernel implementation amount to implementing buffer operations in a user-level library.
But a buffer is not what NT does, and is not what any of the proponents of a "kernel implementation" are thinking of.
Not true of X as originally envisioned. X is supposed to buffer possibly thousands of calls into a single context switch. This can reduce the context switches considerably below the one-per-call required by a kernel implementation.
The biggest problem with X is the huge number of calls requiring synchronization because the program has to get a response before doing the next call. For instance to draw in red, the program has to send the "allocate a color cell with red" call, wait for the response with the number of the color cell, and then use that number. This introduces a synchornization that can slow it down by several orders of magnitude. There is no reason the interface could not be "allocate a color cell with red and I will call it N from now on" and that can immediately be followed by a "use N as the color call". Some intelligent design like this would solve a lot of X's problems.
Buffers do have a few problems:
Although very fast at throughput, they have latency problems, as nothing is drawn until the buffer is filled and sent. Trying to solve the latency loses the advantage of buffers in the first place. But I think latency problems will show up in the code anyway, so I would prefer that the graphics not try to solve this at all, but concentrate on fast throughput. Also check interactive net games, which have been fighting real latency problems for years, for better solutions.
The other problem is the overhead of filling the buffer and then parsing it. But this is a completely false assumption. The savings of being able to send a pre-filled buffer (ie a canned sequence) with a single call, and the amazing simplicity of sending possibly millions of graphics calls to a coprocessor, greatly outweigh any overhead of buffering.
Can anybody confirm this, and confirm that this is not true of pirana? Ie: is SQL useless unless the user logs in at least once, and is pirana usable without using the password.
Amoung all the noise here, this is the first coherent response that indicates that in fact the two pieces of software might be different.
Yes, but if you know how to set that up you probably know enough to change the password, too.
Running Linux under VMWARE on NT would be equivalent to this so-called "Posix compiance".
The real shame is that MicroSoft probably would not be exposed to the wrath of the CS community if they had done even rudimentary Posix-compliance correctly in NT. All they needed were raw byte file names (ie case-dependent file names), raw byte files (ie get rid of "text mode" and ^M^J newlines), use forward slashes (they do already, but fix the documentation!), some hack so you don't need colons to name objects (like having /A/foo or //disk/A/foo mean the same as A:foo), and make all of their NT "objects and services" accessible as named files so at least access() works on them, support symbolic links, and all processes have a working stdin/out. All of this would have been trivial to do and if they had done this I believe Linux would be nowhere today since they would have produced a friendly programming environment rather than the horror they did.
Perhaps you may want to rephrase your argument to "Direct X supports a more powerful graphics api" which would make sense.
Neither DirectX or OpenGL or X or BeOS support graphics APIs that have not been invented yet!
Some tests I ran (network intensive reading and writing of files) did run more than twice as fast on Linux as on NT on identical hardware.
Some other tests (compute intensive) ran as much as 10% slower, possibly due to poorer optimization of the gcc compiler.
The "average" person cannot "install Linux". The average person cannot "install Windows". They can't install BeOS or Solaris, which are commercial products in a similar position to Linux. They can't install their DSS dish without the guy from the the store doing the alignment. They can't install a toilet without asking a plumber to do it.
This has nothing to do with whether they can use the product.
The only good example we have of powerful language interfaces is humans talking to each other.
In your example of picking a color, the interface would be the user saying "Can I change the color over here" (and here they point, which is arguably GUI, but that point operation is still in a serial stream with their talking) "to be red, kind of like this color?". At worst the program should then respond "no, my engineer was too stupid to allow that color to be changed". Or you can ask "what are all the colors that can be changed?" and get a response, and stop it and say "yea, that one, change it...".
They could also release the X11-NeWS merge which was the official product, but that was really mess. I would prefer seeing pure NeWS underlying it with an emulation library for X11 that talks to NeWS. The fact that modern programs no longer assumme colormaps should get rid of the worst problems with X11 emulation (the emulator will just claim that a true-color visual is the only one available).
Merging in the FreeType font renderer and some anti-aliasing code from libart and it would kick MicroSoft's (and Java's) ass.
Apparently use of the tld for actually routing information is completely dead, so there is no technical reason for any set of tlds.
All claimnants can register "a.b" where a and b are arbitrary words. Either a or b or both may be a trademark or other word they own, but the combination a.b cannot be trademarked (if it is they must use a_b.c).
To preserve existing value, browsers will automatically replace 'a' (no periods in it) with 'a.com', to give these existing names much more value.
Entity 'a' can sue anybody using 'a.b' or 'b.a' if: the displayed page is blank, contains or links any kind of indication that the name is for sale, or contains content that can reasonably be confused as actually being from 'a'. Otherwise names can be bought and sold on the open market.
I would expect there to quickly be a lot of 'b' words in common use, like .cars and .movie. Some will be as valuable as .com and will be fought bitterly over. But the individual can just pick random b words.
MicroSoft is free to register "microsoft.sucks" and every other word they want. It costs them and they never will pick all the possible words, since this proposal squares the size of the name space.
I think you are right, I was confused by Slashdot again. It should show comments less than my threshold if there are responses greater than my threshold! The current way is misleading as to what is a response.
Trying to solve it in fltk would bloat it up. And a worse problem: any solution we did would not match solutions used by other programmers, so when somebody says "use the font called 'Helvetica'" they may get different results depending on the program.
X is crap and everybody should realize that.
Not sure what it is, perhaps the JX toolkit?
Though NeXTStep certainly is interesting, I do not join in the uniform praise for it that everybody else seems to have. I am also worried that the problems with NeXTStep are being duplicated in BeOS, OS X, and (somwhat) in Gnome and KDE.
Good points:
The postscript interface to the display. It included Adobe's "DPS", but it should not be confused with DPS on X. The important difference is that all commands (such as to create a window) were in PostScript. It is difficult to describe how incredible an advantage it is to only have to think about a single "context" to get all your work done. X is a total hassle where you have to manage windows, gc's, OpenGL glxContexts, DPS contexts, and perhaps the new "Xpicture" objects. NeWS also had this, and in fact integrated it better: the window-creation commands described the window shape using PostScript paths and transformations.
The PostScript printer really worked, far better than the mess that is on Linux now. You could, with incredible reliability, do popen("lpr") and send any postscript you wanted, and it would queue and print!
Problems:
The lack of a hard disk on the base model was a real problem. Basically the optical disk had to be used as a hard disk. Jobs thought people would own their copy of the system and stick them in disk-less machines on a campus to enable them, this is in fact insane if you think about the need to store location-specific configuration imformation like the name of the printer server! (The machine I used had a hard disk, in that case the optical was an excellent back-up device)
NeXTStep wad very slow to start any applications. It had to completely build every single control panel that would ever be used when it started up. At the time I thought this intolerable, but I guess it has become standard on Windows and Mac.
This meant terminal.app was slow to start. Very frustrating for Unix users who wanted to create and destroy these rapidly. For this reason the first software we worked on was a replacement for the terminal (the marketing name was Communicae), and our intention was to bypass as much of NeXTStep as possible. I also wanted to get rid of the menu (which is pretty useless for a terminal) and it appeared to be impossible to make a menu-less NeXTStep program.
This ran into the most serious problem. Though enough information was provided so that we could create plain windows with PostScript, getting them to cooperate with the NeXTStep programs required tracing down (often with disassembly) a lot of undocumented stuff. The NeXT programs refused to click on top of my windows, and many many other problems.
This was an absolute pain in the ass, and NeXT's attitude that we were nuts for avoiding their wonderful code did not help. There are very good reasons for using low-level programming, for instance to get maximum speed, to try new GUI ideas, and (most important nowadays) to write cross-platform code.
I want to plead to the OS-X (and BeOS) designers to not repeat this mistake: please document how to bypass the toolkit!. If you don't, people are going to write incredible kludges to achieve it, and you will have a worse problem remaining compatable in the future. And if you suceed in making it impossible to bypass the toolkit, you will completely cut off any company that is interested in porting software from Windows or Unix but not willing to commit a lot of resources yet...
I also think NeXTStep had some design problems, and am scared at how many of them are being copied today:
Steve Job's hatred for the second mouse button resulted in insane design decisions. The NeXT had two buttons, and there was an option to treat them the same or different. Unbelivably, this modified the server (rather than just set something that NeXTStep read). A program using NeXTStep (or even bypassing it) could not tell the two buttons apart, unless the configuration setting was changed!
"Layers" This is being copied by Gnome, and sort of copied by the "Dock" being used by Windows and OSX and Gnome. "Layers" are why the menus and toolbars are atop the programs and have to "hide" when the program is "inactive" (not to be confused with child/transient-for windows, which are atop a *specific* window). "Layers" are also why the dock is atop all the windows, making a large amount of screen space useless (all modern systems "solve" this problem by providing the auto-hide option).
Let me plead again with the designers: let me click any window atop any other unrelated window! It is not that hard, in fact it simplifies the interface considerably!
And don't give me the excuse "but that will make the dock (or menu) hard to get to". That problem applies to every window on your screen, and you should be working on improving window navigation, not arrogantly claiming that some windows are "important".
Jobs and many other UI designers seem convinced that showing a '/' character in a filename is user-unfriendly, and go through all kinds of weird hoops to avoid it. The Mac and Windows use newlines (and you have to hold a damn mouse button down to see it), while NeXTStep (and OSX) have this column arrangement where you have to scroll horizontally to see where you are! Comon, guys, it really is not that bad to display a slash! In fact the average user sees them all the time on the net! And if you did, it would be much easier and clearer how to cut & paste or drag & drop a filename!
I did not like Objective-C syntax for methods, it was totally different than the syntax for a function call. This made it impossible to switch an interface between C functions and methods, even with macros. People say it was like that to "look like SmallTalk" but that is bogus, as SmallTalk has *only* that syntax. The dual syntax was so the parser could be cheap, no other reason!
Also the first versions were too dynamic: if you mistyped the name of a method you would not find out until you ran the program and it tried to call it! Extremely bad for code such as error handlers that may never be called. They tried to fix this and had lots of trouble with already-existing code that relied on it (because you could create methods at run-time!).
There is no reason for Linux to duplicate DLL hell from Windows.
And everybody asks "what kind of interface is friendly for the user" and talks about installation wizards and other crap. What is "friendly" is when there is a little box in their file browser that is the "program" and they click on it to "run" it and they NEVER have to "install" it.
Static linking will 100% allow this for programs that don't have to mess with system resources like drivers or continuously-running services. For programs that do have to mess with the system, I recommend that the program have compiled into it the ability to execute a setuid utility (that asks the user for the root password) that can run a script to "install" the program.
And he did not mean static linking libc or Xlib or other things that are obviously part of the system, he was talking about static linking those hundreds of Gnome libraries that are making it almost impossible to get Gnome to work!
But rather then trying to figure out how to break this excellent idea so it works with old tools, why not fix the old tools. What we want is the existence of a file to "install" it.
For the shell: modify it (or the exec system call) so you can execute a "package" and run the application. Tell everybody to put ~/bin in their path. And then tell everybody that sticking the package in ~/bin will allow them to run it from the shell.
For things like the Gnome start menu: fix gnome to look for packages in ~/bin and extract the necessary information (help, icon, etc) from it. Then again, putting the package there will suddenly make them appear on the menus.
To "install" a package so all users can see it, become superuser, and move (or link) the package to /System/bin.
To "uninstall" a package, just delete the file (modify rm so it does rm -R on them automatically).
A package that has to change the system somehow (like install a service) will pop up a question box when run saying "do you want to install this". If the user says yes it then runs some kind of "install shell" program. This is a setuid program that asks for the root password in a pop-up window and if the user types in the correct thing it then runs the script. Cheap solution: user must put the "file" (jar/.app/whatever) into ~/bin to see it without installation (and their path must contain ~/bin). Making shells see the command is the same as making the Gnome command see the command or the Windows start menu see the command. Some thing needs to be done other than simply putting the file on the file system.
It is true that programs will not know the screen size correctly unless they pay attention to this event. But this is probably not going to break things too badly. Programs just use it to set maximum window size and to force menus/etc to be on-screen. In many cases the window manager will override them anyways.
(F^G*A^(G-1)+B^G*(1-A))^(1/G)
And it does seem that without hardware support this can be really slow. It might be best to do whatever the hardware does as fast as possible, but not define the exact results of alpha compositing so that such changes are doable.
It also appears that your "mask" is in fact a non-premultiplied alpha channel. Thus both are provided by the design.
I am still really confused by the design, though. Is a "picture" in effect a graphics context?
I also want to state why I feel it is very important that the extension do everything with a single graphics context. Many people have said "use GLX" or "use DPS". But I need the ability to write a library that does something like take a gc and set the foreground color to a special value. This is not possible when there are 3 (or 4) different types of gc.
An alternative is to add the missing stuff to GLX: add antialisaed fonts, clipping, and perhaps a few other things to OpenGL and it can be used for all the graphics, and only a single gc object needs to be worried about (though I would also like the ability to switch the gc between windows).