NeWS did not use DPS. NeWS had it's own, much faster and smaller PostScript interpreter, which did much more than DPS, such as handle the creation of windows and sending events to widgets, and it had an object-oriented system added on (though initially this was just PostScript dictionaries).
The Adobe license had nothing to do with the death of NeWS. It was entirely due to the lack of source code and an attempt by Sun to sell it for a large amount of money. At the same time, X cost $120 and came with source code. Motif is meaningless because at the same time as Motif there was no freer alternative.
The other Unix companies actually panicked because they saw how good NeWS was, and formed the Open Software Foundation (OSF) whose main purpose was to prevent Sun from setting arbitrary standards. To do this they set standards on any junk (like X and Motif) that they could find as long as it was not Sun's. Though it is possible that an unchecked Sun would have been as evil as MicroSoft is today, the main effect was that the Unix vendors all fought each other and ignored MicroSoft until MicroSoft took over.
Actually the original NeWS implementation was quite clean and fast (it was slower than X at that time due to things like outline fonts and dithered images which X did not even attempt at that time).
The slow and crufty one which most people used was the "X11/NeWS" merge. This was a horrid mess where both the PostScript and X were implemented in paralell C code, and a low-lying renderer which was bloated with if's so that it could render pixel-accurate emulation of X11 and not break PostScript too badly (it still failed to fill any shape other than rectangles correctly). The attempts to make a NeWS toolkit were also seriously hurt by the need to have the windows reusable by X and the need to write all the horrors of an X window manager implementation in PostScript code. The PostScript interpreter was also slowed down quite a bit by peoples rabid insistance that it copy every single bug and misfeature of the Apple LaserWriter (too many people thought NeWS's only purpose was to preview documents before printing...)
They should have emulated X11 atop PostScript, but it was already know that Sun was killing NeWS so they were forced to do it this way so X11 performance was not hurt at all.
Of course the real reason it died was that Sun tried to sell it when there was an open-source (not free though, a tape and license cost $120, although that cost was trivial) alternative.
Gnome already fixed this. There are two different cut buffers, one for the text selected by highlighing, and one for the most recent Ctrl+C type of copy. It is unfortunate that most toolkits up to now used the selected buffer for both. I have fixed the newest versions of fltk to match Gnome.
It sounds a little bit from the other poster that perhaps KDE/Qt are going to do this as well.
The old X mechansim is actually equivalent to "drag&drop" but with the advantage that you can rearrange the windows in the middle of the drag. This makes the real problems with drag&drop become visible, this is what you are seeing. (it also points out the drag&drop is pretty powerful, seeing as X has survived for so long with only that, but that it is not sufficient for everything).
I do wish people would stop complaining that the mechanism sucks and then go on to complain that "X lacks drag&drop". I'm sorry, you are wrong, perhaps the mechanism sucks but that mechansim *IS* drag&drop!!!
NeWS is NOT DPS, it is instead Sun's own PostScript interpreter. It is immensely better, mostly because everything (like window creation and event handling) is done in PostScript.
In many ways this unified all-PostScript approach means the interpreter does not have to be able to do things that are dangerous. For instance an interpreter that could make requests of an X server for window id's, etc, I would suspect could be much more dangerous than one that can only draw on it's own screen.
However NeWS did have the capability to write files, and this certainly should be removed from any modern version.
NeWS is still superior to any windowing system I have seen today, and Sun could go a long way toward redeeming the biggest sin that was every done by a computer company by releasing the source code.
However I feel that metadata is a bad idea. The problem is that one of the main things done with a file is to copy it from one place to another. In fact with the web, I would say that non-system files are copied hundreds of times more often then they are "used".
This requires the metadata to be encoded and transmitted with the file. These encodings tend to be complex, kludgey because they are never designed for completeness, and require both ends to understand the encodign. And the end result is a stream of data that most programs (all those concerned with copying files) will treat as the file's data anyway.
There is also the annoying fact that all programming languages need functions added to them to manipulate the metadata.
So how about imbedding all that metadata into the file's data? I have thought that a system could be designed where a file is *only* a block of data. Even the file's name and protection is imbedded in the file. A filesystem would be designed so the first 1K or so of a file is very quickly accessible. There would also be simple rules so that the data could be located and it would appear as comments to whatever reads the file.
Since anybody with write access could change the permissions, permissions would actually be some and/or combination of that file and all the parent directories. This is the only complex part I see to this.
Actually the OLE structure is documented (this is the stuff that people claiming that MicroSoft "documents the Word format" are pointing at).
As I understand it, with this documentation (and also with MFC source code that reads these files), splitting the OLE structure is not too difficult. The problem is that the individual pieces you get are undocumented, at the point where MFC says "block of data".
I have not worked with this, though, so I may be wrong.
I agree. There are a *lot* of programs that use the word "Office" in their names and do similar stuff.
The Adobe thing is different because there really were very few programs (perhaps only one) that used the word "Illustrator". Also the word "illustrator" is somewhat more abstract, as the program could be better described as "draftsman".
Also, although MicroSoft has done some incredible PR blunders in the past, I find it hard to believe would be stupid enough to do this, it serves them no business purpose and would bring a great deal of bad publicity on them.
Re:For every action, there is an equal and opposit
on
Quicktime In Linux
·
· Score: 2
Re: But neither is as easy as "click setup.exe and look for your new program in the start menu".
What the f**k is this? Since when is "install" user friendly? People have been so biased by Windoze crap that they call crap that is only slightly better than Linux "user freindly".
In reality the average user has no idea that you "install" anything.
How about this for user freindly:
The user clicks on the program and it RUNS!!! It does not "install" or any such crap. It RUNS, like programs did THIRTY F**KING YEARS AGO!
Then the user can try out the program. If they don't like it, they quit, and they throw the icon they clicked on in the trash, and it is GONE with no cleanup necessary!
Yea, of course "installation" is necessary. How about if the programs, if they need installation, would pop up a warning "Until you decide to install me, I can't do this wizzy network thing, so I will show you a simulation of what I do". The user can still experiement with it.
When the user quits the program it pops up a box that says "Would you like to make this program available to all users of your system?" (or if it needs root stuff to function, "Would you like to make this program able to do it's stuff for all users". It would then pop up a box that says "Please type the root password for your machine" (possibly with a button that says "this is what I am going to do" that shows advanced users the exact script it is going to run as root). The user does this and the program is then "installed", and the icon they clicked is removed (because a new icon appears on the startup menu or whatever).
When the user tires of a program they installed, they can pick "uninstall" from the program. It says "please type the root password" (and the "this is what I'm going to do" button) and then the program is removed and it exits. It may also offer "Do you want to save me so I can be used again" and if you say yes it asks for a location and an icon identical to the original one is created there.
I'm really don't understand, though, where people who otherwise appear intelligent, will go and say "Linux needs easier installation". What we need is *NO* "installation".
Re:For every action, there is an equal and opposit
on
Quicktime In Linux
·
· Score: 2
You got to be kidding, or you are not too familiar with X.
X does not do color cursors. The call to set the cursor takes two bitmaps, giving you 3 colors at most (plus transparent). Most X servers use only 2 colors and make the third color be "xor" (perhaps this is required). Nobody has bothered to modify the call to take an X Pixmap, because they are all paranoid about back compatability.
Similarily, yea there is this marvelous XRender "extension" to do anti-aliased fonts, but use of it requires a huge library on the client end, completely defeating one of the main purposes of X! Why didn't they just replace the existing X font rendering? People always tell me "well, that's technically impossible, you don't know shit about X", but I know for a fact that the MicroSoft that we all love to deride successfully replaced *their* non-antialiased interface with an anti-aliased one and it didn't break any programs and all programs, including old ones, suddenly got anti-aliased text! I think it is pretty disgusting that the X designers cannot do this. Of course it is due to the absrudly complex internals of X and the horrid complex toolkits that are atop it that make them completely unwilling to change the slightest thing about how the calls work for fear they will break something.
And all that 3-D stuff is added on. I have to create different "contexts" for OpenGL than for X, I have to use totally different calls to set the color I want to draw in, and I can't share the fonts (especially I can't share the new XRender fonts). This is just stupid and has absolutely nothing to do with intelligent design. (Of course MicroSoft's 3D has the same problem so we aren't inferior to them there, but still...)
I agree that it would be far more useful to make the "official" Atheos interface much more low level, on the "create a window this shape, draw these rectangles and colors, tell me where the mouse clicked" interface, and put all the work into a powerful graphics engine (which X and Windows lack).
Writing buttons is pretty trivial (I have done it!), the reason toolkits on X is so hard is the enormous amount of work needed to do things that should be easy, like select fonts and draw them and draw images.
I also feel that putting the toolkit into the system will lock the design into something that would quickly become obsolete. X, for all it's problems, is still used today, and able to emulate stuff invented 15 years later. Do you think X would be anything other than a joke if it required all programs to use the Athena toolkit?
However, I cannot prove from the documentation whether or not Atheos is designed this way, but I don't really like what I see. But his toolkit may just be an example, he certainly would need to write a toolkit layer so that there could be anything other than trivial demo programs, and perhaps he intends to allow that layer to be replaced.
I think any such emulation should be done by making an Xlib emulator so that the applications, as much as possible, cooperate with native Atheos applications. It would be best if many X things, in particular window managers, were not supported.
Unfortunately it appears this is difficult or people are not interested. Most "emulate X" schemes I have seen require an entire X server to be emulated. This either takes over the screen, or puts a screen in a native window, or at best actually mixes the X windows with the native windows but they interact in strange ways. I think this is the wrong approach.
Thanks for your support, I sometimes feel this is a hopeless cause...
The "searching for the title bar" problem can be solved by raising windows when the user clicks on dead area, such as background or labels, where the click has no other meaning. On X this requires toolkit or application support to implement. In my experience people used to Windows do not notice any difference in function, since they always search for such a "dead" area to click when they want to raise a window without using any other function.
Applications are also free to raise themselves if they really think they should. Some people think a word processor should do this if the user clicks to place the insertion cursor (but not if they drag to select text or if they move any other controls). I'm uncertain, but at least now the application can decide!
Ideally I would like clicks on this dead area to do all "window manager" stuff, i.e it can drag the windows around and resize them and bring up window manager menus. This would probably allow us to get rid of title bars and window borders. Unfortunatley support for this requires changes in how window managers are implemented on X.
We have discontinued use of NT on Alpha (switching to Linux), so this was about 2 years ago, NT 4.something, and whatever version of the compiler came with it.
The bugs may have been in floating point handling, possibly with assumptions about aliasing of floating point variables in structures. Basically things just refused to work when optimization was turned on. The same software works fine with VC++ on Intel NT, and with GCC, Dec, and Irix compilers.
Our software uses extensive floating point and we compile without ANSI emulation in order to speed it up, this is probably the main difference from the NT kernel. Also MicroSoft probably fixed the bugs as they found them when compiling NT.
GCC does produce slow code (probably 2/3 the speed of the VC++ Alpha code) but at least it works. And the optimized GCC is way faster than the unoptimized VC++.
Yes there need to be standards, but a lot of users like me are scared of this copying of Windows crap because people are familiar with it. Both KDE and Gnome suffer from these (to me) fatal problems:
We need consistent, tested support for point-to-type. I have never seen a single user (on either Linux or NT) who has used point-to-type for a day or so switch back. It is obviously superior and the only thing stopping it is the unfamiliarity of users with it. I would like to see point-to-type be the default in any Linux desktop. Let's see a little "innovation" instead of this sheep-like copying of Windoze and Mac!
Stop raising the windows when I click on them! This is less obvious but killer problem. Both KDE and Gnome will raise any window on a click. If I want to raise the window I will click on the title or border, or on an empty area of the window!! This foul behavior forces programmers to use horrifying kludges like tiled windows or "MDI" and then everybody bitches about the poor or buggy toolkit support for these, while failing to realize that these are horrid workarounds for an extremely simple and basic design flaw! This misfeature was removed from X in 1984, dammit, and we are somehow reintroducing it by copying stupid Windows into the X window managers! All old X window managers did this correctly, this disease is killing the ability for innovative user interface designs to be made. Note that it is trivial for an application to raise it's own windows and thus act like Windows if it wants to.
(Gnome/Sawfish can have the click-to-raise turned off, but it is totally mysterious how to do it and requires changing key and mouse bindings. KDE is much worse, it appears to be impossible to turn click-to-raise off without also turning it off for the title bars, I have tried quite a bit).
Stop raising the "parent" when a "child" window is raised. This additional Windows-copied foul behavior is almost as bad as the click-to-raise behavior in preventing overlapping window interfaces from being implemented. For the morons out there who are designing this stuff: yes a child window must be "above" it's parent, but that does not mean that there cannot be windows inbetween them! Both KDE and Gnome have this behavior and it cannot be turned off, pretty much forcing us to make *all* windows children, or *none*. This problem seems to exist in older CDE window managers too. But FVWM got it right, and there is no reason you morons cannot do it, too.
You may think I am bitching, but I think the above are simple, basic, design errors in how the window managers work, and these simple errors are the main reason there is resistance to a "standard Linux desktop".
Hate to rain on the OpenGL parade, but this has not worked with any DRI version of XFree86 I have seen in quite awhile. This is from a Linux box to an Irix server, vice-versa, and between two Linux boxes. I would think it is quite technically possible but it does not appear there is enough interest and software rot has set in.
Also GLX (or whatever Irix called it when you went between machines) was never very fast. People would always complain to me that their program was slow, and I would discover that they had accidentally rsh'ed into another machine. In some ways it would have been preferrable if it didn't work at all, so people would know immediately not to do that.
It is too bad but I would have to say this is not a selling point of OpenGL anymore.
This should be quite possible. Although I don't know anything about SDL, the fact that it is portable to non-X applications means that it must only use X for implementation and does not expose it to a program that is using SDL.
Replacing X with a much better designed and modern interface has been a long time dream of mine and this sounds like a way to do it.
I suspect SDL may lack features for allowing more than one program to cooperate on the screen (ie it lacks overlapping windows). But these should be possible to add with a few calls that should be designed to resemble the rest of SDL as much as possible.
Um, that was what I was trying to say. My complaint is that MicroSoft is not breaking *enough* software. They should have switched to NT a decade ago and they still haven't. This is not good design and demonstrates that they are quite unwilling to break existing software, no matter how good of an idea it is.
I am concerned that they have decided to break old software by explicitly putting each piece of software in a list that they control, rathern than having the software fail for technical reasons that are under the software writer's control.
There is nothing wrong with MicroSoft requiring everybody to rewrite their programs to work on the new system. That is an excellent way to get rid of these programs that are using unsafe interfaces.
Yes this would be bad for developers (who should also be allowed complete API documentation and test machines at least a year ahead of release, so MicroSoft cannot have the only programs that work at release). So there are monopoly problems with it. But technically it is the correct solution. I am also quite happy that Linux decided to replace libc or a.out and broke programs, sometimes you have to do that (it would be nice if they made the old programs fail in a more user-friendly way, however).
However it sounds like MicroSoft is making a back-compatability mess in an attempt to run everything, and then making a database of the programs they failed to be back-compatable for. As a lot of people here have indicated there is a lot of fear that this list's contents will be selected more on political than technical reasons.
Yes this is somewhat true, and it certainly is true of Windows (which has many more third-party drivers).
Linux also seems to be crashing much more often due to third-party drivers. I have had several lockups due to a closed-source X driver (fire GL) that killed everything except ping (actually that is done by the hardware, right). (PS new versions of the drivers do not seem to be crashing).
NT also suffered from a great deal of the GUI in the kernel. This caused most of our crashes as we attempted to use our machines as a renderfarm and the whole thing would bluescreen when somebody logged in. This appears to have been fixed as the rendering processes no longer link with any GUI DLLs (I know NT was not fixed as we never updated past 4.0 here). I suppose you could just say that the programs are written correctly, now, but I still think this is a problem.
I would greatly applaud MicroSoft getting away from their back-compatability parnoia and actually fixing the system. But this is obviously not the reason they are doing this.
If they were fixing the system and unconcerned about old programs doing "tricks" they would switch to NT as the underlying system. XP is not NT. They have promised the NT+DOS merge for TWELVE years now and it has not happened, this is because the upper management (probably in a big fight with the actual poor saps who have to implement this mess) do not want to do obvious steps, like have all programs that make an old call pop up a box that says "This program does not work on Windows XP". The problem is that this may prevent some sales of XP and the continuation of older MicroSoft machines, which are actually their biggest "competitor" (there are about 100 times as many Windows '93 machines than Linux machines, and that is probably an "enemy" they are more worried about!).
This system sounds like it will allow them to actively choose which programs they want to have fail, and they can make them fail with ominous messages about the given program being unsafe and disallowed by MicroSoft.
Serious OS design would cause Black Ice and literally thousands of others to fail at startup, possibly with cryptic messages. And I agree with you that would be a good design decision. But that is not what they seem to be doing.
Pixel shaders are equivalent to RenderMan shaders (though obviously many orders of magnitude faster since they are in hardware, and it can be assummed that they are somewhat less powerful because of this as well). You can do a lot, but believe me you cannot magically generate input that is not there!
If somebody invents a new algorithim that uses various derivatives of the normals and surface position to produce some new lighting effect, they can be implemented in the pixel shaders. But if the algorithim requires volumetric information that is an integral of all the surrounding surface points, the information is not there, because the hardware is not producing it!
Yea, you can use some pixel shaders to index a 3-D volume that may be pregenerated by this algorithim, and this is "faster". But that is equivalent to pre-rendered radiosity being loaded into texture maps, most people do not consider that "hardware radiosity", and I don't think this pixel shader solution would be considered "hardware photon mapping".
If they got their hands on a russian tactical nuke, they would have to put it in a suitcase to send it to the US. The missles don't have the range.
And if you think the informers that can spot somebody buying nuke plans cannot see an entire russian submarine defecting, I think you are really grasping at straws.
There seems to be total stupidy on all sides of this, though. Of course the missle had a transmitter sending it's GPS position. It is really helpful to find out how the test worked (or didn't work) if you have telemetry information! If they had not put this on, would people then say they hid the telemetry so people could not figure out they were cheating? Yes, the telemetry signal could be used to home in, but they could also have had the target steer toward the interceptor, or just put a bomb on it and blow it up at the right time, or done a million other things. I have to believe that at least some of the engineers are honest enough to not cheat.
The reason I don't think the toolkit should be in the system is that the interface is enormously complex. System interfaces should not be complex, because it is then impossible to reliably debug them.
Putting the toolkit into the system and you are frozen into a design that may seem modern right now, but may seem massively outdated and obsolete just a few years from now. The best example is why we are even able to use X now when it was designed in 1983? If X had had the toolkit as part of it it would have an Athena-style toolkit, and MicroSoft could have quite rightly laughed us off the planet.
The overhead of X is due to stupid graphics primitives, not the fact that graphics primitives are used. There is no reason a round trip is needed to select a color or a font. Unfortunately the interface to widgets can easily become much more complex than the graphics needed to draw them, obvious examples are X window managers.
And I certainly do want a dozen different toolkits on top! GUI diversity is a good thing, it might mean, dare I say it, "innovation" could happen!
Also everybody says users are "confused by different toolkits". I think this is a myth, I have worked with a lot of users and have seen no sign of this. People recognize buttons and scrollbars and menus with an enormous variety of appearances, and put up with keys not doing any thing with remarkable ease. Otherwise computer game designers could never get away with the designs they do.
It is true that huge differences cause problems, for instance Athena scrollbars were a stupid design. But these are solved quickly by competition between the toolkits. For example all the Unix toolkits quickly migrated to a Windows-style of key bindings, this would have been impossible if Unix had an enforced toolkit.
The "confused user" is a figment of the imagination of the people who are trying to force these toolkits down our throats. These people should get out of their theoretical ivory towers and examine exactly what the real programmers and users use and expect from their computers.
I do want to check out AtheOS, though. I suspect the necessary lower levels are there, because implementing a toolkit like they describe is impossible without them.
I think you are confused about what the previous poster wanted. He is asking about architectural issues of the internals of the system. Neither design would look any different to the user, the command line would be hidden behind the pretty graphic interface in both cases.
It does sound like AtheOS, although it implements the GUI as part of the system, implementes it as another task in user space using the microkernel=like communication mechanism. This sounds like an ok approach.
Although I do find the fact that there are "scrollbars" and "text edit" things in the interface (see the change log) indicates that he has made the GUI interface way too high level. I would much rather see an interface that reliably and quickly does "draw a rectangle here" and "format this UTF-8 text here" would be more powerful, as it would allow variation in the GUI design.
I still need to study the design and try it out to really get an opinion, though.
Slashdot Mirror
The Adobe license had nothing to do with the death of NeWS. It was entirely due to the lack of source code and an attempt by Sun to sell it for a large amount of money. At the same time, X cost $120 and came with source code. Motif is meaningless because at the same time as Motif there was no freer alternative.
The other Unix companies actually panicked because they saw how good NeWS was, and formed the Open Software Foundation (OSF) whose main purpose was to prevent Sun from setting arbitrary standards. To do this they set standards on any junk (like X and Motif) that they could find as long as it was not Sun's. Though it is possible that an unchecked Sun would have been as evil as MicroSoft is today, the main effect was that the Unix vendors all fought each other and ignored MicroSoft until MicroSoft took over.
The slow and crufty one which most people used was the "X11/NeWS" merge. This was a horrid mess where both the PostScript and X were implemented in paralell C code, and a low-lying renderer which was bloated with if's so that it could render pixel-accurate emulation of X11 and not break PostScript too badly (it still failed to fill any shape other than rectangles correctly). The attempts to make a NeWS toolkit were also seriously hurt by the need to have the windows reusable by X and the need to write all the horrors of an X window manager implementation in PostScript code. The PostScript interpreter was also slowed down quite a bit by peoples rabid insistance that it copy every single bug and misfeature of the Apple LaserWriter (too many people thought NeWS's only purpose was to preview documents before printing...)
They should have emulated X11 atop PostScript, but it was already know that Sun was killing NeWS so they were forced to do it this way so X11 performance was not hurt at all.
Of course the real reason it died was that Sun tried to sell it when there was an open-source (not free though, a tape and license cost $120, although that cost was trivial) alternative.
It sounds a little bit from the other poster that perhaps KDE/Qt are going to do this as well.
The old X mechansim is actually equivalent to "drag&drop" but with the advantage that you can rearrange the windows in the middle of the drag. This makes the real problems with drag&drop become visible, this is what you are seeing. (it also points out the drag&drop is pretty powerful, seeing as X has survived for so long with only that, but that it is not sufficient for everything).
I do wish people would stop complaining that the mechanism sucks and then go on to complain that "X lacks drag&drop". I'm sorry, you are wrong, perhaps the mechanism sucks but that mechansim *IS* drag&drop!!!
In many ways this unified all-PostScript approach means the interpreter does not have to be able to do things that are dangerous. For instance an interpreter that could make requests of an X server for window id's, etc, I would suspect could be much more dangerous than one that can only draw on it's own screen.
However NeWS did have the capability to write files, and this certainly should be removed from any modern version.
NeWS is still superior to any windowing system I have seen today, and Sun could go a long way toward redeeming the biggest sin that was every done by a computer company by releasing the source code.
However I feel that metadata is a bad idea. The problem is that one of the main things done with a file is to copy it from one place to another. In fact with the web, I would say that non-system files are copied hundreds of times more often then they are "used".
This requires the metadata to be encoded and transmitted with the file. These encodings tend to be complex, kludgey because they are never designed for completeness, and require both ends to understand the encodign. And the end result is a stream of data that most programs (all those concerned with copying files) will treat as the file's data anyway.
There is also the annoying fact that all programming languages need functions added to them to manipulate the metadata.
So how about imbedding all that metadata into the file's data? I have thought that a system could be designed where a file is *only* a block of data. Even the file's name and protection is imbedded in the file. A filesystem would be designed so the first 1K or so of a file is very quickly accessible. There would also be simple rules so that the data could be located and it would appear as comments to whatever reads the file.
Since anybody with write access could change the permissions, permissions would actually be some and/or combination of that file and all the parent directories. This is the only complex part I see to this.
As I understand it, with this documentation (and also with MFC source code that reads these files), splitting the OLE structure is not too difficult. The problem is that the individual pieces you get are undocumented, at the point where MFC says "block of data".
I have not worked with this, though, so I may be wrong.
The Adobe thing is different because there really were very few programs (perhaps only one) that used the word "Illustrator". Also the word "illustrator" is somewhat more abstract, as the program could be better described as "draftsman".
Also, although MicroSoft has done some incredible PR blunders in the past, I find it hard to believe would be stupid enough to do this, it serves them no business purpose and would bring a great deal of bad publicity on them.
What the f**k is this? Since when is "install" user friendly? People have been so biased by Windoze crap that they call crap that is only slightly better than Linux "user freindly".
In reality the average user has no idea that you "install" anything.
How about this for user freindly:
The user clicks on the program and it RUNS!!! It does not "install" or any such crap. It RUNS, like programs did THIRTY F**KING YEARS AGO!
Then the user can try out the program. If they don't like it, they quit, and they throw the icon they clicked on in the trash, and it is GONE with no cleanup necessary!
Yea, of course "installation" is necessary. How about if the programs, if they need installation, would pop up a warning "Until you decide to install me, I can't do this wizzy network thing, so I will show you a simulation of what I do". The user can still experiement with it.
When the user quits the program it pops up a box that says "Would you like to make this program available to all users of your system?" (or if it needs root stuff to function, "Would you like to make this program able to do it's stuff for all users". It would then pop up a box that says "Please type the root password for your machine" (possibly with a button that says "this is what I am going to do" that shows advanced users the exact script it is going to run as root). The user does this and the program is then "installed", and the icon they clicked is removed (because a new icon appears on the startup menu or whatever).
When the user tires of a program they installed, they can pick "uninstall" from the program. It says "please type the root password" (and the "this is what I'm going to do" button) and then the program is removed and it exits. It may also offer "Do you want to save me so I can be used again" and if you say yes it asks for a location and an icon identical to the original one is created there.
I'm really don't understand, though, where people who otherwise appear intelligent, will go and say "Linux needs easier installation". What we need is *NO* "installation".
X does not do color cursors. The call to set the cursor takes two bitmaps, giving you 3 colors at most (plus transparent). Most X servers use only 2 colors and make the third color be "xor" (perhaps this is required). Nobody has bothered to modify the call to take an X Pixmap, because they are all paranoid about back compatability.
Similarily, yea there is this marvelous XRender "extension" to do anti-aliased fonts, but use of it requires a huge library on the client end, completely defeating one of the main purposes of X! Why didn't they just replace the existing X font rendering? People always tell me "well, that's technically impossible, you don't know shit about X", but I know for a fact that the MicroSoft that we all love to deride successfully replaced *their* non-antialiased interface with an anti-aliased one and it didn't break any programs and all programs, including old ones, suddenly got anti-aliased text! I think it is pretty disgusting that the X designers cannot do this. Of course it is due to the absrudly complex internals of X and the horrid complex toolkits that are atop it that make them completely unwilling to change the slightest thing about how the calls work for fear they will break something.
And all that 3-D stuff is added on. I have to create different "contexts" for OpenGL than for X, I have to use totally different calls to set the color I want to draw in, and I can't share the fonts (especially I can't share the new XRender fonts). This is just stupid and has absolutely nothing to do with intelligent design. (Of course MicroSoft's 3D has the same problem so we aren't inferior to them there, but still...)
Writing buttons is pretty trivial (I have done it!), the reason toolkits on X is so hard is the enormous amount of work needed to do things that should be easy, like select fonts and draw them and draw images.
I also feel that putting the toolkit into the system will lock the design into something that would quickly become obsolete. X, for all it's problems, is still used today, and able to emulate stuff invented 15 years later. Do you think X would be anything other than a joke if it required all programs to use the Athena toolkit?
However, I cannot prove from the documentation whether or not Atheos is designed this way, but I don't really like what I see. But his toolkit may just be an example, he certainly would need to write a toolkit layer so that there could be anything other than trivial demo programs, and perhaps he intends to allow that layer to be replaced.
Unfortunately it appears this is difficult or people are not interested. Most "emulate X" schemes I have seen require an entire X server to be emulated. This either takes over the screen, or puts a screen in a native window, or at best actually mixes the X windows with the native windows but they interact in strange ways. I think this is the wrong approach.
The "searching for the title bar" problem can be solved by raising windows when the user clicks on dead area, such as background or labels, where the click has no other meaning. On X this requires toolkit or application support to implement. In my experience people used to Windows do not notice any difference in function, since they always search for such a "dead" area to click when they want to raise a window without using any other function.
Applications are also free to raise themselves if they really think they should. Some people think a word processor should do this if the user clicks to place the insertion cursor (but not if they drag to select text or if they move any other controls). I'm uncertain, but at least now the application can decide!
Ideally I would like clicks on this dead area to do all "window manager" stuff, i.e it can drag the windows around and resize them and bring up window manager menus. This would probably allow us to get rid of title bars and window borders. Unfortunatley support for this requires changes in how window managers are implemented on X.
The bugs may have been in floating point handling, possibly with assumptions about aliasing of floating point variables in structures. Basically things just refused to work when optimization was turned on. The same software works fine with VC++ on Intel NT, and with GCC, Dec, and Irix compilers.
Our software uses extensive floating point and we compile without ANSI emulation in order to speed it up, this is probably the main difference from the NT kernel. Also MicroSoft probably fixed the bugs as they found them when compiling NT.
GCC does produce slow code (probably 2/3 the speed of the VC++ Alpha code) but at least it works. And the optimized GCC is way faster than the unoptimized VC++.
VC++ on the Alpha we had to give up on compiling with any optimizations, due to a huge number of bugs. I would not consider the port a big success.
We need consistent, tested support for point-to-type. I have never seen a single user (on either Linux or NT) who has used point-to-type for a day or so switch back. It is obviously superior and the only thing stopping it is the unfamiliarity of users with it. I would like to see point-to-type be the default in any Linux desktop. Let's see a little "innovation" instead of this sheep-like copying of Windoze and Mac!
Stop raising the windows when I click on them! This is less obvious but killer problem. Both KDE and Gnome will raise any window on a click. If I want to raise the window I will click on the title or border, or on an empty area of the window!! This foul behavior forces programmers to use horrifying kludges like tiled windows or "MDI" and then everybody bitches about the poor or buggy toolkit support for these, while failing to realize that these are horrid workarounds for an extremely simple and basic design flaw! This misfeature was removed from X in 1984, dammit, and we are somehow reintroducing it by copying stupid Windows into the X window managers! All old X window managers did this correctly, this disease is killing the ability for innovative user interface designs to be made. Note that it is trivial for an application to raise it's own windows and thus act like Windows if it wants to.
(Gnome/Sawfish can have the click-to-raise turned off, but it is totally mysterious how to do it and requires changing key and mouse bindings. KDE is much worse, it appears to be impossible to turn click-to-raise off without also turning it off for the title bars, I have tried quite a bit).
Stop raising the "parent" when a "child" window is raised. This additional Windows-copied foul behavior is almost as bad as the click-to-raise behavior in preventing overlapping window interfaces from being implemented. For the morons out there who are designing this stuff: yes a child window must be "above" it's parent, but that does not mean that there cannot be windows inbetween them! Both KDE and Gnome have this behavior and it cannot be turned off, pretty much forcing us to make *all* windows children, or *none*. This problem seems to exist in older CDE window managers too. But FVWM got it right, and there is no reason you morons cannot do it, too.
You may think I am bitching, but I think the above are simple, basic, design errors in how the window managers work, and these simple errors are the main reason there is resistance to a "standard Linux desktop".
Also GLX (or whatever Irix called it when you went between machines) was never very fast. People would always complain to me that their program was slow, and I would discover that they had accidentally rsh'ed into another machine. In some ways it would have been preferrable if it didn't work at all, so people would know immediately not to do that.
It is too bad but I would have to say this is not a selling point of OpenGL anymore.
Replacing X with a much better designed and modern interface has been a long time dream of mine and this sounds like a way to do it.
I suspect SDL may lack features for allowing more than one program to cooperate on the screen (ie it lacks overlapping windows). But these should be possible to add with a few calls that should be designed to resemble the rest of SDL as much as possible.
I am concerned that they have decided to break old software by explicitly putting each piece of software in a list that they control, rathern than having the software fail for technical reasons that are under the software writer's control.
Yes this would be bad for developers (who should also be allowed complete API documentation and test machines at least a year ahead of release, so MicroSoft cannot have the only programs that work at release). So there are monopoly problems with it. But technically it is the correct solution. I am also quite happy that Linux decided to replace libc or a.out and broke programs, sometimes you have to do that (it would be nice if they made the old programs fail in a more user-friendly way, however).
However it sounds like MicroSoft is making a back-compatability mess in an attempt to run everything, and then making a database of the programs they failed to be back-compatable for. As a lot of people here have indicated there is a lot of fear that this list's contents will be selected more on political than technical reasons.
Linux also seems to be crashing much more often due to third-party drivers. I have had several lockups due to a closed-source X driver (fire GL) that killed everything except ping (actually that is done by the hardware, right). (PS new versions of the drivers do not seem to be crashing).
NT also suffered from a great deal of the GUI in the kernel. This caused most of our crashes as we attempted to use our machines as a renderfarm and the whole thing would bluescreen when somebody logged in. This appears to have been fixed as the rendering processes no longer link with any GUI DLLs (I know NT was not fixed as we never updated past 4.0 here). I suppose you could just say that the programs are written correctly, now, but I still think this is a problem.
If they were fixing the system and unconcerned about old programs doing "tricks" they would switch to NT as the underlying system. XP is not NT. They have promised the NT+DOS merge for TWELVE years now and it has not happened, this is because the upper management (probably in a big fight with the actual poor saps who have to implement this mess) do not want to do obvious steps, like have all programs that make an old call pop up a box that says "This program does not work on Windows XP". The problem is that this may prevent some sales of XP and the continuation of older MicroSoft machines, which are actually their biggest "competitor" (there are about 100 times as many Windows '93 machines than Linux machines, and that is probably an "enemy" they are more worried about!).
This system sounds like it will allow them to actively choose which programs they want to have fail, and they can make them fail with ominous messages about the given program being unsafe and disallowed by MicroSoft.
Serious OS design would cause Black Ice and literally thousands of others to fail at startup, possibly with cryptic messages. And I agree with you that would be a good design decision. But that is not what they seem to be doing.
If somebody invents a new algorithim that uses various derivatives of the normals and surface position to produce some new lighting effect, they can be implemented in the pixel shaders. But if the algorithim requires volumetric information that is an integral of all the surrounding surface points, the information is not there, because the hardware is not producing it!
Yea, you can use some pixel shaders to index a 3-D volume that may be pregenerated by this algorithim, and this is "faster". But that is equivalent to pre-rendered radiosity being loaded into texture maps, most people do not consider that "hardware radiosity", and I don't think this pixel shader solution would be considered "hardware photon mapping".
And if you think the informers that can spot somebody buying nuke plans cannot see an entire russian submarine defecting, I think you are really grasping at straws.
There seems to be total stupidy on all sides of this, though. Of course the missle had a transmitter sending it's GPS position. It is really helpful to find out how the test worked (or didn't work) if you have telemetry information! If they had not put this on, would people then say they hid the telemetry so people could not figure out they were cheating? Yes, the telemetry signal could be used to home in, but they could also have had the target steer toward the interceptor, or just put a bomb on it and blow it up at the right time, or done a million other things. I have to believe that at least some of the engineers are honest enough to not cheat.
Putting the toolkit into the system and you are frozen into a design that may seem modern right now, but may seem massively outdated and obsolete just a few years from now. The best example is why we are even able to use X now when it was designed in 1983? If X had had the toolkit as part of it it would have an Athena-style toolkit, and MicroSoft could have quite rightly laughed us off the planet.
The overhead of X is due to stupid graphics primitives, not the fact that graphics primitives are used. There is no reason a round trip is needed to select a color or a font. Unfortunately the interface to widgets can easily become much more complex than the graphics needed to draw them, obvious examples are X window managers.
And I certainly do want a dozen different toolkits on top! GUI diversity is a good thing, it might mean, dare I say it, "innovation" could happen!
Also everybody says users are "confused by different toolkits". I think this is a myth, I have worked with a lot of users and have seen no sign of this. People recognize buttons and scrollbars and menus with an enormous variety of appearances, and put up with keys not doing any thing with remarkable ease. Otherwise computer game designers could never get away with the designs they do.
It is true that huge differences cause problems, for instance Athena scrollbars were a stupid design. But these are solved quickly by competition between the toolkits. For example all the Unix toolkits quickly migrated to a Windows-style of key bindings, this would have been impossible if Unix had an enforced toolkit.
The "confused user" is a figment of the imagination of the people who are trying to force these toolkits down our throats. These people should get out of their theoretical ivory towers and examine exactly what the real programmers and users use and expect from their computers.
I do want to check out AtheOS, though. I suspect the necessary lower levels are there, because implementing a toolkit like they describe is impossible without them.
It does sound like AtheOS, although it implements the GUI as part of the system, implementes it as another task in user space using the microkernel=like communication mechanism. This sounds like an ok approach.
Although I do find the fact that there are "scrollbars" and "text edit" things in the interface (see the change log) indicates that he has made the GUI interface way too high level. I would much rather see an interface that reliably and quickly does "draw a rectangle here" and "format this UTF-8 text here" would be more powerful, as it would allow variation in the GUI design.
I still need to study the design and try it out to really get an opinion, though.