X can support an hourglass: It would only be an hourglass when pointed at the windows belonging to the program that is busy, this may be considered a bug by people used to Windows but it is more accurate in that you can click on the other programs and work on them so the cursor should not be an hourglass. This behavior also makes perfect sense to anybody using point-to-type. You could duplicte Window's behavior with some server grabs but that is probably a bad idea!
It actually is pretty easy to support the hourglass, so there is a question of why programs don't do it. My programs don't do it, incidentally. Perhaps programmers are lazy.
When you ctrl+alt+backspace it DOES restart X. In fact X has no protocol for logging out so this is the only way this can possibly work.
It is true that unless the monitor reports the new size restarting X without editing the config files is not going to help. Since Windows seems to require manual changing of the resolution, it sounds like these projectors do not report the size.
If MS released the full source for Windows XP (and there were no restrictions on what you could do with the code) I would expect open-source hackers to quickly alter it to include Unix functionality (like Cygwin, adding fork and stuff to the kernel, adding symbolic links, the ability for the same program to have a GUI and be a daemon, adhere to network standards, and whatever else is missing) without changing the upper levels of the GUI. It would then be Unix with a Windows GUI and Windows libraries for all those functions that are missing on Linux, and the ability to run Windows programs (and non-X Unix programs with a recompile). Probably the GUI would be hacked a little, but I suspect mostly to add virtual desktops and support point-to-type correctly and make VNC work all the time.
I think the result would be enourmously popular, it would wipe Linux and OS/X and every other system in the desktop world off the map within months. There may be some fight between several "forks" for a few weeks at most before one of them became popular enough that everybody sent their change ideas to that project and it became the standard.
It really would be a good thing (unless you really think Linux is better because it is Linux and not because it is Open Source...). It would even be good for MicroSoft as they could jettison an expensive part of their operations and concentrate on services and Word/Office.
But it is NOT going to happen because Bill Gates would rather die first.
Second, cutting and pasting has never been a problem in the X environment with *any piece of software*
but KDE 1 and 2. There have been established standards for cut-and-paste interoperability for X some time
(Athena era, at least). KDE broke those, and didn't enter compliance until KDE 3.0. If KDE doesn't work with
a compliant piece of software, that's KDE's fault. Mozilla is not to blame here.
Actually *LOTS* of software did the same thing as KDE/Qt. I know, I wrote some of it (fltk until a year ago worked this way). In fact at one time the few programs that worked the modern way were considered broken.
The real problem is that X had "drag and drop" long before anybody else, but you dragged by selecting the thing to drag and dropped by clicking the middle mouse button. Think about it and you will see that X selection is exactly like drag n drop, except with the advantage that you can rearrange the windows and open new ones before dropping (thus no "spring loaded folders" or other kludges are needed).
When Mac and Windows came out with cut/copy/paste, though, nobody realized the X mechanism was fundementally different and in fact a GUI idea that was not going to occur to the Windows designers for a few more years. So the cut/copy/paste was often crammed into this drag n drop interface, resulting in the "cut copy paste does not work" situation.
Whether that is good or bad (there are arguments both ways), it has nothing to with the average user experience. Do you think the average Windows user edits the registry with regedit, and if they are forced to, they say "oh this is easy because all the data is stored in the same structured format?"
Unfortunately most of the problems are way over that level. Windows provides some friendly interfaces that change some registry entries, without them it would be exactly the same as the Linux problems (or worse, at least Linux configuration files sometimes have comments in them saying what the fields do).
I agree nobody is going to pay extra for the two-system game. However putting both versions on the disk for the same price may work. Id software did not release the Linux version at the same time as the other version and charged significantly extra for it, if I recall. It was doomed to failure. However I think if porting to Linux was easy there may be some companies that put the Linux copy on the disk at the same time they release it for Windows. It doesn't even have to work very well, just recompile without any tweaking for performance, the game would probably be pretty popular amoung Linux people.
My experience with OpenGL on both Wind32 and X is that the Win32 initialization is actually slightly cleaner. X's big loss is that you have to decide you are going to use OpenGL before you even create the window (because of those damn visuals). MicroSoft's WGL big loss is that you cannot share OpenGL contexts between windows and you must destroy them when you destroy windows. MicroSoft's method of supporting overlays is better than the X one where they are a seperate window, in particular they provide a call that can swap both the overlay and main window together. I have seen lots of bugs in the NT version of OpenGL, however, such as lines and text not drawing in the foreground buffer.
Neither the X or Win32 system is "good" for any reasonable definition of the word "good". I should be able to draw using OpenGL into *any* window, at *any* time, by telling it to "draw into this window" with one call. I don't know who designs this stuff...
They can do anything they want as long as they don't pass laws that restrict our ability to use devices we have purchased.
For instance your movie producer can restrict showings to movie theatres and check everybody at the door to make sure they don't bring in a recording device. I seem to remember this was a popular way to make money on movies once upon a time...
They are also allowed to prosecute anyone they find posting or selling their copyrighted movie.
Both of these are well within their rights and do not require legislation.
Yes it is true that most X window managers have a way to turn off click-to-raise, which certainly is better than Windows. I have my KDE configured this way. It would still help if this was the default, however, so applications could assumme it!
Number 2 is the real killer for me however. It makes it impossible to have a modal window that stays on top and still allow an application to have overlapping main windows. Every single modern X window manager, and Windows, and OS/X, have this annoying behavior. I think this could easily be fixed but the designers are sheep and are scared to death of being different.
On my KDE alt+left does nothing, however I did notice that the right mouse button pops up a menu that has "move" on it and that moves the window without raising it. Still not as nice as old fvwm behavior, in my opinion.
The reason you can't do this is X lacks any way to find out what the other application tried to draw on the obscured portion of the window. All such drawing is clipped and thrown away by the X server.
If you ignore changes, you could in theory allow the window to drag by remembering the entire screen initially and continuously redrawing the shadowed part. But I think the "real" edge would quickly become visible because the changing image would not be in sync with the window movement.
The trick for the drop shadows only works if the window will not be moved and there will be no change to the display below the window until it disappears. For this reason it is only good for pop-up (and pull-down) menus, and perhaps for tooltips.
What really is happening is the window is somewhat larger than it looks, it includes a bottom and right edge that have been painted with an image that looks just like what is behind it plus a shadow.
I'll suggest a change that would make Linux much superior to Windows because it will allow programs to use multiple overlapping windows:
DON'T RAISE WINDOWS UNLESS THE USER CLICKS ON THE BORDER!!!!
By this I mean:
1. When the user clicks in a window, give it the focus, but DONT RAISE IT.
2. (less obvious but NO modern window managers do this) When the user raises a "child" window, DO NOT RAISE THE PARENT!!!! This is the real killer that makes it impossible to have overlapping windows of any substantial size.
3. Provide a way to move windows around without raising them. For instance, why not the way X window managers worked for a decade before people starting thinking copying MicroSoft was kool: if the user drags the border, move the window and DO NOT RAISE IT, if they click they can raise it. Modern window managers seem to be unable to do this correctly, the KDE I am using cannot do this unless you turn off all ability to raise the windows.
I really really wish some of these people would do this. I do not believe it will "confuse" the amateur user, and it would allow some user interface designs that cannot be done with Windows. Mostly it would allow a single object to be controlled by 2 or more large "views" that overlap on the screen in different windows.
On another point, please test everything under point-to-type. If a program grabs the focus it should warp the mouse to point at it (after first making absolutely positively sure you really really really want to grab the focus).
I think the point is that they copied the GUI from MicroSoft. Of course you could do this years before MicroSoft thought of it by using VNC and typing the right cryptic thing on the command line on both machines, but nobody thought to make this user-friendly until they saw MicroSoft do it. That is what the original poster was saying.
That extension (XDBE) I believe is intended to be a hardware double buffer like OpenGL has. The double buffer only exists for the visible portion of the window (because in fact there is a single buffer that is the same size as the screen, shared by all the windows). Though this helps a lot for flicker-free it does not help for the window movement. But it does have advantages such as being able to use hardware acceleration and finite memory requirements.
What you describe is double buffering, and it could be done. There is a missing part of the X protocol, which is an indicator from the program that it is done updating the buffer and it needs to be copied to the screen (often called a swap-buffers call, though I recommend that X do a copy rather than swap and thus match OS/X). You also can get transparent windows this way.
One problem is that older programs won't call the "swap" function and the screen will not change except when expose events happen. Automatically copying every vertical retrace would remove a lot of the advantages of double buffering (such as flicker-free update no matter how stupid the program is). My recommendation is to fix xlib so requests to read events send the swap command, but I don't know if anything can be done about old remote X clients. I suspect these problems are the main reason this is not being done.
Sending one mouse event per vertical retrace is an excellent idea! On modern machines the response is so fast that the program and X may react before the vertical retrace is done, and you will get smooth display of many things, not just window moving, but the contents of the windows. And it won't require any additions to the X protocol and will work with old programs as well as new!
I have thought of solutions but none of them get around the problem that the window manager draws the border and the application draws the contents. The only real solution would be to scrap the window manager (except for it's "task management" job which would be to handle windows while they are iconized). That would require all X programs to be rewritten as they would otherwise appear like they do when you kill the window manager, with no border and no way to move or rearrange them.
A plausible part-way solution is this:
Add a WM_PROTOCOL that a program can use to indicate that it wants "resize requests". Then a compliant window manager would do absolutly nothing when the user attempts to resize the window except send the requested size to the application. The application can then resize the window to any size it wants, and also has the responsibility of resizing the window manager border window. This allows the application to batch all these resizes together along with all the repainting instructions. It also allows the application to make arbitrary rules about legal window sizes. The borders would still blink slightly because they will be drawn by the window manager slightly later.
1. Checked my sourcecode and it appears that WM_ERASEBKGND is a message sent to a window. If my app is working I send it to DefaultWindProc so I guess I am not ignoring it. As far as I can tell it does not blank the window to white, as I can purpously delay my drawing and then draw black and I see no blinking. If my app is dead it will never be processed (as I am not calling DispatchMessage), yet the screen still clears to white. My best guess is that Windows times out, perhaps seeing if I ever call DefaultWindProc with WM_ERASEBKGND and then clears the window if I take too long. This is on NT4.0, incidentally.
2. Yes you can use X pixmaps (and on NT you can use images) to make fake double-buffering. However this still requires a round trip to the app for it to say "the way to repaint is to copy this area". This is nowhere near as good as double-buffering understood by the system, as it is in OS/X and in the newer versions of Windows.
Is there some way to find out what files a package will install without installing it? This has always driven me nuts.
Also it ridiculous that "rpm packagename" (with no switches) does not do anything. I think it should either say "it's installed" or "do you want to install it y/n" or "can't install it because it needs these...". It should do the proper install if you confirm, with -v -H -whateverthehell you need.
I would also like to see "source rpms" that take a long time to install, but they automatically unpack the source, configure, make, install, and remove the source (you can save the source with some switch).
Being closed-source has anything to do with binary compatability. Both open and closed source could be binary compatable or incompatable. You could say that Windows made the right decision and Linux the wrong one, but you seem to be implying that either Linux could not do this because of open source, or that closed source somehow forced Windows to do this. That is wrong.
Actually the slow window dragging *IS* a problem with X's design. However it is not due to the client/server architecture as most people think. It is due to "synchronous" calls (calls that return an answer) and the fact that a major part of the GUI is seperated into a program called the "window manager".
The first thing to realize is that the "slowness" is not actually slowness but blinking and flashing of intermediate displays before the final one is shown. If when you moved a window it jumped every second to follow the mouse, but jumped exactly and cleanly with all the underlaying windows appearing fully-drawn instantly, it would probably be more preferrable to the way X works now.
The problem is primarily due to the seperate window manager. This guarantees that windows will move and resize at a different time than their contents are redrawn. This is because the window manager moves the window, but then exposure or resize events must be delivered to a different application which then generates the drawing. If the same program could deliver the move and drawing instructions in a single block it would look way smoother. Unlike what a lot of people think, latency is NOT an issue, what is important is that all the instructions come from the same program and can be delivered as one block. This in particular makes resizing terrible on X, window dragging is about equal on X and Windows nowadays.
Another problem was "visuals" which produced annoying color flashing. Fortunately XFree86 has pretty much gotten rid of these on Linux, but if you try an Irix or Sun machine you will see this lovely stupidity in action. This is just BAD design, a proper design would consider the visual part of the "paint" so you don't change a pixel's visual until it is drawn.
Another problem is background clearing, which made sense on older slow machines but produces annoying flashes nowadays, as when you expose an area it is changed twice, first to the background, then to the final display. Windows does not do this (it does do some kind of timeout and clear to white so that dead programs don't end up with garbage in them, but in normal use this does not happen).
Just wanted to add that if MicroSoft's tab completion was a good design, it would be consistent to always put the first filename up instantly when you type tab on a blank, and they don't do that. And the browser completion would be consistent if when you blanked it it automatically showed the first know site in alphabetical order, pre-selected.
Think about it. Also try both systems, and perhaps learn a little.
Unfortunatley that solution is modal, and completely violates all user interface guidelines. You lose the state if you type another letter, for instance if you predicted it was going to match and then tried to add more commands. To revert you have to backspace an arbitrary number of characters (depending on how many were in the first matching filename) and then hit tab again. Also if you hit return you may read or write an existing file that you did not want to, which is a disaster.
In bash/tcsh tab-completion, only the matching letters are added. If you type a few extra letters you can backspace the same number of characters, and you are in the same state as before. Also if you hit return you have named a file that does not exist, so the program will either fail (because it can't read it) or it will write it and at least you did not destroy anything because the file did not exist before.
Web browsers try to remove the modal state by "selecting" the addition. This is technically true (if the actual text is used to identify the location in the list, I suspect they really keep a parallel modal index number). However it makes it difficult to name a new object that has more letters on the end, or for command lines to add more words after the first.
I won't get into "Combo Box" completion. It is just too horrific, even the individual letters are modal. Unf**kingbelivable.
It is shameful that MicroSoft and the web browsers did not at least look at how Unix had been solving these problems for a decade. I believe the main reason for the hate for MicroSoft is because so many good ideas have been discarded by their ignorance of what has been done before.
No, the ideas were invented by the card manufacturers. What MicroSoft did was add an interface to DirectX so a program can use these extensions (or an emulation of them when the card does not have it) without having to figure out what card it is and writing special code for the card. This is a significant development but in no way can be considered "inventing" the idea.
Their unified interface probably contains some data structures to encapsulate the abilities that do not match the data structures made by the card manufacturers. Most likely these data structures are a better design than what the card manufacturers made since they encapsulate the abilities of several cards, and it sounds like this is what MicroSoft is making a patent claim on.
This is really unfortunate as it will force OpenGL to use different structures. This will make it a pain to port programs between OpenGL and DirectX. In any sensible world simple interface ideas would be stolen from either system and put in the other, with no comment whatsoever from the companies. Imagine if read/write/seek interface to files had been patented, this is equivalent.
The lack of drivers, especially for the graphics cards, is really a hurting point for any alternative OS.
I have heard that the division between the driver back-end of XFree86 and the "X" part is getting better and cleaner, which may lead to eventually being able to use XFree86 drivers. But I doubt it is there yet because I don't see it being done now.
Slashdot Mirror
It actually is pretty easy to support the hourglass, so there is a question of why programs don't do it. My programs don't do it, incidentally. Perhaps programmers are lazy.
It is true that unless the monitor reports the new size restarting X without editing the config files is not going to help. Since Windows seems to require manual changing of the resolution, it sounds like these projectors do not report the size.
I think the result would be enourmously popular, it would wipe Linux and OS/X and every other system in the desktop world off the map within months. There may be some fight between several "forks" for a few weeks at most before one of them became popular enough that everybody sent their change ideas to that project and it became the standard.
It really would be a good thing (unless you really think Linux is better because it is Linux and not because it is Open Source...). It would even be good for MicroSoft as they could jettison an expensive part of their operations and concentrate on services and Word/Office.
But it is NOT going to happen because Bill Gates would rather die first.
but KDE 1 and 2. There have been established standards for cut-and-paste interoperability for X some time
(Athena era, at least). KDE broke those, and didn't enter compliance until KDE 3.0. If KDE doesn't work with
a compliant piece of software, that's KDE's fault. Mozilla is not to blame here.
Actually *LOTS* of software did the same thing as KDE/Qt. I know, I wrote some of it (fltk until a year ago worked this way). In fact at one time the few programs that worked the modern way were considered broken.
The real problem is that X had "drag and drop" long before anybody else, but you dragged by selecting the thing to drag and dropped by clicking the middle mouse button. Think about it and you will see that X selection is exactly like drag n drop, except with the advantage that you can rearrange the windows and open new ones before dropping (thus no "spring loaded folders" or other kludges are needed).
When Mac and Windows came out with cut/copy/paste, though, nobody realized the X mechanism was fundementally different and in fact a GUI idea that was not going to occur to the Windows designers for a few more years. So the cut/copy/paste was often crammed into this drag n drop interface, resulting in the "cut copy paste does not work" situation.
Unfortunately most of the problems are way over that level. Windows provides some friendly interfaces that change some registry entries, without them it would be exactly the same as the Linux problems (or worse, at least Linux configuration files sometimes have comments in them saying what the fields do).
My experience with OpenGL on both Wind32 and X is that the Win32 initialization is actually slightly cleaner. X's big loss is that you have to decide you are going to use OpenGL before you even create the window (because of those damn visuals). MicroSoft's WGL big loss is that you cannot share OpenGL contexts between windows and you must destroy them when you destroy windows. MicroSoft's method of supporting overlays is better than the X one where they are a seperate window, in particular they provide a call that can swap both the overlay and main window together. I have seen lots of bugs in the NT version of OpenGL, however, such as lines and text not drawing in the foreground buffer.
Neither the X or Win32 system is "good" for any reasonable definition of the word "good". I should be able to draw using OpenGL into *any* window, at *any* time, by telling it to "draw into this window" with one call. I don't know who designs this stuff...
If you think they are going to allow refunds because of this you are sadly deluded.
For instance your movie producer can restrict showings to movie theatres and check everybody at the door to make sure they don't bring in a recording device. I seem to remember this was a popular way to make money on movies once upon a time...
They are also allowed to prosecute anyone they find posting or selling their copyrighted movie.
Both of these are well within their rights and do not require legislation.
Number 2 is the real killer for me however. It makes it impossible to have a modal window that stays on top and still allow an application to have overlapping main windows. Every single modern X window manager, and Windows, and OS/X, have this annoying behavior. I think this could easily be fixed but the designers are sheep and are scared to death of being different.
On my KDE alt+left does nothing, however I did notice that the right mouse button pops up a menu that has "move" on it and that moves the window without raising it. Still not as nice as old fvwm behavior, in my opinion.
If you ignore changes, you could in theory allow the window to drag by remembering the entire screen initially and continuously redrawing the shadowed part. But I think the "real" edge would quickly become visible because the changing image would not be in sync with the window movement.
What really is happening is the window is somewhat larger than it looks, it includes a bottom and right edge that have been painted with an image that looks just like what is behind it plus a shadow.
DON'T RAISE WINDOWS UNLESS THE USER CLICKS ON THE BORDER!!!!
By this I mean:
1. When the user clicks in a window, give it the focus, but DONT RAISE IT.
2. (less obvious but NO modern window managers do this) When the user raises a "child" window, DO NOT RAISE THE PARENT!!!! This is the real killer that makes it impossible to have overlapping windows of any substantial size.
3. Provide a way to move windows around without raising them. For instance, why not the way X window managers worked for a decade before people starting thinking copying MicroSoft was kool: if the user drags the border, move the window and DO NOT RAISE IT, if they click they can raise it. Modern window managers seem to be unable to do this correctly, the KDE I am using cannot do this unless you turn off all ability to raise the windows.
I really really wish some of these people would do this. I do not believe it will "confuse" the amateur user, and it would allow some user interface designs that cannot be done with Windows. Mostly it would allow a single object to be controlled by 2 or more large "views" that overlap on the screen in different windows.
On another point, please test everything under point-to-type. If a program grabs the focus it should warp the mouse to point at it (after first making absolutely positively sure you really really really want to grab the focus).
I think the point is that they copied the GUI from MicroSoft. Of course you could do this years before MicroSoft thought of it by using VNC and typing the right cryptic thing on the command line on both machines, but nobody thought to make this user-friendly until they saw MicroSoft do it. That is what the original poster was saying.
That extension (XDBE) I believe is intended to be a hardware double buffer like OpenGL has. The double buffer only exists for the visible portion of the window (because in fact there is a single buffer that is the same size as the screen, shared by all the windows). Though this helps a lot for flicker-free it does not help for the window movement. But it does have advantages such as being able to use hardware acceleration and finite memory requirements.
One problem is that older programs won't call the "swap" function and the screen will not change except when expose events happen. Automatically copying every vertical retrace would remove a lot of the advantages of double buffering (such as flicker-free update no matter how stupid the program is). My recommendation is to fix xlib so requests to read events send the swap command, but I don't know if anything can be done about old remote X clients. I suspect these problems are the main reason this is not being done.
Sending one mouse event per vertical retrace is an excellent idea! On modern machines the response is so fast that the program and X may react before the vertical retrace is done, and you will get smooth display of many things, not just window moving, but the contents of the windows. And it won't require any additions to the X protocol and will work with old programs as well as new!
A plausible part-way solution is this:
Add a WM_PROTOCOL that a program can use to indicate that it wants "resize requests". Then a compliant window manager would do absolutly nothing when the user attempts to resize the window except send the requested size to the application. The application can then resize the window to any size it wants, and also has the responsibility of resizing the window manager border window. This allows the application to batch all these resizes together along with all the repainting instructions. It also allows the application to make arbitrary rules about legal window sizes. The borders would still blink slightly because they will be drawn by the window manager slightly later.
1. Checked my sourcecode and it appears that WM_ERASEBKGND is a message sent to a window. If my app is working I send it to DefaultWindProc so I guess I am not ignoring it. As far as I can tell it does not blank the window to white, as I can purpously delay my drawing and then draw black and I see no blinking. If my app is dead it will never be processed (as I am not calling DispatchMessage), yet the screen still clears to white. My best guess is that Windows times out, perhaps seeing if I ever call DefaultWindProc with WM_ERASEBKGND and then clears the window if I take too long. This is on NT4.0, incidentally.
2. Yes you can use X pixmaps (and on NT you can use images) to make fake double-buffering. However this still requires a round trip to the app for it to say "the way to repaint is to copy this area". This is nowhere near as good as double-buffering understood by the system, as it is in OS/X and in the newer versions of Windows.
Also it ridiculous that "rpm packagename" (with no switches) does not do anything. I think it should either say "it's installed" or "do you want to install it y/n" or "can't install it because it needs these...". It should do the proper install if you confirm, with -v -H -whateverthehell you need.
I would also like to see "source rpms" that take a long time to install, but they automatically unpack the source, configure, make, install, and remove the source (you can save the source with some switch).
Being closed-source has anything to do with binary compatability. Both open and closed source could be binary compatable or incompatable. You could say that Windows made the right decision and Linux the wrong one, but you seem to be implying that either Linux could not do this because of open source, or that closed source somehow forced Windows to do this. That is wrong.
The first thing to realize is that the "slowness" is not actually slowness but blinking and flashing of intermediate displays before the final one is shown. If when you moved a window it jumped every second to follow the mouse, but jumped exactly and cleanly with all the underlaying windows appearing fully-drawn instantly, it would probably be more preferrable to the way X works now.
The problem is primarily due to the seperate window manager. This guarantees that windows will move and resize at a different time than their contents are redrawn. This is because the window manager moves the window, but then exposure or resize events must be delivered to a different application which then generates the drawing. If the same program could deliver the move and drawing instructions in a single block it would look way smoother. Unlike what a lot of people think, latency is NOT an issue, what is important is that all the instructions come from the same program and can be delivered as one block. This in particular makes resizing terrible on X, window dragging is about equal on X and Windows nowadays.
Another problem was "visuals" which produced annoying color flashing. Fortunately XFree86 has pretty much gotten rid of these on Linux, but if you try an Irix or Sun machine you will see this lovely stupidity in action. This is just BAD design, a proper design would consider the visual part of the "paint" so you don't change a pixel's visual until it is drawn.
Another problem is background clearing, which made sense on older slow machines but produces annoying flashes nowadays, as when you expose an area it is changed twice, first to the background, then to the final display. Windows does not do this (it does do some kind of timeout and clear to white so that dead programs don't end up with garbage in them, but in normal use this does not happen).
Think about it. Also try both systems, and perhaps learn a little.
In bash/tcsh tab-completion, only the matching letters are added. If you type a few extra letters you can backspace the same number of characters, and you are in the same state as before. Also if you hit return you have named a file that does not exist, so the program will either fail (because it can't read it) or it will write it and at least you did not destroy anything because the file did not exist before.
Web browsers try to remove the modal state by "selecting" the addition. This is technically true (if the actual text is used to identify the location in the list, I suspect they really keep a parallel modal index number). However it makes it difficult to name a new object that has more letters on the end, or for command lines to add more words after the first.
I won't get into "Combo Box" completion. It is just too horrific, even the individual letters are modal. Unf**kingbelivable.
It is shameful that MicroSoft and the web browsers did not at least look at how Unix had been solving these problems for a decade. I believe the main reason for the hate for MicroSoft is because so many good ideas have been discarded by their ignorance of what has been done before.
Their unified interface probably contains some data structures to encapsulate the abilities that do not match the data structures made by the card manufacturers. Most likely these data structures are a better design than what the card manufacturers made since they encapsulate the abilities of several cards, and it sounds like this is what MicroSoft is making a patent claim on.
This is really unfortunate as it will force OpenGL to use different structures. This will make it a pain to port programs between OpenGL and DirectX. In any sensible world simple interface ideas would be stolen from either system and put in the other, with no comment whatsoever from the companies. Imagine if read/write/seek interface to files had been patented, this is equivalent.
The lack of drivers, especially for the graphics cards, is really a hurting point for any alternative OS.
I have heard that the division between the driver back-end of XFree86 and the "X" part is getting better and cleaner, which may lead to eventually being able to use XFree86 drivers. But I doubt it is there yet because I don't see it being done now.