The "30 year old technology" argument is bullshit, as Windows is from the CP/M line which is from the older Dec systems like RSX-11M and older RT11. Unix in fact was the first system to reject some of the older systems baggage. The obvious examples are:
Unix got rid of the need for two characters (^M^J) to seperate lines, replacing them with the single ^J. The two characters were legacy from older mechanical tty's that did not have enough power to return the carraige and rotate the platen at once (there was no synchronization timing then, so each action had to take place in the same time as a single character, so slowing down the newline character was not possible). There is no other reason for seperate ^M and ^J, believe me when communication was 110 baud they would have dearly loved to have removed the need to send this extra character every line.
The other example is the highly simplified file nameing scheme, where only two characters (slash and null) have meaning, and where the hardware layout may be hidden (at that time only by mount points, though symbolic links were added later and are probably more useful). Before Unix, it was very common for "device:" to be at the start of a filename, and many specific characters (square brackets, period, and commas come to mind) had to be at specific places in filenames.
In 1969 these things, and many others, were rejected by the designers of Unix, as being legacy that made programming complex and hard. By far this is the primary reason Unix was the platform almost every significant computer software was written on.
Before anybody does that "old technology" bit I recommend you check which OS has multi-character line terminators and has drive letters...
There is a point. The IBM PC did abandon a good deal of device independence that already existed in CP/M, by botching the character screen device so that there were no escape sequences. This made stream-based I/O useless for updating the display, and caused PC software, up to the present day, to go down the route of giant shared libraries, rather than services communicating by message streams. I think that we actually lost pretty bad here!
Yes, some CP/M machines lacked escape sequences as well, but none of them had any serious market share. Unix relied on escape sequences, and they were finnally standardized on the VT220, though some horrible cruft from the non-matching escape sequeces still lives on in stuff like termcap. But that horror is nothing compared to trying to make programs portable when there are *no* escape sequences.
Although some hack to run a Linux binary on Windows would be interesting, it hardly is useful, as all the good Linux programs have the source and can be compiled on NT, perhaps with the help of some compatability libraries like Cygwin.
Such libraries like Cygwin are the "Wine-like tool for using Linux apps under Windows".
There are examples of programs that are better on Linux: command line programs like the GNU utilities and shells (where I work we could not live without the port of tcsh to NT). Terminal emulators are WAY better on Linux than the built-in one on NT. In graphics only small hack programs are better on Linux, gdiff and network monitoring programs are good examples.
Certainly most of the good stuff has been ported to NT. The only big missing thing is good terminal emulators, but there may be issues with how NT does it's stdio that make this impossible? With the death of Motif I would expect any useful graphics hack on Linux to use a modern toolkit or just Xlib and be portable.
The other killer app is window managers, but not because of that crufty huge "themes". I would very much like to see Windoze fixed so that it does not raise windows when you click on their contents, so that working with overlapping windows was possible. This may be better considered a fix in Windows, besides Linux seems to be going down the same bad road by forcing us to use the KDE or similar window managers, which have the same bugs Windows does...
Why not "extend" it some? Probably it will happen by accident (in fact most of MicroSoft's "extend" behavior is by accident and not a willful malicious act).
If Wine DirectX did something useful with some argument values that did not do the right thing on Windows, it is likely that game writers might even #ifdef LINUX these calls in and improve the game on Linux, and also be a big embarrassment to MicroSoft, who would eventually be forced to copy the Wine-invented interface.
This is what I was saying. X is designed to by asynchronous.
However, besided bad drivers, there are numerous mistakes in the Xlib interface so that many of the "asynchornous" calls are always followed by a wait for a response from the server. For instance the call to register an Atom requires the server to check to see if it is registered, allocate a new number, and return it. Xlib must block until this value is returned, because the Xlib interface is a function that returns the atom.
There is very little that can be done about this because it is almost impossible to add extenstions or change the design of the X server. I think it would be faster to use string tokens than to use the bi-directional atom mechanism. Or you could give each process it's own Atom space, with translations done by the server to messages between processes (this requires the location of Atoms in each message to be identified, which is nearly impossible).
It does appear that Windoze has learned to batch requests as well, they added a GdiFlush() call. They probably also call this when you do GetMessage and some other system calls.
I think you will find that Mozart did not have any copyright protection!
He was paid quite well to write new items. His music was in the public domain after the first performance and was performed by many cut-rate houses without his consent.
Re:A wicked thought...Open Source Censorware
on
Kid Clicks For Sale
·
· Score: 2
Open source censorware is an excellent idea.
The lists of blocked sites would be in an open format. This does not mean that they could not be politically motivated, there would be nothing wrong with the Christian Coalition making their own blocking list, anybody that wants to can use it, but it is also quite clear what it is blocking.
I would hope that users of this software would be free to download blocking lists from anybody they wanted to, and to merge and intersect lists. Or even to subtract lists, thus lists of "sites that should not be blocked" would work.
OSS programmers are much more adapt at programming complex and powerful pattern matching rules than any of the commercial houses (apparently because this is the type of software that very much benifits from the many-eyes complex). They may have the capability to produce a system that works.
Because the lists can be reversed, people searching for pr0n might find them useful, and this may encourage pr0n providers to match the results more carefully, actually improving the censorware!
X has problems (and so does Windows) but your description is a common misconception.
Context switches are a problem. But the difference is not that X has 2 (client->kernel->server) and Windows has 1 (client->kernel).
The problem is "synchronous" interfaces, where you make a call and that call, besides doing something to the screen, returns a value. This actually requires 4 context switches on X and 2 on NT according to your design.
What is needed is non-synchronous or stream-based interfaces. In this case all the things you want to draw on the screen go into a buffer and are eventually flushed. This has the potential of making the number of context switches per operation.001 (note the decimal point) or smaller!
With such a design the overhead of not putting the server in the kernel is miniscule, and you get all the advantages of making it user level.
The problem is that both are designed with large numbers of synchronous interfaces. Windoze has an excuse in that it is based on W3.1 where everything was synchronous, but X was designed as a server, and they really had no excuse for doing stupid things like requiring a round trip to allocate a color or to set the current font.
I do hope that X will be replaced someday, like soon, but we should design it right. Hacks with memory mapping and direct rendering and kernel modules are nice, but none of them come close to the win you will get with an interface that is designed to be piped. The problem is that any such interface is going to incompatable, it is impossible to emulate a synchronous interface atop an async one.
Actually it can be thread safe. There are things called "per thread globals". It is unfortunate that C compilers do not support these in a clean way so that the implementation can be messy and require a function call instead of just a static variable.
A lot of serialized interfaces become much easier to program if a global state is preserved. It can also be much faster in many cases as no checks are needed to see what is different between the new and previous arugments.
I also think this is vital to get the drawing code away from the toolkits. OpenGL has this and we people writing Qt, GTK, Windows MFC, and other programs can cut & paste there OpenGL code between them!
Xlib and Win32 GDI do not do this, and nobody bothers bothers emulating one of these on the other, despite the portability advantages. This is because the application has to retrieve the static information (the "gc") from the toolkit library, binding your code to the toolkit, and making portability between the toolkits impossible.
Oh come on! It is well known here that Scott McNealy would be as bad, and probably far worse, than Bill Gates if he had managed to get into his position (and they tried, they tried so hard they scared all the other Unix companies into forming OSF, and spending all their energies fighting Sun rather than coming up with real new stuff, hmm kind of similar to what everybody is doing now).
Beloved Sun, indeed. You obviously don't read the text here. Even Linux zealots are mad that Sun seems to be spurning them! You don't even seem to be reading the extremest attitudes here!
Face it, it does not matter what you want. 99% of the web designers out there and the users out there want precise pixel-layout of their images. If the designers of html would have just supported this from the start we would not be in this mess. The arrogant belief that we are transmitting anything other than images has caused the incredibly complex and slow document structure model and the fact that the slightest difference between the browsers causes pages to look bad.
Yes, flowing text is nice. But html should have had a "draw in x,y,w,h" command to give the rectangle to format the text into. Perhaps x,y,w,h could be given in percentages of the window size or relative to the bottom of the last rectangle, as well as in pixels. But that and a "fill x,y,w,h" rectangle call would have gotten rid of the need to use tables and CSS and frames and all the other messiness, and probably would have been supported perfectly in Netscape 1.0 and in every other browser in the world (Lynx could even round to the nearest character cell).
You get over it. The arrogant designers of HTML are the ones who should have gotten a clue and realized that 99% of the users want WYSIWYG precise control over the appearance of the page, and they will kludge HTML to be this no matter how much you insist it is "not designed to do that".
If html had simply had a "go to pixel x,y" command we would not be in this horrible mess of incompatable browsers and we would have quick-rendering pages without huge messes of nested tables. I'm sorry, but this attitude is entirely responsible for the hell we are in now.
I think that is a good approach. There is no reason to cough up money for POSIX compliance. Fact is, MicroSoft came up with the money, and their system is totally useless for Posix programs, while Linux did not and Posix programs work great on it.
I also don't think strict compliance is very important. I would be happy if I could rely on a command-line program (no X) that does no ioctl calls was the only thing guaranteed to work (and it can read any file, so NT does not conform to this). For instance they can go ahead and break that incredible mess that is pseudo-ttys and the terminal driver.
NT DOES NOT conform to the POSIX standard in any useful way. For instance, a file created by a POSIX program is not visible to a normal NT program, and vice-versa. This makes it totally useless. They also did a very minimal support of POSIX, so minimal that no real program can port to it. It was simply so it could be checked off on government requirement lists, but purposely broken enough that nobody would write portable programs for NT.
Not only that, I certainly expect an xlib emulator (or X server emulator) that allows X clients to run in an Aqua window. The only X programs that wont run are window managers, and perhaps some things that try to draw on the desktop.
This will allow any X program to run on the Mac (and will probably allow remote X applications to appear in windows on the Aqua screen, too).
Even with this, I would expect ported toolkits to produce faster and more reliable code.
If I left a piece of paper with the password for my NT box in the front lawn, I would not announce it either, dummy.
A much better example is that I bought my house lock from Acme and Acme keeps private how the innards works, not revealing the fact they just figured out that all hairpins in the world work just fine if bent in a certain way.
The problem with these arguments is that there are 102 keys on the keyboard, and nobody seems to be saying it would be better to have only one key.
If the original mice had printed something (like "menu" or "right" or anything) on the buttons, I don't think there would be any argument today and there would be multi-button mice.
They are entirely concerned about analog copies, or any kind of copy. Unless they are idiots, they know that people will put up with extreme levels of degradation to get things for free. The small minority who are concerned about quality will already pay extra for "original" disks, even digital ones, if they come with nice cover art or other non-digital add ons.
Even bad copies will stop their real intention,
to force people into a system where they pay per view, always. They also don't want to allow you to fast-forward through commercials.
They will not stop until the signal is piped directly into a chip implanted in your brain, and modifications are made so you are incapable of describing the signal to another person.
Imagine even the simplest display, some black text on a white background. In your case the server automatically clears exposed areas to white.
Take a sample pixel that lies inside a black letter. It will initially have the old window's contents. When exposed the server changes it to white. When drawn the server changes it to black. That is 2 transitions.
Now imagine the program is super-efficient at drawing (or that it copies the data from a backing store, as you suggest), so that it only draws each pixel once. Then initially that pixel will have the old window's contents. When drawn it will turn black. This is 1 transition, the minimum possible.
Now you can argue that nobody draws their data like that, and any reasonable program will result in 2 blinks anyway, but the fact remains that if the server clears it, it is impossible to avoid the 2 blinks.
I also argue that simple application will erase the background even if the server did. This will result in 3 writes to the pixel, even if two of them are the same white color. This is not cheap, 1000 pixels does take some machine time and it is worth it to save one pass.
Also, even if the program blinks I think it is less objectionable since it will draw the two images right next to each other in time. If the server erases it there could be a quite long time where the display is showing the cleared area, making the blink much more visible.
Backing store like the NeXT had is nice (and it can be faked on X by mapping a single large pixmap as the background for the window). In fact I believe it is the only solution that allows the server to decide what to do with exposed area. But unfortunately most modern hardware does not allow hardware accelerated graphics to be used there, defeating most of the advantages.
I think the *actual* drag & drop requires this move behavior, because the user "cancels" the drag by releasing when the mouse points at the selected region. Only move would result in the desired no-op behavior in this case, and from my work on Drag&Drop I have found this more reliable and consistent to program than a "detect if the user is still pointing at the selection" type of cancel behavior.
Because middle-mouse click allows the user to cancel by not doing the paste at all, this move behavior is not necessary. I actually think a copy behavior would be more useful and consistent (since that is what is done between programs). Middle-mouse also allows the user to select, delete, and then paste, allowing drag&drop to do either a copy or a move by the user's choice.
As you point out, there are big problems with the same buffer being used for middle-mouse drag&drop and cut/paste, as selecting something wipes out the users cut, since in middle-mouse terms the user has just started a drag. In Windows drag&drop this is not a problem because click that starts a drag is not needed to edit text otherwise, and I suspect Windows users would never notice if drag & drop replaced the clipboard contents.
Unfortunately through historical failure to notice that middle-mouse click is different from cut/paste, we are probably stuck on X with the same buffer used for both.
BUT, I do think a single buffer could be used, if it was not changed when a selection is done (or the drag is started), but rather when the focus exits the buffer, (or even better it should change at the moment the middle-mouse/"drop" is done but this cannot be done on either Windows or X). I am working on implementing this behavior in fltk right now.
Try thinking a little. That is exactly what I am saying, you dummy!
"Middle mouse button paste" (and the automatic selection->copy) of X is exactly the same as Drag and Drop! EXACTLY!
Therefore, a proper implementation would merge this behavior with any drag and drop behavior and use the same buffer. While a seperate buffer should be used for the ^X^V cut/paste operations.
Unfortunately there are a lot of X programs (my own stuff included) that use the same buffer for the middle mouse click and for the ^X^C. This is what my original message was about, and it is a problem. However too many people seem to think the middle-mouse stuff is cut/paste and should be seperate from drag & drop, when in fact they are identical and the original X behavior, while cut & paste is the "new" stuff for X. Unfortunately event the drag & drop standards for X have fallen into this so that the only compatable thing to do is have THREE buffers (selection, "clipboard", and "drag and drop"). Very few programs use the SELECTION buffer as well (many of them consider it more drag & drop than the clipboard, too), forcing the same buffer to be used if you want ^X^C to work between programs.
Slashdot Mirror
Unix got rid of the need for two characters (^M^J) to seperate lines, replacing them with the single ^J. The two characters were legacy from older mechanical tty's that did not have enough power to return the carraige and rotate the platen at once (there was no synchronization timing then, so each action had to take place in the same time as a single character, so slowing down the newline character was not possible). There is no other reason for seperate ^M and ^J, believe me when communication was 110 baud they would have dearly loved to have removed the need to send this extra character every line.
The other example is the highly simplified file nameing scheme, where only two characters (slash and null) have meaning, and where the hardware layout may be hidden (at that time only by mount points, though symbolic links were added later and are probably more useful). Before Unix, it was very common for "device:" to be at the start of a filename, and many specific characters (square brackets, period, and commas come to mind) had to be at specific places in filenames.
In 1969 these things, and many others, were rejected by the designers of Unix, as being legacy that made programming complex and hard. By far this is the primary reason Unix was the platform almost every significant computer software was written on.
Before anybody does that "old technology" bit I recommend you check which OS has multi-character line terminators and has drive letters...
Yes, some CP/M machines lacked escape sequences as well, but none of them had any serious market share. Unix relied on escape sequences, and they were finnally standardized on the VT220, though some horrible cruft from the non-matching escape sequeces still lives on in stuff like termcap. But that horror is nothing compared to trying to make programs portable when there are *no* escape sequences.
Doesn't the newer versions of bash do this?
Although some hack to run a Linux binary on Windows would be interesting, it hardly is useful, as all the good Linux programs have the source and can be compiled on NT, perhaps with the help of some compatability libraries like Cygwin.
Such libraries like Cygwin are the "Wine-like tool for using Linux apps under Windows".
There are examples of programs that are better on Linux: command line programs like the GNU utilities and shells (where I work we could not live without the port of tcsh to NT). Terminal emulators are WAY better on Linux than the built-in one on NT. In graphics only small hack programs are better on Linux, gdiff and network monitoring programs are good examples.
Certainly most of the good stuff has been ported to NT. The only big missing thing is good terminal emulators, but there may be issues with how NT does it's stdio that make this impossible? With the death of Motif I would expect any useful graphics hack on Linux to use a modern toolkit or just Xlib and be portable.
The other killer app is window managers, but not because of that crufty huge "themes". I would very much like to see Windoze fixed so that it does not raise windows when you click on their contents, so that working with overlapping windows was possible. This may be better considered a fix in Windows, besides Linux seems to be going down the same bad road by forcing us to use the KDE or similar window managers, which have the same bugs Windows does...
If Wine DirectX did something useful with some argument values that did not do the right thing on Windows, it is likely that game writers might even #ifdef LINUX these calls in and improve the game on Linux, and also be a big embarrassment to MicroSoft, who would eventually be forced to copy the Wine-invented interface.
Obviously MicroSoft then adjusted the expected level of intelligence of their users and changed the game to a more appropriate one.
However, besided bad drivers, there are numerous mistakes in the Xlib interface so that many of the "asynchornous" calls are always followed by a wait for a response from the server. For instance the call to register an Atom requires the server to check to see if it is registered, allocate a new number, and return it. Xlib must block until this value is returned, because the Xlib interface is a function that returns the atom.
There is very little that can be done about this because it is almost impossible to add extenstions or change the design of the X server. I think it would be faster to use string tokens than to use the bi-directional atom mechanism. Or you could give each process it's own Atom space, with translations done by the server to messages between processes (this requires the location of Atoms in each message to be identified, which is nearly impossible). It does appear that Windoze has learned to batch requests as well, they added a GdiFlush() call. They probably also call this when you do GetMessage and some other system calls.
He was paid quite well to write new items. His music was in the public domain after the first performance and was performed by many cut-rate houses without his consent.
The lists of blocked sites would be in an open format. This does not mean that they could not be politically motivated, there would be nothing wrong with the Christian Coalition making their own blocking list, anybody that wants to can use it, but it is also quite clear what it is blocking.
I would hope that users of this software would be free to download blocking lists from anybody they wanted to, and to merge and intersect lists. Or even to subtract lists, thus lists of "sites that should not be blocked" would work.
OSS programmers are much more adapt at programming complex and powerful pattern matching rules than any of the commercial houses (apparently because this is the type of software that very much benifits from the many-eyes complex). They may have the capability to produce a system that works.
Because the lists can be reversed, people searching for pr0n might find them useful, and this may encourage pr0n providers to match the results more carefully, actually improving the censorware!
Context switches are a problem. But the difference is not that X has 2 (client->kernel->server) and Windows has 1 (client->kernel).
The problem is "synchronous" interfaces, where you make a call and that call, besides doing something to the screen, returns a value. This actually requires 4 context switches on X and 2 on NT according to your design.
What is needed is non-synchronous or stream-based interfaces. In this case all the things you want to draw on the screen go into a buffer and are eventually flushed. This has the potential of making the number of context switches per operation .001 (note the decimal point) or smaller!
With such a design the overhead of not putting the server in the kernel is miniscule, and you get all the advantages of making it user level.
The problem is that both are designed with large numbers of synchronous interfaces. Windoze has an excuse in that it is based on W3.1 where everything was synchronous, but X was designed as a server, and they really had no excuse for doing stupid things like requiring a round trip to allocate a color or to set the current font.
I do hope that X will be replaced someday, like soon, but we should design it right. Hacks with memory mapping and direct rendering and kernel modules are nice, but none of them come close to the win you will get with an interface that is designed to be piped. The problem is that any such interface is going to incompatable, it is impossible to emulate a synchronous interface atop an async one.
Despite Mr. Bush's feverent wishes, all those plants could be turned back on and run at 100% capacity without violating any environmental regulations.
Therefore the regulations have absolutely nothing to do with the power shortage.
A lot of serialized interfaces become much easier to program if a global state is preserved. It can also be much faster in many cases as no checks are needed to see what is different between the new and previous arugments.
I also think this is vital to get the drawing code away from the toolkits. OpenGL has this and we people writing Qt, GTK, Windows MFC, and other programs can cut & paste there OpenGL code between them!
Xlib and Win32 GDI do not do this, and nobody bothers bothers emulating one of these on the other, despite the portability advantages. This is because the application has to retrieve the static information (the "gc") from the toolkit library, binding your code to the toolkit, and making portability between the toolkits impossible.
Beloved Sun, indeed. You obviously don't read the text here. Even Linux zealots are mad that Sun seems to be spurning them! You don't even seem to be reading the extremest attitudes here!
Yes, certainly, but you are wasting a lot less of it by not taking over the whole screen, which is what the current X solutions do.
Yes, flowing text is nice. But html should have had a "draw in x,y,w,h" command to give the rectangle to format the text into. Perhaps x,y,w,h could be given in percentages of the window size or relative to the bottom of the last rectangle, as well as in pixels. But that and a "fill x,y,w,h" rectangle call would have gotten rid of the need to use tables and CSS and frames and all the other messiness, and probably would have been supported perfectly in Netscape 1.0 and in every other browser in the world (Lynx could even round to the nearest character cell).
If html had simply had a "go to pixel x,y" command we would not be in this horrible mess of incompatable browsers and we would have quick-rendering pages without huge messes of nested tables. I'm sorry, but this attitude is entirely responsible for the hell we are in now.
I also don't think strict compliance is very important. I would be happy if I could rely on a command-line program (no X) that does no ioctl calls was the only thing guaranteed to work (and it can read any file, so NT does not conform to this). For instance they can go ahead and break that incredible mess that is pseudo-ttys and the terminal driver.
NT DOES NOT conform to the POSIX standard in any useful way. For instance, a file created by a POSIX program is not visible to a normal NT program, and vice-versa. This makes it totally useless. They also did a very minimal support of POSIX, so minimal that no real program can port to it. It was simply so it could be checked off on government requirement lists, but purposely broken enough that nobody would write portable programs for NT.
This will allow any X program to run on the Mac (and will probably allow remote X applications to appear in windows on the Aqua screen, too).
Even with this, I would expect ported toolkits to produce faster and more reliable code.
A much better example is that I bought my house lock from Acme and Acme keeps private how the innards works, not revealing the fact they just figured out that all hairpins in the world work just fine if bent in a certain way.
If the original mice had printed something (like "menu" or "right" or anything) on the buttons, I don't think there would be any argument today and there would be multi-button mice.
Even bad copies will stop their real intention, to force people into a system where they pay per view, always. They also don't want to allow you to fast-forward through commercials.
They will not stop until the signal is piped directly into a chip implanted in your brain, and modifications are made so you are incapable of describing the signal to another person.
Imagine even the simplest display, some black text on a white background. In your case the server automatically clears exposed areas to white.
Take a sample pixel that lies inside a black letter. It will initially have the old window's contents. When exposed the server changes it to white. When drawn the server changes it to black. That is 2 transitions.
Now imagine the program is super-efficient at drawing (or that it copies the data from a backing store, as you suggest), so that it only draws each pixel once. Then initially that pixel will have the old window's contents. When drawn it will turn black. This is 1 transition, the minimum possible.
Now you can argue that nobody draws their data like that, and any reasonable program will result in 2 blinks anyway, but the fact remains that if the server clears it, it is impossible to avoid the 2 blinks.
I also argue that simple application will erase the background even if the server did. This will result in 3 writes to the pixel, even if two of them are the same white color. This is not cheap, 1000 pixels does take some machine time and it is worth it to save one pass.
Also, even if the program blinks I think it is less objectionable since it will draw the two images right next to each other in time. If the server erases it there could be a quite long time where the display is showing the cleared area, making the blink much more visible.
Backing store like the NeXT had is nice (and it can be faked on X by mapping a single large pixmap as the background for the window). In fact I believe it is the only solution that allows the server to decide what to do with exposed area. But unfortunately most modern hardware does not allow hardware accelerated graphics to be used there, defeating most of the advantages.
Because middle-mouse click allows the user to cancel by not doing the paste at all, this move behavior is not necessary. I actually think a copy behavior would be more useful and consistent (since that is what is done between programs). Middle-mouse also allows the user to select, delete, and then paste, allowing drag&drop to do either a copy or a move by the user's choice.
As you point out, there are big problems with the same buffer being used for middle-mouse drag&drop and cut/paste, as selecting something wipes out the users cut, since in middle-mouse terms the user has just started a drag. In Windows drag&drop this is not a problem because click that starts a drag is not needed to edit text otherwise, and I suspect Windows users would never notice if drag & drop replaced the clipboard contents.
Unfortunately through historical failure to notice that middle-mouse click is different from cut/paste, we are probably stuck on X with the same buffer used for both.
BUT, I do think a single buffer could be used, if it was not changed when a selection is done (or the drag is started), but rather when the focus exits the buffer, (or even better it should change at the moment the middle-mouse/"drop" is done but this cannot be done on either Windows or X). I am working on implementing this behavior in fltk right now.
"Middle mouse button paste" (and the automatic selection->copy) of X is exactly the same as Drag and Drop! EXACTLY!
Therefore, a proper implementation would merge this behavior with any drag and drop behavior and use the same buffer. While a seperate buffer should be used for the ^X^V cut/paste operations.
Unfortunately there are a lot of X programs (my own stuff included) that use the same buffer for the middle mouse click and for the ^X^C. This is what my original message was about, and it is a problem. However too many people seem to think the middle-mouse stuff is cut/paste and should be seperate from drag & drop, when in fact they are identical and the original X behavior, while cut & paste is the "new" stuff for X. Unfortunately event the drag & drop standards for X have fallen into this so that the only compatable thing to do is have THREE buffers (selection, "clipboard", and "drag and drop"). Very few programs use the SELECTION buffer as well (many of them consider it more drag & drop than the clipboard, too), forcing the same buffer to be used if you want ^X^C to work between programs.