You seem to be confused. TWM is a possible window manager but is not required. In fact Gnome/KDE replace it with their own window manager.
It may make sense to question the idea of having a window manager at all. It seems quite possible to implement the windows in the toolkits and reduce the complexity to a "task manager" that only needs to be running if the user wants a list of running tasks. Yea, the window borders will look different depending on the toolkit, but I don't think it will be that bad, and it might lead to designs where there are no window borders.
The problem with X (at least when in 8bpp mode) is that the programs have local storage of a "colormap" where they know "this number produces this color". There was no mechanism in X so that the server could say "throw away your colormap and start over". Even if there was, there would probably be many programs that did not work because they were never tested with such changes (Windows had such a mechnism but it never really worked for exactly this reason).
The real solution is to have "true color" where a program does not keep track of a colormap, but instead asks for a color directly and the server does whatever it wants to get that color (such as allocate it from a colormap).
X supported this but had a serious design flaw: the calls for true color only worked when the screen was in true-color mode. You still had to manage colormaps if it was not in this mode. Since virtually all screens then had colormaps, most programs did not bother with the true color calls, or they made buggy untested versions.
When True Color became practical people quickly discovered that 90% of their programs did not work. Most manufacturers (Sun, for instance) were forced to add hardware to their cards so that some pixels could be in true color while others were in colormap. It wasn't until XFree86 started doing true-color on PC cards that lacked such hardware that programs started to be rewritten so that colormaps were not necessary.
Why did Windows not have this problem? In fact it was due to a good design decision, of the type that the X people seem to seriously lack the ability to make. The "true color" calls worked even when the screen was in colormap mode!. This meant that a program that just wanted a color worked when the screen was set to full color. Only programs that wanted to do funny things to colormaps failed, but on Windows this was only a small percentage of them (mostly games).
Why didn't X do this? It was due to a weird type of stupidity: The Windows version, when asked for a random color, produced a halftone of a fixed colormap, which looked horrible. But there were 64 (16 on early versions) of colors that looked good on all displays because they did not halftone.
The X people probably thought of this design, said "only 64 special colors looks good, while with our design the programmer can choose any set of 64 colors, and we won't implement that less-powerful design, besides they can always emulate it atop our design"
People writing Windows programs, however, said "I can use this complex mess to manage colormaps, or I can use this nice simple call to get a color." They then try it, and say "well, only these 64 colors work." But then they don't say "that sucks, I better learn colormaps". Instead they fix their program to only use the nice colors! And their programs worked right away on True Color because Windows had provided the stupider and simpler interface, and not worried that that interface could not do "everything".
I sincerly hope the X developers will learn something from this about what a good interface is. But from what I am seeing come out of there, I'm afraid it is not happening.
Yay! It is good to see at least one other person who understands what is going on.
In fact in all implementations I have seen, it requires less code to draw the button than to communicate the fact that a button exists. Compare the number of Xlib calls needed to the size of the interface to the button object in either Qt or Motif, the interface to a button is 10 or more times larger!
Sending pixmaps is stupid but fixing it does NOT mean that the server has to understand widgets. It means we need the ability to keep the pixmap on the server (X already does this). And it means we need better graphics "primitives" like Gourand shading, and perhaps the ability to send compressed images straight from files to the server (not as the final image but as pixmaps to build the final image from). This (powerful graphics) is the area that X seriously lacks! But is annoying to see every attempt to solve this getting confused with the completely backwards "put a toolkit in the server" idea.
The idea is that Gdk provides a "draw a raised button-like rectangle here" call. At least I think it does. Thus if Qt used gdk (and it was written in such a way that loading a "theme" replaced the implementation of that low-level call without making assumptions about how Gtk used it or modifying gtk stuff to match, which I actually think is very unlikely) then they could match.
Personally I think the "consistent user interface" is way oversold. I have yet to see a user "confused" because the buttons are different colors. They are confused when the left mouse button does not push the button, but that stupidity was eliminated long ago in X programs and none of these "themes" even attempt to address that anyway.
Nonsense, alternative widget kits were very much in use. This was when to use X you got a commercial distribution and got Motif for "free".
Face it, Motif was absolutely horrible, and people were desperate to replace it.
Examples include xview, tk, Forms and XForms, Glut, early versions of fltk (which I wrote long before Linux was any big deal), and literally dozens of others. None of them used Xt or Motif, and for good reasons. Take a look at any commercial program that was graphic-intensive then (especially for SGI) and less than half of them used Motif.
Not true, in many cases it takes much less code to describe how to draw a button than to describe the fact that you want a button drawn (ie there is a box and label, which is exactly the same amount of information as "a button named this"). Then people say "well I will send the object id only" but in fact in most cases you have made it worse because now the entire object must be sent initially so that the object id will work, and this tends to be an enormous amount of information, 95% of which will never be used, but must be sent in case you do the call that needs this information. This stuff tends to bloat excessively over time, too.
This was a serious problem with NeWS, which I worked on, and basically made it impossible to make a C program talk to the widgets efficiently.
In any case I think "standardized widget set" is seriously misguided. If X had been designed with such a set it would be still using Athena style widgets today and would be laughably primitive.
Cut/Paste is done by the X system, not by the window manager. It's just that the interface blows so all toolkits have to add some nicer interface above it. Thus cut/paste in Qt has a different programming interface than in Gtk. This leads people to believe that the underlying mechanisim is different between KDE and Gnome, in fact it isn't and they actually interoperate quite well (the incompatability would be the same as two Windows programs not agreeing on a filename to store some temporary data in, no amount of design will fix that, one of the two has to change their mind to agree with the other).
It would be nice if Xlib added some easier interface to this stuff so that all the toolkits did not have to do it.
Just to point out redundantly that there really are standards:
Use a single dash for single-letter switches, ie -a, -b, -c. This lets you turn on all three by using -abc.
Use double dashes for descriptive word switches, like --backup, this avoids these being considered -b -a -c -k -u -p.
Many programs only support one switch per dash, which is incompatable with the standard. These usually don't care how many dashes you put in front.
In any case you have got to be kidding if you think Windows is better for consistent command line switches. Certainly there are things there that are more consistent but you managed to choose the worst possible example for Windows! Hint: what and how do you use forward slashes? When do you use an equal sign? What glob expressions are accepted?
Unfortunately nobody has figured out how to do a single menu bar with point-to-type. Point-to-type is an enormous improvement to GUI usability and the only thing stopping it is that nobody defaults to it so it is saddled with the "unintuitive" moniker.
Anyway unless point-to-type is solved there is going to be zero interest from Linux programmers. There will also be zero interest from advanced Windows users (you can set point-to-type with a registry preference).
But it is not unsolvable. Obvious answer is to use a timeout so moving the mouse quickly does not switch applications. More dramatic solutions would be to move the application to the top edge of the window. Work on solutions for this and maybe you will see your menubars someday.
Small nit-pick: the X11 "border" is probably not used by any modern applications. What you are talking about is the border added by the X window manager.
In a window manager I wrote (flwm) I copied the Win32 maximize behavior and moved the resize border off the screen. This worked for what you wanted but so far has been somewhat of a pain for the same reason as Win32: you can't resize the window back down. On win32 this would be the only reliable way of making a maximized-vertical window (my window manager provides a seperate button for it). In any case the main reason I (and Win32) did this was to save screen space, not for this effect of easily pushing the button (this should be obvious because Win32 does not make it so easy to click the max/min buttons). In the end though I would preserve this behavior and put the resize borders off-screen, the main problem I have with flwm is that the user can easily drag a window to this position (it sticks with the resize border outside) and it seems that this should only be done by clicking the maximize buttons.
The fact that Glade (and QtDesigner) output editable C code and not an interpreted "resource" file (as you call it) is considered one of their big advantages. Mostly you know exactly what it can do and you are assurred that any program you write can do the same things.
If you think any user is going to edit the resources you seem to be very confused about what "user friendly" means. There is absolutely no advantage to the end user of an interpreted file over C source. Any user that would want to do that would be MUCH happier with the source code to the program.
There would be no "location" problem with the pop-up menu on the desktop. No matter where you clicked on the desktop you would get the same popup menu, which would be the equivalent of the "start" menu.
I would also put all the "taskbar" onto the popup menu and get rid of that as well. Combining the ability to open a program and an already-opened program would also allow some of the "dock" ideas from NeXT to be reused, ie you don't have to know if you are already running the program.
I would also get rid of all the desktop icons so that any mouse click (not just the right) can pop up the menu.
I have also had great luck with combining Alt+Tab into this popup menu so that it works as expected but can also be used as a keyboard shortcut to navigate the "start" menu.
You can try all this in flwm. Unfortunately it requires manual setup of the items in the popup menu but after that it seems to work very well.
The biggest problem with copying Windows is the lack of point-to-type. This results in all kinds of weird kludges with window ordering and clicks raising windows and dialog boxes that make real overlapping window interfaces impossible and lead to the 1-task-at-a-time design of Windows and OSX. These problems are invading KDE as well and the future for innovation does not look good.
The trick is that *all* the windows (at least the opened ones) need to be there, not just the one being drawn. Also most of that memory is for texture maps and it is possible that the graphics accelerator is not connected to it in a way that can write it (obviously it is connected for read).
I think it is quite possible to do this with hardware support, but I suspect that the hardware designs do not do it yet because it is unnecessary for high Quake frame rates.
Pretty accurate. Only nit-pick is that bezier curves are typically not hardware accelerated, they are decomposed into little straight lines (or triangles or trapazoids for filling) and then those are hardware accelerated. The decomposition into lines is a minor amount of processing compared to the drawing/filling.
A likely culprit is the alpha blending and the off-screen back buffers. The alpha blending is probably not supported by current hardware (since it does not exist on Windows). And full-window offscreen buffers would be similar to Windows Bitmaps (or X Pixmap objects) and those often do not get hardware acceleration because the memory is not connected to the graphics accelerator (this is as opposed to the clipped double-buffer used by OpenGL (and probably DirectX) and by the X Double Buffering Extension) which is usually hardware graphics memory (since the size is fixed and does not have to be larger than the screen).
"Transparent" windows and anti-aliased window edges pretty much require a window-sized buffer and until graphics cards are redesigened to render to main memory I don't think they will be fast.
Yes but I would still like a lower level so that implementing fltk was a relatively trivial operation.
Right now writing fltk is like writing a text editor where the only interface to the disk is the disk blocks, I would spend a lot more time figuring out the file system and trying to correctly cooperate with other programs, than writing useful things into the text editor.
Excellent point that the API should be a data protocol or otherwise simplified.
GUI api design today seems to me to be equivalent to the interfaces to file systems in the 1960's. At that time you had to know exactly what device and structure of the file you were going to use, you had to use a completely different set of calls for each file, and "pip" (the equivalent of "cp") was far larger than any other application on the system. In modern GUI interfaces you have windows, menus, buttons, canvases, etc, and printers, all with vastly different interfaces (MicroSoft's GDI is not quite a solution although I certainly admit it is better than the situation on Unix), and COM and Corba, etc, are the equivalent of PIP and enormously complicated.
In 1970 the Multics/Unix people came up with the open/read/write/seek interface to files. I'm sure then there was huge gnashing of teeth and complaints that people would write all kinds of inefficient databases and there would be "inconsistent interfaces" that would "confuse users" and all the other attacks that are levied against any attempt to simplify the GUI today. Well it turns out they were wrong, the simple interface works and resulted in more powerful databases than anybody ever imagined, and that interface designed in 1970 can be used today on huge arrays of networked computers and on disks the size of which was unimaginable then.
We need the same thing in GUI today. I don't know if there is much hope as it requires a powerful force to implement it. MicroSoft could, but ActiveX is the exact opposite, it is enormously complex and basically requires all of Windows to be implemented (there would be little complaint if in fact a slow emulator like Mesa could be written for ActiveX, but the design makes it impossible). Everything else I see is an attempt to make "toolkits" be part of the OS (ie Berlin and Qt Embedded and Atheos) and I think is going to make things worse. I don't know if it is possible for a solution to appear today.
The answer is *both* are bad. And both can be good (just wait until MicroSoft accidentally does something good if you want to post such wit here on SlashDot). They are huge organizations of people who are not necessarily smart enough to figure out how to maximize their own evil, so they will do all kinds of random things.
I think the estimate would be in a couple millions. However you are correct in the relative scale, I think you are underestimating the sales of Windows machines by about the same factor.
If Lindows simply concatenates a lot of OSS programs together with proprietary programs and sells them for a lot of money, they can continue to point at other sources of the source code. It does not matter if it is "commercially distributed" or not. (actually there may be some kind of requirement that they host the source code, but my personal feeling is that this is too much of a hiderance for people simply repackaging things and discourages people from getting the newest version of the source code because the companies copy may not get updated).
Conversely if Lindows has modified some GPL or LGPL source code, they are obligated to provide their changed versions somehow. Again it does not matter if it is "commercial" or not.
It seems they do not have to put it on a web site, they can use any method they want to distribute the source code. In fact they can limit the ability to download it to people who have bought the disk, even using some proprietary decoding program and key on the disk to force it (though there really is no reason for that). What they can't do is prevent people who download the code from doing anything they want with it, like give the code to somebody else. However this is not anywhere near as bad as some people believe, the real result is that things will inter-operate better with Lindows, and the code will eventually be folded back into the official Wine, and they don't have to worry about Wine's improvements being incompatable with their own improvements. I really doubt it will hurt Lindows sales at all.
Give them a week or so. But really they should dump their source code on a site. The "beta" loophole is way, way too big and must be disallowed.
No you are confusing the toolkit with the underlying library.
Windows originally "pushed" all events to the WndProc function that was registered with each window. They very quickly (before Windows 3) added the "GetMessage" and "DispatchMessage" calls that allowed a "sort-of" pull environment. The problem was that virtually any call to the system could cause WndProc to be called, requiring applications to make sure everything was in a consistent state and ready for any possible user event before every system call. This is practically impossible.
Xlib has a call almost exactly like GetMessage except with the added insurance that every event goes through it (Windows still sends map/unmap events directly to WndProc, which has bitten me many many times). Your program is in an inconsistent state? Simple: don't call XGetNextEvent. Not so simple on Windows.
The big case statement you talk about is virtually identical in Windows and Xlib. In Windows you have to put it in the WndProc callback, in Xlib you put it right after you get an event.
Building a "push" system (like all toolkits including fltk and Qt) is pretty easy on top of a "pull" system. This is why the toolkits work on both X and Win32.
The other way around, building a "pull" system atop a "push" one, *could* be done if the event callback put the events in a queue. But there are problems doing this on Windows with some events, as Windows seems very unhappy if you don't do the expected actions in response to events. The big one is WM_PAINT events, I really want to save these so that updates due to window exposures and updates due to user interaction can be done together, potentially saving half the redrawing. Unfortunately this has proved to be impossible, so I have to treat the PAINT events as a push system (though I draw user interface updates at that time so in most cases it is not less efficient).
I think it would also be very difficult to build a different "push" system atop another "push" system. This is why toolkits atop toolkits (like WxWindows) are really flaky. Fortunately fltk (and probably others) do not need to push any events (like PAINT) that Windows handles strangely. I do push the map/unmap events and it certainly makes bugs show up in fltk code developed on X.
Only a specific implementation of the TCP/IP stack is covered by the GPL.
Other implementations are not. For instance the BSD implementation, which in fact the GPL implementation is a copy of (at least parts of it). If what you were saying is true, the mere existence of Linux would mean that BSD (and Windows) instantly changed to the GPL. Obviously not true.
Patents can do scary things like this, which is why everybody here hates them. The GPL is nothing different than any NDA or other agreement that MicroSoft cooks up and is usually considered harmless.
If you want to sell your software, DON'T USE THE F**KING GPL! It's not that hard, it just requires you to write your own code, or (shudder) buy it (you may find some GPL authors would be happy to sell you a closed license).
The GPL DOES NOT MEAN YOUR CODE HAS TO BE FREE. It means YOU CANNOT USE THE GPL CODE. There is lots of code you cannot use. Deal with it.
Many schools have MicroSoft's source code. But they are not allowed to use it in commercial products due to the NDA. Why aren't you complaining about this. IT IS THE SAME THING
Write your own code and stop being such an asshole.
Slashdot Mirror
It may make sense to question the idea of having a window manager at all. It seems quite possible to implement the windows in the toolkits and reduce the complexity to a "task manager" that only needs to be running if the user wants a list of running tasks. Yea, the window borders will look different depending on the toolkit, but I don't think it will be that bad, and it might lead to designs where there are no window borders.
The real solution is to have "true color" where a program does not keep track of a colormap, but instead asks for a color directly and the server does whatever it wants to get that color (such as allocate it from a colormap).
X supported this but had a serious design flaw: the calls for true color only worked when the screen was in true-color mode. You still had to manage colormaps if it was not in this mode. Since virtually all screens then had colormaps, most programs did not bother with the true color calls, or they made buggy untested versions.
When True Color became practical people quickly discovered that 90% of their programs did not work. Most manufacturers (Sun, for instance) were forced to add hardware to their cards so that some pixels could be in true color while others were in colormap. It wasn't until XFree86 started doing true-color on PC cards that lacked such hardware that programs started to be rewritten so that colormaps were not necessary.
Why did Windows not have this problem? In fact it was due to a good design decision, of the type that the X people seem to seriously lack the ability to make. The "true color" calls worked even when the screen was in colormap mode!. This meant that a program that just wanted a color worked when the screen was set to full color. Only programs that wanted to do funny things to colormaps failed, but on Windows this was only a small percentage of them (mostly games).
Why didn't X do this? It was due to a weird type of stupidity: The Windows version, when asked for a random color, produced a halftone of a fixed colormap, which looked horrible. But there were 64 (16 on early versions) of colors that looked good on all displays because they did not halftone.
The X people probably thought of this design, said "only 64 special colors looks good, while with our design the programmer can choose any set of 64 colors, and we won't implement that less-powerful design, besides they can always emulate it atop our design"
People writing Windows programs, however, said "I can use this complex mess to manage colormaps, or I can use this nice simple call to get a color." They then try it, and say "well, only these 64 colors work." But then they don't say "that sucks, I better learn colormaps". Instead they fix their program to only use the nice colors! And their programs worked right away on True Color because Windows had provided the stupider and simpler interface, and not worried that that interface could not do "everything".
I sincerly hope the X developers will learn something from this about what a good interface is. But from what I am seeing come out of there, I'm afraid it is not happening.
In fact in all implementations I have seen, it requires less code to draw the button than to communicate the fact that a button exists. Compare the number of Xlib calls needed to the size of the interface to the button object in either Qt or Motif, the interface to a button is 10 or more times larger!
Sending pixmaps is stupid but fixing it does NOT mean that the server has to understand widgets. It means we need the ability to keep the pixmap on the server (X already does this). And it means we need better graphics "primitives" like Gourand shading, and perhaps the ability to send compressed images straight from files to the server (not as the final image but as pixmaps to build the final image from). This (powerful graphics) is the area that X seriously lacks! But is annoying to see every attempt to solve this getting confused with the completely backwards "put a toolkit in the server" idea.
Personally I think the "consistent user interface" is way oversold. I have yet to see a user "confused" because the buttons are different colors. They are confused when the left mouse button does not push the button, but that stupidity was eliminated long ago in X programs and none of these "themes" even attempt to address that anyway.
Face it, Motif was absolutely horrible, and people were desperate to replace it.
Examples include xview, tk, Forms and XForms, Glut, early versions of fltk (which I wrote long before Linux was any big deal), and literally dozens of others. None of them used Xt or Motif, and for good reasons. Take a look at any commercial program that was graphic-intensive then (especially for SGI) and less than half of them used Motif.
This was a serious problem with NeWS, which I worked on, and basically made it impossible to make a C program talk to the widgets efficiently.
In any case I think "standardized widget set" is seriously misguided. If X had been designed with such a set it would be still using Athena style widgets today and would be laughably primitive.
It would be nice if Xlib added some easier interface to this stuff so that all the toolkits did not have to do it.
Use a single dash for single-letter switches, ie -a, -b, -c. This lets you turn on all three by using -abc.
Use double dashes for descriptive word switches, like --backup, this avoids these being considered -b -a -c -k -u -p.
Many programs only support one switch per dash, which is incompatable with the standard. These usually don't care how many dashes you put in front.
In any case you have got to be kidding if you think Windows is better for consistent command line switches. Certainly there are things there that are more consistent but you managed to choose the worst possible example for Windows! Hint: what and how do you use forward slashes? When do you use an equal sign? What glob expressions are accepted?
Okay, don't come crying to me when you get to be a good enough programmer that you might (horrors) want to *generate* a dialog box from your code.
Anyway unless point-to-type is solved there is going to be zero interest from Linux programmers. There will also be zero interest from advanced Windows users (you can set point-to-type with a registry preference).
But it is not unsolvable. Obvious answer is to use a timeout so moving the mouse quickly does not switch applications. More dramatic solutions would be to move the application to the top edge of the window. Work on solutions for this and maybe you will see your menubars someday.
In a window manager I wrote (flwm) I copied the Win32 maximize behavior and moved the resize border off the screen. This worked for what you wanted but so far has been somewhat of a pain for the same reason as Win32: you can't resize the window back down. On win32 this would be the only reliable way of making a maximized-vertical window (my window manager provides a seperate button for it). In any case the main reason I (and Win32) did this was to save screen space, not for this effect of easily pushing the button (this should be obvious because Win32 does not make it so easy to click the max/min buttons). In the end though I would preserve this behavior and put the resize borders off-screen, the main problem I have with flwm is that the user can easily drag a window to this position (it sticks with the resize border outside) and it seems that this should only be done by clicking the maximize buttons.
If you think any user is going to edit the resources you seem to be very confused about what "user friendly" means. There is absolutely no advantage to the end user of an interpreted file over C source. Any user that would want to do that would be MUCH happier with the source code to the program.
I would also put all the "taskbar" onto the popup menu and get rid of that as well. Combining the ability to open a program and an already-opened program would also allow some of the "dock" ideas from NeXT to be reused, ie you don't have to know if you are already running the program.
I would also get rid of all the desktop icons so that any mouse click (not just the right) can pop up the menu.
I have also had great luck with combining Alt+Tab into this popup menu so that it works as expected but can also be used as a keyboard shortcut to navigate the "start" menu.
You can try all this in flwm. Unfortunately it requires manual setup of the items in the popup menu but after that it seems to work very well.
The biggest problem with copying Windows is the lack of point-to-type. This results in all kinds of weird kludges with window ordering and clicks raising windows and dialog boxes that make real overlapping window interfaces impossible and lead to the 1-task-at-a-time design of Windows and OSX. These problems are invading KDE as well and the future for innovation does not look good.
I think it is quite possible to do this with hardware support, but I suspect that the hardware designs do not do it yet because it is unnecessary for high Quake frame rates.
A likely culprit is the alpha blending and the off-screen back buffers. The alpha blending is probably not supported by current hardware (since it does not exist on Windows). And full-window offscreen buffers would be similar to Windows Bitmaps (or X Pixmap objects) and those often do not get hardware acceleration because the memory is not connected to the graphics accelerator (this is as opposed to the clipped double-buffer used by OpenGL (and probably DirectX) and by the X Double Buffering Extension) which is usually hardware graphics memory (since the size is fixed and does not have to be larger than the screen).
"Transparent" windows and anti-aliased window edges pretty much require a window-sized buffer and until graphics cards are redesigened to render to main memory I don't think they will be fast.
Comon, none of this requires legislation!
Right now writing fltk is like writing a text editor where the only interface to the disk is the disk blocks, I would spend a lot more time figuring out the file system and trying to correctly cooperate with other programs, than writing useful things into the text editor.
GUI api design today seems to me to be equivalent to the interfaces to file systems in the 1960's. At that time you had to know exactly what device and structure of the file you were going to use, you had to use a completely different set of calls for each file, and "pip" (the equivalent of "cp") was far larger than any other application on the system. In modern GUI interfaces you have windows, menus, buttons, canvases, etc, and printers, all with vastly different interfaces (MicroSoft's GDI is not quite a solution although I certainly admit it is better than the situation on Unix), and COM and Corba, etc, are the equivalent of PIP and enormously complicated.
In 1970 the Multics/Unix people came up with the open/read/write/seek interface to files. I'm sure then there was huge gnashing of teeth and complaints that people would write all kinds of inefficient databases and there would be "inconsistent interfaces" that would "confuse users" and all the other attacks that are levied against any attempt to simplify the GUI today. Well it turns out they were wrong, the simple interface works and resulted in more powerful databases than anybody ever imagined, and that interface designed in 1970 can be used today on huge arrays of networked computers and on disks the size of which was unimaginable then.
We need the same thing in GUI today. I don't know if there is much hope as it requires a powerful force to implement it. MicroSoft could, but ActiveX is the exact opposite, it is enormously complex and basically requires all of Windows to be implemented (there would be little complaint if in fact a slow emulator like Mesa could be written for ActiveX, but the design makes it impossible). Everything else I see is an attempt to make "toolkits" be part of the OS (ie Berlin and Qt Embedded and Atheos) and I think is going to make things worse. I don't know if it is possible for a solution to appear today.
If the molecules "clump" this is equivalent to there being fewer molecules, so in fact the dilution is even less likely to have any chemical in it.
The answer is *both* are bad. And both can be good (just wait until MicroSoft accidentally does something good if you want to post such wit here on SlashDot). They are huge organizations of people who are not necessarily smart enough to figure out how to maximize their own evil, so they will do all kinds of random things.
I think the estimate would be in a couple millions. However you are correct in the relative scale, I think you are underestimating the sales of Windows machines by about the same factor.
If Lindows simply concatenates a lot of OSS programs together with proprietary programs and sells them for a lot of money, they can continue to point at other sources of the source code. It does not matter if it is "commercially distributed" or not. (actually there may be some kind of requirement that they host the source code, but my personal feeling is that this is too much of a hiderance for people simply repackaging things and discourages people from getting the newest version of the source code because the companies copy may not get updated).
Conversely if Lindows has modified some GPL or LGPL source code, they are obligated to provide their changed versions somehow. Again it does not matter if it is "commercial" or not.
It seems they do not have to put it on a web site, they can use any method they want to distribute the source code. In fact they can limit the ability to download it to people who have bought the disk, even using some proprietary decoding program and key on the disk to force it (though there really is no reason for that). What they can't do is prevent people who download the code from doing anything they want with it, like give the code to somebody else. However this is not anywhere near as bad as some people believe, the real result is that things will inter-operate better with Lindows, and the code will eventually be folded back into the official Wine, and they don't have to worry about Wine's improvements being incompatable with their own improvements. I really doubt it will hurt Lindows sales at all.
Give them a week or so. But really they should dump their source code on a site. The "beta" loophole is way, way too big and must be disallowed.
Windows originally "pushed" all events to the WndProc function that was registered with each window. They very quickly (before Windows 3) added the "GetMessage" and "DispatchMessage" calls that allowed a "sort-of" pull environment. The problem was that virtually any call to the system could cause WndProc to be called, requiring applications to make sure everything was in a consistent state and ready for any possible user event before every system call. This is practically impossible.
Xlib has a call almost exactly like GetMessage except with the added insurance that every event goes through it (Windows still sends map/unmap events directly to WndProc, which has bitten me many many times). Your program is in an inconsistent state? Simple: don't call XGetNextEvent. Not so simple on Windows.
The big case statement you talk about is virtually identical in Windows and Xlib. In Windows you have to put it in the WndProc callback, in Xlib you put it right after you get an event.
Building a "push" system (like all toolkits including fltk and Qt) is pretty easy on top of a "pull" system. This is why the toolkits work on both X and Win32.
The other way around, building a "pull" system atop a "push" one, *could* be done if the event callback put the events in a queue. But there are problems doing this on Windows with some events, as Windows seems very unhappy if you don't do the expected actions in response to events. The big one is WM_PAINT events, I really want to save these so that updates due to window exposures and updates due to user interaction can be done together, potentially saving half the redrawing. Unfortunately this has proved to be impossible, so I have to treat the PAINT events as a push system (though I draw user interface updates at that time so in most cases it is not less efficient).
I think it would also be very difficult to build a different "push" system atop another "push" system. This is why toolkits atop toolkits (like WxWindows) are really flaky. Fortunately fltk (and probably others) do not need to push any events (like PAINT) that Windows handles strangely. I do push the map/unmap events and it certainly makes bugs show up in fltk code developed on X.
Only a specific implementation of the TCP/IP stack is covered by the GPL.
Other implementations are not. For instance the BSD implementation, which in fact the GPL implementation is a copy of (at least parts of it). If what you were saying is true, the mere existence of Linux would mean that BSD (and Windows) instantly changed to the GPL. Obviously not true.
Patents can do scary things like this, which is why everybody here hates them. The GPL is nothing different than any NDA or other agreement that MicroSoft cooks up and is usually considered harmless.
If you want to sell your software, DON'T USE THE F**KING GPL! It's not that hard, it just requires you to write your own code, or (shudder) buy it (you may find some GPL authors would be happy to sell you a closed license).
The GPL DOES NOT MEAN YOUR CODE HAS TO BE FREE. It means YOU CANNOT USE THE GPL CODE. There is lots of code you cannot use. Deal with it.
Many schools have MicroSoft's source code. But they are not allowed to use it in commercial products due to the NDA. Why aren't you complaining about this. IT IS THE SAME THING
Write your own code and stop being such an asshole.