I don't think you quite got the point beind the line "information wants to be free". The joke is *all* information "wants to be free", even top-secret or personal information. That's why you have to work at keeping it secret. It's kind of like a law of thermodynamics, information spreads and is "free" unless you stop it. Just because we build refrigerators does not mean the laws of thermodynamics are false.
Not just the black market, *all* markets fund terrorism! You can be pretty sure that when you buy a candy bar, some fraction of a cent of the profit will end up with a terrorist. I guess we better ban ALL commerce! It funds terrorism!
Re:Separating Content from Presentation a Good Thi
on
Office 2003 and XML
·
· Score: 1
Well further reading showed that the article's authors had no idea what they were talking about and had checked an option that purposely deletes the data.
However my initial reading indicated that all the formatting information, including *where* it happens, is stripped. Ie if the the word BOLD is in bold, there is nothing left in the text between it and the non-bold text. It does not matter if that thing is an instruction that says "this is important" or an instrcution that says "render this in MicroSoft-Ariel-Bold at 12.389 points and.1 kerning", what matters is that the instruction is there.
By "seperating data from formatting" I mean that a program reading the document should be able to easily seperate it, not that it should be absent. I think this is what everybody *really* wants, and only some ivory-tower users want the presentation actually in a different file.
It word documents were readable and writable by other programs this would in no way hurt Microsoft's market. The ability to write little utility programs that process Word files would make Word *MORE* popular.
The Word editor itself has some features that nobody else has, and has a huge (much larger than Windows, apparently) body of developers, researchers, and testers behind it. It actually is a pretty useful and good product and it cannot be replicated by any smaller startup or open-source effort.
In truth MicroSoft can compete fairly on "innovation" and "features" and their Word market would be as big or larger than it is now. They would also get rid of some of the hostility directed toward them by everybody else in the industry, this hostility is probably hurting their sales more than any other competition is. It is also possible their engineers will produce better work, IMHO the evil company behavior is certainly affecting the desire of any engineer with a conscious to do quality work.
MicroSoft should stop acting like asses and start to show a cooperative face and they could change the entire attitude of the computer industry toward them, and still end up on the top of the heap or even more powerful than they are now.
Actually it was not what was expected on SlashDot. The most common prediction was for "unsuable" XML, most likely because all the interesting information was enclosed in a giant binary block (or maybe many small blocks). This would have kept the files closed but allowed them to say "XML" on their advertisements, and would allow MicroSoft Word to re-open these saved xml documents.
It appears they are doing worse than anybody predicted. They don't want to risk anybody even accidentally saving a file in XML by making sure they are severely punished by the deletion of all their formatting information. This will keep anybody from ever even trying it.
The enginneers at MicroSoft who write this stuff should be ashamed of themselves. I can't understand how they sleep at night.
Re:Separating Content from Presentation a Good Thi
on
Office 2003 and XML
·
· Score: 1
The point is to seperate them *in the same file*. This is not the same as deleting the presentation information!
Didn't this already happen? There was a story about somebody's Linux machine successfully propagating a Windows email virus, due to a Linux email program automatically (or maybe manually) executing a program attached to an email. The Windows executable was recognized and loaded the Wine libs and ran. The virus failed to infect the machine but it did succeed in opening the users address list (maybe a Windows address list on a mounted Windows drive) and emailing itself to everybody on the list.
This requires changing the rules in all the shells, which is really why it isn't done. But it needs to be done!
The rules for execution of a file need changes. There should be "app directories" like OS/X excecpt there should not be any ".app" in the directory name. If "foo" is such a directory then attempting to run "foo" will run either "foo/foo" or "foo/main" (I'm not sure which is better). When this happens argv[0] is forced to be the full name of "foo" so that the program can easily locate other files in the same directory. Also it sets LD_LIBRARY_PATH to have this directory at the start.
This would easily allow applications to be "installed" where the shell paths can see them, and even moved or renamed.
Couldn't the system crc-hash all memory-mapped read-only pages and use this to find identical ones and reuse the mapping? Automatically all matchine shared libraries and executables would reuse memory. Also I would suspect that, due to aligment restrictions, even statically-linked binaries would find matching pages and share them.
The only problem I see with this is that is may be slow to do the crc every time a new page is introduced. But if it is faster than reading the disk it seems this should work.
I'm not sure if patching libraries is that much of a problem. The real libraries that have bugs and need patching are the central system ones. The problem shared libraries are things like the giant Gnome library set, where there really isn't a "patch", instead all the libraries *and* all the programs are replaced at once. In these cases the shared libraries are there simply to reduce program size, and with this crc idea (plus perhaps a similar idea for disk file systems and compressed packages) the programs could in fact all be statically linked with all of Gnome.
Apple invented the ZXCV bindings for the Lisa, supposedly they did tests that showed the lower-left position was easier to learn than mnemonics. I suspect their programmers did not want to interfere with common Emacs meta keys and that is the real reason those keys were chosen.
Somehow MicroSoft failed to realize that the Apple key was more accurately represented by the Alt key and they used Ctrl instead. (actually a more likely explanation is that almost all DOS programs used Alt+letters for various things (again due to a desire to copy the Macintosh), while they tended not to use Ctrl+letters, and they wanted to make it easy to port DOS programs to Windows).
At the same time almost all Unix X programs that copied the Macintosh used Alt for this purpose. This led to all the complaints about Unix being "inconsistent" because some things used Alt+x while others (copying Microsoft) used Ctrl+x. Again it is MicroSoft that is the inconsistent one, but nobody believes that because no matter what stupid thing they do everybody says "that's standard".
its quite irritating to use middle mouse to paste in one program, ctrl-v in the other and shift-insert in the third
You are obviously just making things up. I think you will find that the vast majority of programs accepts ALL THREE of these.
If you really knew anything you would know that the "inconsistent" program is Emacs, which takes Ctrl+Y to paste. There are also very old programs that have no idea about pasting at all, but I'm sure you can find some Windows programs like DOS ports that don't pay attention to pasting either.
They synchronization you are talking about would require even more round-trips, I think. Best I can think of now is that when the window gets bigger the window manager immediately resizes it's frame and starts drawing everywhere including behind the new area of the window, and sends some message to tell the appliation to resize it's window and redraw it. Making the window smaller would require this message to be sent first and then wait for a synchronous reply and then resize the frame. This still won't solve a resize where the window gets taller but narrower. None of this is anywhere near as efficient as having the windows in the program, where the program can send out both resizes immediately followed by drawing commands to fix the display in a single non-synchronous block.
Even if it is all gotten to work, the non-synchronous nature is a serious burden to making GUI programs on X, and no toolkit can hide it well enough. The programmer really wants to be able to draw immediately into a window after they show it, and to set the size and immediately draw and assumme the new size is correct. All X toolkits either have serious delays and internal complexity in order to synchronize this stuff with the WM, or they just are inefficient (fltk does this) and redraw more times than necessary, resulting in blinking.
So I do not think there really is a solution. I am glad you agree it is at least a good idea to move the window manager closer. I think into the client is the best. If it was in the server we would be stuck in a fixed design for window management, and an entire "theme" interface would have to be added to X.
You are right about the vertical retrace. This sounds like an easy fix for X. Fltk (and probably other toolkits) read all pending events and don't draw anything until the pending events are exausted. X could take all events generated during a screen draw and send them as a single block per vertical retrace. This would make fltk and most other toolkits generate only a single block of drawing instructions per vertical retrace. It may also help if the *start* of drawing was delayed until the next vertical blanking, although a series of commands should continue to be obeyed even if it takes longer than the blanking.
I heard the problem with the jerky mouse is not X itself but the scheduling problems in Linux, which is being addressed with the new scheduling patches.
This is for use by people who will not be tortured for the keys, ie the UN workers who will be kicked out of the country after their equipment is confiscated. With this that equipment will not give the evil army information that they want.
Both systems need high-end graphics cards for 3d and there are plausible claims that the OpenGL->hardware interfaces are somewhat better under X than in Window's design.
But you are in denial if you believe X11 is as fast as NT in updating the display for simple graphics. Moving windows is by far the worst difference in speed but I cannot see anything where X11 is actually better than NT. This is based on direct comparisons of two quite slow machines (350Mhz Pentiums) running Linux and NT4.0.
The problem is entirely in X11's old design and their total inability to make the slightest changes or enhancements to it.
Some people claim the problem is the client/server but that is only a *latency* problem, not a speed problem (if you can batch a thousand calls into a single communication you actually have achieve 500 times more efficency than Windows kernel implementation where every call is a context switch). Latency is a problem we are going to have to deal with anyway in a networked system, for instance web page user interfaces are severly limited by it.
However X11's graphics design and the horrendous mess of ICCCM window managers mean that virtually every call is "synchronous" in that any practical program cannot continue until it recieves a response from the previous call. This means the latency translates directly into a loss of speed. For typical graphics you get 2 latencies, for making a change to a window you get almost 4!
We need a new graphics system, with static "contexts" like OpenGL has, and NO RETURN VALUES so it is impossible to require synchronization, at least PostScript capabilities of drawing, and the ability to render UTF-8 text as good as possible without a gigantic client-side library!
We also need to scrap window managers and move the windows into the toolkits. Yes this means windows will have different borders, just DEAL with it. Worrying about "inconsistent interfaces" and "confusing the user" is delaying the need to do what needs to be done. Maybe one toolkit will take over, or all the toolkits will start to agree on appearances. Or maybe some *NEW* ideas will appear (HORRORS! An "inconsistent" new idea! Oh the poor "confused" users!) and we can finally laugh at Bill Gates by showing what "innovation" means.
Both Linux and Windows will stop working if the root user deletes enough files, but they will both likely stop with some kind of error like "Unable to locate file blah, I can't continue", which is not really a bug because in fact they are doing exactly what they are supposed to do.
What he was looking for was a BSOD (or a kernel panic on Linux) or perhaps mysterious lockups (which are now much more common on both systems than actual crashes).
I also agree. But there are ways to fix this that don't involve "modes". For Ctrl+A I would have it go to the start of the line, and the *second* Ctrl+A does select-all. Goto start-of-line is enormousely more useful than select-all and we should not copy Windows in ways that reduce functionality, but there are many tricks you can do to be "compatable enough" to not confuse new users.
Using KDE or Windows I am really being killed by ^A,^E, and ^K not working. The movement keys like ^F,^B,^N,^P are not really necessary but it is extremely annoying that they bring up sometimes dangerous things like printing, they should either act like Emacs or do nothing. Check some Windows users, I think most use the menu to print and would never notice the loss of the ^P shortcut.
Personally I would like to see emacs bindings for ^A,B,D,E,F,K,N,P supported. There also appears to be demand for ^T and ^W, and maybe ^O. ^Q should not be supported as it is not user-friendly because it eats the next keystroke. ^S and ^R should only work if it is a real incremental search.
Conversly there is no reason not to have ^Z be undo, ^X be cut, ^C be copy, and ^V be paste. They don't interfere with important Emacs commands. Certainly "emacs mode" should not turn these off!
Hurting much worse is that Ctrl+P brings up the print dialog.
I think what Microsoft is doing and what the original poster is looking for is something more/different than "task-oriented UI". The original Mac/Lisa had a "task oriented UI" and it quickly became obvious that it does not match how people think. Despite the initial appearance to the contrary, people really do clearly understand and like the idea of "I am going to run MicroSoft Word and then edit these three papers with it, and I am going to run Photoshop and paint this picture with it" verses "I am going to work on these 4 documents". Part of the problem may be that this is the only way to market Photoshop and MicroSoft Word so people feel they are buying something worth money, but I feel it is more than that, that in fact the way the machines work today may actually match how human brains work. This despite the fact that all logic and my own feelings are that "task oriented" is better, but it looks like in the real world I have been proven wrong.
Contrary to popular belief it is possible to run non-Qt programs under KDE. IMHO the most useful stuff coming out of the Gnome+KDE cooperation is the relativley simple documentation of protocols like the window manager hints and so on that are not tied to *any* toolkit. These are working very well to eliminate any true need to use Qt, other than convienence. I think the KDE developers are well aware that any core interface cannot be "use the code in Qt for this" since that in effect closes it as much as Windows.
If you actually wrote X11 programs or toolkits you would know that using X11 child windows for each child widget is *extremely* inefficient and slow. Motif was forced to add "gadgets" (as they called them) to get around this problem (these were a new type of "widget" that did not create an X window). Modern toolkits were written by people who are well aware of this problem and actively try to use as *few* windows as possible.
The only reasons for using child windows is lameness in the X drawing copabilities. You need them if you need different "visuals", you need them to enforce clipping such as when you want a program you don't trust to draw into an area, and you need them for efficient scrolling of areas with correct exposure events.
Sounds more to me like programs using Xft can draw on servers without XRender but they use the *normal* bitmapped fonts.
However this was already true of even the first Xft (which is the *only* X "extension" that has ever been correctly written so the poor programmer does not have to "detect extension and do two versions of their code"). So this feature may indicate something more.
Actually the XRender extension does do what is needed. "compositing" of the alpha-transparency characters are done on the server, while before transparency requred the app to read what was on the screen (or more likely, remember what it drew there before) and do the compositing itself and send the resulting image back. Also XRender caches the glyphs on the server, or so I am lead to believe. Technically this addresses all of the real issues with supporting antialiased fonts.
Although technically wrong, your complaints do match what I have about where X is going. The people designing X seem to be obsessed with backwards compatability, or unable to see methods of improving X which reuse existing interfaces in nice ways, and instead keep adding interfaces and "extensions".
I think it is pretty inexcusable that programs using the older Xlib interface do not get the exact same set of anti-aliased fonts that newer Xft interfaces get. They should be ashamed of the fact that MicroSoft reused their interface (earlier Windows versions used aliased fonts almost as bad as X11 has) and all programs got antialiased fonts without being rewritten.
I also hear about the RandR "extension" and all the additions needed for that. I don't think any new calls are needed for window managers, just have the root report a normal resize event. Yes *some* window managers may crash when they get that, but those window managers should be fixed, rather than adding yet another complex interface to X. I suspect fixing these window managers would be much easier for programmers than figuring out this new interface.
As for drawing, why can't they fix X so we are *guaranteed* to get a 32-bit truecolor "visual" and *guaranteed* that support for 24 and 32 bit image maps (and perhaps every 3*2^n and 4*2^n bits). These can be easily emulated on hardware with colormaps or fewer bits, with MUCH less code than toolkits that are forced to translate between all possible images and all possible visuals (the server has it much easier as it only has to translate from all possible images to a *single* visual). And a huge and ugly block of code could be eliminated from programs because they would no longer have to contain a translation to every possible visual they may encounter.
Besides those three, there are probably hundreds of other examples where X is failing to be creative in updating to the modern world.
If there is some outward pressure from solar wind, wouldn't it increase by 1 over the square of the distance as you got closer? A given area of ring, if twice as close, would intersect 4 times as much rays shooting directly out of the sun. If the ring is made of some material that magically does this with greater force than the inward gravity, this would counteract any tendency to go off-center and stabilize it around the sun. Of course it would also shoot it perpendicularily along the axis, but that might be solved by making the ring a tiny cross-section of a sphere so each edge tries to move away.
Slashdot Mirror
I don't think you quite got the point beind the line "information wants to be free". The joke is *all* information "wants to be free", even top-secret or personal information. That's why you have to work at keeping it secret. It's kind of like a law of thermodynamics, information spreads and is "free" unless you stop it. Just because we build refrigerators does not mean the laws of thermodynamics are false.
Not just the black market, *all* markets fund terrorism! You can be pretty sure that when you buy a candy bar, some fraction of a cent of the profit will end up with a terrorist. I guess we better ban ALL commerce! It funds terrorism!
However my initial reading indicated that all the formatting information, including *where* it happens, is stripped. Ie if the the word BOLD is in bold, there is nothing left in the text between it and the non-bold text. It does not matter if that thing is an instruction that says "this is important" or an instrcution that says "render this in MicroSoft-Ariel-Bold at 12.389 points and .1 kerning", what matters is that the instruction is there.
By "seperating data from formatting" I mean that a program reading the document should be able to easily seperate it, not that it should be absent. I think this is what everybody *really* wants, and only some ivory-tower users want the presentation actually in a different file.
The Word editor itself has some features that nobody else has, and has a huge (much larger than Windows, apparently) body of developers, researchers, and testers behind it. It actually is a pretty useful and good product and it cannot be replicated by any smaller startup or open-source effort.
In truth MicroSoft can compete fairly on "innovation" and "features" and their Word market would be as big or larger than it is now. They would also get rid of some of the hostility directed toward them by everybody else in the industry, this hostility is probably hurting their sales more than any other competition is. It is also possible their engineers will produce better work, IMHO the evil company behavior is certainly affecting the desire of any engineer with a conscious to do quality work.
MicroSoft should stop acting like asses and start to show a cooperative face and they could change the entire attitude of the computer industry toward them, and still end up on the top of the heap or even more powerful than they are now.
It appears they are doing worse than anybody predicted. They don't want to risk anybody even accidentally saving a file in XML by making sure they are severely punished by the deletion of all their formatting information. This will keep anybody from ever even trying it.
The enginneers at MicroSoft who write this stuff should be ashamed of themselves. I can't understand how they sleep at night.
The point is to seperate them *in the same file*. This is not the same as deleting the presentation information!
Didn't this already happen? There was a story about somebody's Linux machine successfully propagating a Windows email virus, due to a Linux email program automatically (or maybe manually) executing a program attached to an email. The Windows executable was recognized and loaded the Wine libs and ran. The virus failed to infect the machine but it did succeed in opening the users address list (maybe a Windows address list on a mounted Windows drive) and emailing itself to everybody on the list.
The rules for execution of a file need changes. There should be "app directories" like OS/X excecpt there should not be any ".app" in the directory name. If "foo" is such a directory then attempting to run "foo" will run either "foo/foo" or "foo/main" (I'm not sure which is better). When this happens argv[0] is forced to be the full name of "foo" so that the program can easily locate other files in the same directory. Also it sets LD_LIBRARY_PATH to have this directory at the start.
This would easily allow applications to be "installed" where the shell paths can see them, and even moved or renamed.
The only problem I see with this is that is may be slow to do the crc every time a new page is introduced. But if it is faster than reading the disk it seems this should work.
I'm not sure if patching libraries is that much of a problem. The real libraries that have bugs and need patching are the central system ones. The problem shared libraries are things like the giant Gnome library set, where there really isn't a "patch", instead all the libraries *and* all the programs are replaced at once. In these cases the shared libraries are there simply to reduce program size, and with this crc idea (plus perhaps a similar idea for disk file systems and compressed packages) the programs could in fact all be statically linked with all of Gnome.
However you could not incorporate any GPL code into it because the GPL does not allow it's code to be restricted by such rules.
Apple invented the ZXCV bindings for the Lisa, supposedly they did tests that showed the lower-left position was easier to learn than mnemonics. I suspect their programmers did not want to interfere with common Emacs meta keys and that is the real reason those keys were chosen.
Somehow MicroSoft failed to realize that the Apple key was more accurately represented by the Alt key and they used Ctrl instead. (actually a more likely explanation is that almost all DOS programs used Alt+letters for various things (again due to a desire to copy the Macintosh), while they tended not to use Ctrl+letters, and they wanted to make it easy to port DOS programs to Windows).
At the same time almost all Unix X programs that copied the Macintosh used Alt for this purpose. This led to all the complaints about Unix being "inconsistent" because some things used Alt+x while others (copying Microsoft) used Ctrl+x. Again it is MicroSoft that is the inconsistent one, but nobody believes that because no matter what stupid thing they do everybody says "that's standard".
You are obviously just making things up. I think you will find that the vast majority of programs accepts ALL THREE of these.
If you really knew anything you would know that the "inconsistent" program is Emacs, which takes Ctrl+Y to paste. There are also very old programs that have no idea about pasting at all, but I'm sure you can find some Windows programs like DOS ports that don't pay attention to pasting either.
They synchronization you are talking about would require even more round-trips, I think. Best I can think of now is that when the window gets bigger the window manager immediately resizes it's frame and starts drawing everywhere including behind the new area of the window, and sends some message to tell the appliation to resize it's window and redraw it. Making the window smaller would require this message to be sent first and then wait for a synchronous reply and then resize the frame. This still won't solve a resize where the window gets taller but narrower. None of this is anywhere near as efficient as having the windows in the program, where the program can send out both resizes immediately followed by drawing commands to fix the display in a single non-synchronous block.
Even if it is all gotten to work, the non-synchronous nature is a serious burden to making GUI programs on X, and no toolkit can hide it well enough. The programmer really wants to be able to draw immediately into a window after they show it, and to set the size and immediately draw and assumme the new size is correct. All X toolkits either have serious delays and internal complexity in order to synchronize this stuff with the WM, or they just are inefficient (fltk does this) and redraw more times than necessary, resulting in blinking.
So I do not think there really is a solution. I am glad you agree it is at least a good idea to move the window manager closer. I think into the client is the best. If it was in the server we would be stuck in a fixed design for window management, and an entire "theme" interface would have to be added to X.
You are right about the vertical retrace. This sounds like an easy fix for X. Fltk (and probably other toolkits) read all pending events and don't draw anything until the pending events are exausted. X could take all events generated during a screen draw and send them as a single block per vertical retrace. This would make fltk and most other toolkits generate only a single block of drawing instructions per vertical retrace. It may also help if the *start* of drawing was delayed until the next vertical blanking, although a series of commands should continue to be obeyed even if it takes longer than the blanking.
I heard the problem with the jerky mouse is not X itself but the scheduling problems in Linux, which is being addressed with the new scheduling patches.
This is for use by people who will not be tortured for the keys, ie the UN workers who will be kicked out of the country after their equipment is confiscated. With this that equipment will not give the evil army information that they want.
But you are in denial if you believe X11 is as fast as NT in updating the display for simple graphics. Moving windows is by far the worst difference in speed but I cannot see anything where X11 is actually better than NT. This is based on direct comparisons of two quite slow machines (350Mhz Pentiums) running Linux and NT4.0.
The problem is entirely in X11's old design and their total inability to make the slightest changes or enhancements to it.
Some people claim the problem is the client/server but that is only a *latency* problem, not a speed problem (if you can batch a thousand calls into a single communication you actually have achieve 500 times more efficency than Windows kernel implementation where every call is a context switch). Latency is a problem we are going to have to deal with anyway in a networked system, for instance web page user interfaces are severly limited by it.
However X11's graphics design and the horrendous mess of ICCCM window managers mean that virtually every call is "synchronous" in that any practical program cannot continue until it recieves a response from the previous call. This means the latency translates directly into a loss of speed. For typical graphics you get 2 latencies, for making a change to a window you get almost 4!
We need a new graphics system, with static "contexts" like OpenGL has, and NO RETURN VALUES so it is impossible to require synchronization, at least PostScript capabilities of drawing, and the ability to render UTF-8 text as good as possible without a gigantic client-side library!
We also need to scrap window managers and move the windows into the toolkits. Yes this means windows will have different borders, just DEAL with it. Worrying about "inconsistent interfaces" and "confusing the user" is delaying the need to do what needs to be done. Maybe one toolkit will take over, or all the toolkits will start to agree on appearances. Or maybe some *NEW* ideas will appear (HORRORS! An "inconsistent" new idea! Oh the poor "confused" users!) and we can finally laugh at Bill Gates by showing what "innovation" means.
If you read my post you would see that I was suggesting a way to *make* there be one keybinding. The second press of Ctrl+A would act like Windows.
Both Linux and Windows will stop working if the root user deletes enough files, but they will both likely stop with some kind of error like "Unable to locate file blah, I can't continue", which is not really a bug because in fact they are doing exactly what they are supposed to do.
What he was looking for was a BSOD (or a kernel panic on Linux) or perhaps mysterious lockups (which are now much more common on both systems than actual crashes).
Using KDE or Windows I am really being killed by ^A,^E, and ^K not working. The movement keys like ^F,^B,^N,^P are not really necessary but it is extremely annoying that they bring up sometimes dangerous things like printing, they should either act like Emacs or do nothing. Check some Windows users, I think most use the menu to print and would never notice the loss of the ^P shortcut.
Personally I would like to see emacs bindings for ^A,B,D,E,F,K,N,P supported. There also appears to be demand for ^T and ^W, and maybe ^O. ^Q should not be supported as it is not user-friendly because it eats the next keystroke. ^S and ^R should only work if it is a real incremental search.
Conversly there is no reason not to have ^Z be undo, ^X be cut, ^C be copy, and ^V be paste. They don't interfere with important Emacs commands. Certainly "emacs mode" should not turn these off!
Hurting much worse is that Ctrl+P brings up the print dialog.
There are ways to fix t
I think what Microsoft is doing and what the original poster is looking for is something more/different than "task-oriented UI". The original Mac/Lisa had a "task oriented UI" and it quickly became obvious that it does not match how people think. Despite the initial appearance to the contrary, people really do clearly understand and like the idea of "I am going to run MicroSoft Word and then edit these three papers with it, and I am going to run Photoshop and paint this picture with it" verses "I am going to work on these 4 documents". Part of the problem may be that this is the only way to market Photoshop and MicroSoft Word so people feel they are buying something worth money, but I feel it is more than that, that in fact the way the machines work today may actually match how human brains work. This despite the fact that all logic and my own feelings are that "task oriented" is better, but it looks like in the real world I have been proven wrong.
Contrary to popular belief it is possible to run non-Qt programs under KDE. IMHO the most useful stuff coming out of the Gnome+KDE cooperation is the relativley simple documentation of protocols like the window manager hints and so on that are not tied to *any* toolkit. These are working very well to eliminate any true need to use Qt, other than convienence. I think the KDE developers are well aware that any core interface cannot be "use the code in Qt for this" since that in effect closes it as much as Windows.
The only reasons for using child windows is lameness in the X drawing copabilities. You need them if you need different "visuals", you need them to enforce clipping such as when you want a program you don't trust to draw into an area, and you need them for efficient scrolling of areas with correct exposure events.
However this was already true of even the first Xft (which is the *only* X "extension" that has ever been correctly written so the poor programmer does not have to "detect extension and do two versions of their code"). So this feature may indicate something more.
Although technically wrong, your complaints do match what I have about where X is going. The people designing X seem to be obsessed with backwards compatability, or unable to see methods of improving X which reuse existing interfaces in nice ways, and instead keep adding interfaces and "extensions".
I think it is pretty inexcusable that programs using the older Xlib interface do not get the exact same set of anti-aliased fonts that newer Xft interfaces get. They should be ashamed of the fact that MicroSoft reused their interface (earlier Windows versions used aliased fonts almost as bad as X11 has) and all programs got antialiased fonts without being rewritten.
I also hear about the RandR "extension" and all the additions needed for that. I don't think any new calls are needed for window managers, just have the root report a normal resize event. Yes *some* window managers may crash when they get that, but those window managers should be fixed, rather than adding yet another complex interface to X. I suspect fixing these window managers would be much easier for programmers than figuring out this new interface.
As for drawing, why can't they fix X so we are *guaranteed* to get a 32-bit truecolor "visual" and *guaranteed* that support for 24 and 32 bit image maps (and perhaps every 3*2^n and 4*2^n bits). These can be easily emulated on hardware with colormaps or fewer bits, with MUCH less code than toolkits that are forced to translate between all possible images and all possible visuals (the server has it much easier as it only has to translate from all possible images to a *single* visual). And a huge and ugly block of code could be eliminated from programs because they would no longer have to contain a translation to every possible visual they may encounter.
Besides those three, there are probably hundreds of other examples where X is failing to be creative in updating to the modern world.
The source for NeWS is not available, unfortunately.
Or am I completely wrong?