Oh come on, I like gcc and all that, but it is pretty obvious that MSVC makes faster code when you turn on all the optimizations. The difference is totally obvious to an end user and does not require any timing tests. (This is with code using the fltk toolkit and huge amounts of floating point math, and not using any MFC or other MicroSoft libraries other than the ones that gcc can compile with).
(it is also true that the MSVC optimizer is full of bugs, though, forcing us to select which files we need to optimize. But this pain is easily worth it to get the speed increase).
The "technical" reason is that the XFree86 people are totally paranoid about back compatability and the Xlib interface to fonts sucks.
XRender provides an all-new and much nicer interface to fonts, and it makes sense for programs to use it. However it would be nice to see a rewrite of Xlib so that attempts to use old font calls cause emulation code to be run that draws Xft fonts.
MicroSoft deserves credit for implementing anti-aliased fonts while both Mac and X people were convincing themselves it was impossible or too slow. They also deserve credit for having the balls to change their already existing font interface to draw the new fonts, despite the fact that some programs that depended on the exact pixels drawn would break and make people mad. It did help them that thier font interface sucked less than 1/10th as much as Xlib, though...
Xft does not cause old X11 programs to suddenly be antialiased. What the "native X11 calls" means is that Xft works (in that it produces readable output) if it talks to an X server that lacks the Xrender extension or that lacks the fonts.
This won't help the end-user much, but it is a huge deal because it removes the main impediment stopping all programs from immediatly switching to xft.
Normally when somebody makes an "extension" to an existing interface they write it so you cannot use the "extension" without also updating what you are talking to. This means that anybody writing a program using the new interface either has to say "you have to update your drivers" which is user-unfriendly, or they have to put in a big mess of code to "detect" the extension and then have to write two interfaces, one using the extension and one not. The real result is almost nobody uses the extension because it it too much of a pain to write to.
X is horrid with these things. Shared memory images (an interface now 15 years old) required you to detect whether the server did it and write totally different code for non-shared. The result is that the majority of programs don't use shared memory images. If they had written the detection and emulation into it, I'm sure *EVERY* program would use shared images today.
Congrats to Keith Packard for figuring this out!
Now lets see the same thing done for the rest of XRender, so we can get anti-aliased lines and shapes without having to write everything twice.
Actually the deal is that LCD screens have three rectangles for the pixels, a red one, green one, and blue one, next to each other.
Normal screens do draw a round dot but there is the phosphor mask in front of that which are the pattern you see, diffraction by the screen makes the dots themselves overlap. On modern screens each pixel is then a blurry overlapping circle cut out of a pattern of vertical stripes of red, green, and blue. There is probably a way to take advantage of this for improved antialiasing but there seems to be no control over the exact registration of this pattern with the dot location, unlike the LCD.
Fonts on X are a pretty huge mess. The main thing to know is that about 90% of the fonts you see in some lists are back-compatability fonts and programs ignore them. This is an unfortunate mess but I think keithp is doing the right thing now with Xft. For now you may see names like these:
Names like "fixed10" or "lucidasans10" (ie with a number on the end) are very old X fonts, which were only useful for terminal programs. Most modern programs ignore these, but in a list of all fonts they make up at least 50%.
Names like "-adobe-helvetica-p-a-crap-foo-*-*-*-more-crap-iso 8859-1" are the designed-by-committee attempt to make useful names for fonts and handle scaling fonts. It sucks but until Xft anybody programming X fonts had to deal with this.
Most common now you will see lists that look rather nice like "Helvetica" with some check marks for bold, italic, and a font size. Unfortunately these are made by the program by finding all the fonts with the above ugly dash names and attemting to extract something usable by mortals from it. The main problem is that all the programs and toolkits made up their own rules about how to extract this, so "helvetica at size 10" in one program may produce something different than in another program.
In modern programs you will also see "Helvetica" and you may see "Sans" and "Serif". These are names for Xft. Xft uses True-Type fonts and totally ignores the old X font mechanism, thus it is possible that the set of fonts is completely different than the "old" programs. In most cases however the fonts are shared by the old and new programs, so the "Helvetica" you see is the same one, but the "old" programs the "nice" name "Helvetica" has been translated into the "ugly" dash-name by X and then back-translated by the toolkit, so the names probably don't match very well. The big advantage is that Xft decides and controls the "nice" names so at least all programs using Xft will agree. I'm sure Xft will completely take over within a year so this horrid mess will be fixed.
Actually people learn Point-to-type really fast. Here at work we have all Linux machines set to it and many NT machines (it can be done with a registry setting) and the users adapt to it almost immediatly. Often they don't even notice it is turned on.
Going from point-to-type to click-to-type is almost impossible and causes severe errors when commands are typed to the wrong window.
Granted everybody here is using a desktop mouse or trackball. There may be problems with adapting to point-to-type with an easily-moved thing like a pen tablet.
I have not checked it yet but I believe the new Qt is using the seperate Clipboard/Selection that KDE and some versions of Motif used. The problem is it does not really work so well with older programs.
There are two clipboards called "Clipboard" and "Selection". When you select a block of text it is immediately copied into "Selection". When you click with the middle mouse button it inserts the current contents of "Selection". When you cut/copy it with a command (such as Ctrl+C) it is copied to "Clipboard" but that is unchanged otherwise, and pasting commands (such as Ctrl+V) paste the contents of "Clipboard".
This avoids confusing Windows users and still allows the drag&drop power of the older X selection and middle mouse click.
However older applications did not know anything about "Clipboard". Instead both selecting text and copy commands changed the value of "Selection", and both middle mouse click and paste commands pasted the contents of "Selection".
The result is that if you have program "New" and program "Old":
Selecting text and pasting (dropping) it with the middle mouse button works both ways between the programs.
If you "copy" in the New program, the Old program will not see it. Attempts to paste will get the last selection (this often is the same as the copied text but not always), the same as using the middle mouse.
If you "copy" in the Old program, if you try to "Paste" in the New program you will not get it, instead you will get the last "copy" from a New program. You need to click the middle mouse button to "paste". This is by far the most annoying incompatability.
Hopefully the "old" programs will vanish over time. I am trying to do my part...
There is no reason Linux cannot be modified so that every program can access every object by name. It is the way Unix was designed (remember what/dev was for?) And there is no reason this basic functionality should be in a user interface toolkit, it should be in the system (or at least in libc) so I don't have to think about it when writing software!
Honestly I expected this sort of interface 12 years ago. Plan9 did it but it seemed to not conflict with Unix. What is taking so long?
This would be fine except it appears that Sony is ignoring literally DOZENS of mod-chip makers who make chips that can ONLY be used to play pirate games. Then the first chip comes out that outwits the region-lock and Sony attacks!
"Piracy" is only a smoke-screen and that region controls are much much more important to Sony. This is obvious if you calculate how much money they are losing:
Your friends probably would have bought *ZERO* of those games that they got for free, because there is a HUGE perceived price differential between free and any cost whatsoever. So Sony lost nothing. But anybody who *BUYS* the overseas disk (and pays to ship it!) would likely BUY the disk for an inflated price when it appears locally (the inflated price is probably less than the cost of getting that overseas disk). Thus Sony loses the difference between the inflated local price and the foreign disk.
They will talk all they want about "piracy" but Sony knows the real area they are losing money and they are attacking the region coding. They cannot admit it because they will lose their case, but there actions prove it.
As for "piracy" if Sony thought they could do anything about it they would go after the Asian manufacturers who are actually *selling* pirated games. In this case many of the people using those pirated games would have bought the real game (because the pirated copy is not free) so this represents real losses of potential sales.
Ok, I want to report that I have been abducted by aliens and taken to the far side of the moon. Why isn't Reuters reporting it? They don't have to believe it to report it, right?
Re:Backing store vs Double buffering
on
Xfree86 4.2.0 Out
·
· Score: 2
It can forget it, or it can render into the backing store (I don't think any X servers do that, but they could). It can also choose to put back the unchanged version, but it does have to send an expose event.
As far as I can tell XFree86 is putting back the unchanged version but failing to send the expose event. Either that or when my software responds to the expose event the area is still obscured by the overlapping window so the update is thrown away, or some other bug causes it to draw the saved buffer a second time after I update. I gave up using save behind because of this but I could experiment some more to find out what is going on...
I don't recall transparency on the NeXT, but it double buffered to save apps the trouble of implmenting redraws
You are right the NeXT did not do transparency compositing of the windows. It was strictly used to avoid redraws, and to speed up the dragging of windows.
Re:Backing store vs Double buffering
on
Xfree86 4.2.0 Out
·
· Score: 3, Informative
No, backing store is different than double buffering. Both have an off-screen image that corresponds to a part of an on-screen window.
Backing store (as used by X) copies the part of the screen that is being hidden by a new window to an off-screen area. It can then copy parts of it back when that obscuring window is moved or removed.
Double buffering lets the program draw into the offscreen area, and then it copies that offscreen area to the screen (either automatically or on a program command).
Backing store sounded like a good idea when most overlapping windows were assummed to be pop-up menus. It does not work if the underlying window changes (which almost all modern toolkits do, due to them copying Windows's highlighting of menu titles, or due to the focus moving to the window). If the underlying area is drawn to, X is supposed to forget the backing store, but XFree86 seems to not do this, this indicates how little backing store is used that nobody bothers to fix this.
Double buffering is much more useful, though it uses a lot more memory. If the entire image of the window is stored then transparency of the windows is possible without having to draw them all from back to front. For this reason all X and Windows hacks that produce transparency of all windows use double-buffering, also OSX uses it. NeXT used it too. It is also possible and useful to double-buffer only the visible portion of the window, this is what OpenGL and probably DirectX and all other 3D systems do because the offscreen area is the same size as the screen, but you lose the ability to move or composite transparent windows without redrawing.
This is correct. The unavoidable flicker is due to the fact that the window frame is drawn by a seperate program (the window manager) than the contents.
Other causes of flicker: multiple visuals (not a problem on most Linux XFree86 systems), and toolkits (fixable with double buffering and can be reduced though not eliminated by the programmer of the toolkit).
I think the window hould be put into the toolkit. The window borders are no different than any other widget. In fact I believe far more code is expended trying to talk to a window manager than would be needed to do this in a toolkit (which already contains code to draw the buttons and borders). This would allow new ideas in window management to be experimented with, such as getting rid of the borders entirely.
The system might provide a "Task Manager" (using the term taken from Windows) that any program creating a window would talk to. The program would indicate the task that window belonged to and the name of the window itself. The task manager would send commands like "raise this window" or "map this window" or "hide this window" to the program, and by watching the visiblity and positions of windows could provide pagers, icons, and taskbar type interfaces.
I strongly believe that putting widgets into the server is BAD. If X had done this we would be using Athena widgets right now and X would look laughably bad. The fact that X can emulate Windows and Mac interface designs invented 10 years after X was is definate proof that keeping UI elements out of it was the best possible design.
GEM definately did copy the style of the Apple interface, including the appearance of the icons on the desktop and the title bars and resize handle of the windows. The Star did not have window borders (other than a 1-pixel line) and the icons were different with very few diagonal lines, and did not have a menu bar at the top.
To the other poster who said there were technical reasons Apple did not do multitasking, that would appear to be false, as the Lisa already did (cooperative) multitasking, and so did GEM and several DOS clones, and Unix-like systems, all on hardware commonly available then. Memory protection and true time slicing multitasking was available for only a slightly greater price such as was in workstations or in the MicroVax. The lack of Multitasking in the Mac was probably one of the biggest mistakes they did, otherwise I think they would have wiped Unix and Windows off the desktop.
As I graduated from MIT in spring of 1983 and immediately went to work for a PC software company (Mark of the Unicorn, writing their word processor) I can date things pretty well in these times.
There was absolutely no Windows until fall of 1985, two years after I started work (the first project took 2 years). At this time we started looking at the "tiled" Windows system (I guess that is 3.0). Although our company did not posess any machines running X (they were too expensive) we did have the entire X reference manuals at that time, on the assumption (perhaps foolish) that MicroSoft might copy at least the names of the calls...
This system worked so badly that we started looking at Digital Research's GEM (which may have been worse, actually). I also considered writing a stream-based windowing system on top of DOS and implemented a DOS driver that worked on Hercules graphics cards and SVGA displays, this was strongly influenced by the knowledge that X used streams to communicate and that such an interface would be needed if there was memory protection (something that did not appear in DOS for ten years...). This successfully ran overlapping windows and drew proportionally spaced text and filled arbitrary polygons before I decided that it was pointless to compete with the upcoming Windows (which was still years away).
The Macintosh came out at the end of 1984, of course, but except for a silly game (Mouseapede) we did nothing about it for a year, then MOTU started working on music software for it. By that time I had worked with Xlib programming and NeWS at MIT in the media lab, not much, but at least some programs, I had written nothing for Windows because the instructions were completely opaque to me, talking about resources and all that crap, all of which I figured was to work around the lack of virtual memory (true) but I again foolishly thought MicroSoft would fix this really soon, since I knew far less powerful Unix workstations had had it for a decade now.
Anyway I know I saw my first machine running Windows in the real world in my second year at USC (1987). This was windows 3.2, I think, the first working one. I was aware they had scrapped the tiled windowing years earlier.
I do not clearly remember when there was not an "X" windowing system. Certainly it did not exist when I was at MIT, but the name and the manuals were well know in the spring of 1984, definately before the Macintosh annoucement. I remember being seriously disappoited that the Macintosh did not have multitasking (a mistake that has hurt them until today), considering the Lisa did (though it had a limit of 6 proceses).
Anyway, enough rambling, but it is clear to me that all aspects of X predate Windows. Windows 93 copied the keyboard navigation from the CDE desktop environment, which had been in development for several years before that (and was based somewhat on the Macintosh, and on existing X standards).
What an idiot. Ever heard of "Direct-X"? I seem to remember it is a MicroSoft product, maybe they are not marketing it enough or you would have heard of it?
The name was obviously chosen because at the time (about 1990?) "kool" computers used something called "X".
If this is a worry, release your code under your own modification of the GPL where you add a clause that says you reserve the right to remove the GPL license in the future.
In reality this is not a worry. They only have the rights to the old version of the code. Surely you have enhanced it some at the same time you decided to make it proprietary!
As the anonymous responder said, NeWS is NOT Display PostScript!. It was Sun's own PostScript interpreter and did the complete job of X. It did not contain any Adobe code.
Display PostScript was an attempt by Adobe to add PostScript to X. It could only draw into a window, you needed to use Xlib to create the window. This was purchased by NeXT and the X part was thrown away and replaced with some simple PostScript calls to create windows to make the NeXT windowing system.
NeWS had an enourmousely simpler and faster method of compressing PostScript into a data stream that pretty much involved reserving some bytes to mean the most common postscript keywords and to introduce arrays of floating point numbers that were imbedded in the data stream. DPS required a compiler that produced machine-specific data structures that also appeared to be highly specific to their PostScript interpreter, I feel this was an infinitely worse design.
NeWS also used PostScript to advantage to control non-drawing things. For instance the shape of a window was controlled by a PostScript path and the position (and rotation!) by a PostScript transformation. Original DPS had none of this, requiring ugly Xlib stuff, and NeXTStep only had simple "create a rectangular window and return it's id" calls that did not integrate so well.
NeWS was enormously better than DPS and anything else out there and it was a shame Sun blew it by trying to charge for it.
I do agree that downloading widgets was NeWS's main defect. It made communication between app and server very difficult and the only programs that really worked were entirely written in PostScript to avoid this communication. But other than this mistake, the unified single interface to create windows, draw *advanced* graphics, and manage events with easy string-based interface was far ahead of anything that has been invented since.
Originally X only had middle-mouse selection. It worked like this: any selection you made acted as though you then immediately did a copy operation (like Ctrl+C on Windows). Clicking the middle mouse button was like clicking the left mouse button to move the cursor to that point and then doing a paste operation (like Ctrl+V on Windows). The buffer that held this data was called SELECTION.
In some ways this was very nice. It certainly required the fewest possible operations to copy something, and did not require any key assignments. Technically it is exactly the same as drag & drop (which everybody ooh's and aah's over for some reason...) but with the advantage that you could rearrange windows before you "dropped" (ie no need for Mac "spring loaded folders" or any other hacks).
It has losing points that people are aware of: any selection anywhere destroys the clipboard, making *replacement* of text impossible without planning ahead and requiring extra mouse clicks. It also required you to point the mouse even if the cursor was already at the correct location for the paste (some programs made middle click only do the paste and not the click because of this, resulting in inconsistent behavior).
The Motif people did figure out the correct way to emulate Windows/Mac was to have a second buffer called the CLIPBOARD. This is obvious if you think about middle mouse as drag & drop, there is no reason that dragging data should change the clipboard! Fortunately X already had support for an arbitrary number of such buffers due to some bogus and best-forgotten ideas about "secondary selection" and so on so it was easy to do this.
However all other toolkits were concerned about interoperability between them and older programs that did not understand CLIPBOARD. So they tended to just use the SELECTION for Ctrl+C/Ctrl+V. This confused Windows users no end because selection of text still changed the clipboard, and made Ctrl+C be a no-op in most cases.
Motif died for very good reasons, but since it understood clipboard, this is why you hear complaints that you cannot cut/paste from Netscape into other programs. Middle-mouse has always worked, though.
Fortunately in the last year GTK decided to switch to the Motif model of CLIPBOARD. It sounds like the next version of Qt (and thus KDE) also does this. I personally have fixed my own software to obey this.
Unlike common perception the programs on X do not all use incompatable cut & paste, though. They all agree on the initial design. It is the attempts to emulate an outside design, with no standards, that they disagree on. If Windows added middle-mouse paste today you can be certain that years from now there would be many programs that still "can't cut and paste correctly" on that platform, too!
Why doesn't Sun open-source NeWS. Granted the chance of it being useable now is slim, but it would be nice to see Sun try to make up for one of the biggest sins in the history of computer science.
I truly believe that if Sun had open-sourced a reference implementation of NeWS back in 1985 that right now it would be Scott McNealy on the government witness stand right now and everybody as SlashDot would call them $un. This is because Sun would be in control of the NeWS standard and could propose and release any enhancements to it before anybody else. They could also close-source it, or close-source the enhancements (like people worry about MSoft doing with.net), if they wanted. But to do any of this it had to be accepted, and it was not going to be accepted when it cost vast amounts of money and there was another thing (X) that, while obviousy 100 times crappier, was free (well $115 for a tape of the source code).
Very badly worded. Every company that tries to make money off a "free" product will fail, for obvious reasons.
You are assumming "open source" == "free". The actual question is whether this assumption is true or not (and, despite claims to the contrary here on SlashDot, I think it is possible that this assumption is true).
If you assumme this is true, a further question is whether some non-free product can somehow be linked to a free product so that the company makes money. Broadcast TV seems to indicate that vast sums of money can be made this way, but it is not clear if any such setup can be done for source code. Except for zealots on SlashDot, most people are asking if this is possible.
However you worded the question as though you assummed "open source"=="free" is a true statement. That has not been proven.
They can do this easily, if they give up on "DRM".
How? By putting a real "watermark" on the data. This watermark is not to prevent copying, and in fact it must have absolutely no effect on any consumer device. They then have an easy automated test they can do to data they find on the internet, and detect people selling or otherwise distributing copyrighted works, and go after them with the law. Once the illegal data has been detected humans can look at it and easily determine and prove that it is copyrighted, there is no need for the watermark's techniques to be revealed in court.
Unfortunately they are going to insist on blowing it by trying to avoid the need for law by making consumer devices recognize the watermark and trying to avoid copying that way. The problem with this is that it provides hackers with a trivial test to see if the watermark is there and allows them to remove it!
They could try both, but they shoud realize that if the hacker is encouraged to mess with the data due to the copy-prevention watermark, it is quite likely they will accidentally remove the other watermark, or they will detect the other watermark during their attempts to remove the copy-protection one (since it is likely the technologies will be tied together).
The people running the MPAA, etc. are idiots. They are sabotaging their own ability to stop pirates, and pissing off the consumers at the same time with difficult-to-use and overpriced equipment. Unfortunately there seems to be no way to change their mind because they have no knowledge of technology.
This control panel is precisely what I was talking about, I am unable to get what I consider correct behavior. Primarily it is impossible to move windows using the title bar without raising them. Turning this off makes it impossible to raise windows at all.
I have been meaning to look at the source code, I do think the kde people would be receptive to changes (I have also written a window manager of my own flwm, so I think I can do this).
One difficulty with both major window managers is the "what does this mouse button do" type of controls. These are not user friendly, allow you to set it to an infinite number of useless settings, and often do not allow you to set it to behave as wanted. I would prefer a few checkmarks to control the major unknowns about window management:
Click-to-type or point-to-type (for point to type just use sloppy focus, the others serve no reason).
Click in contents raises window.
Timeout to raise focused window (works in click-to-type as well as point-to-type).
Dragging or resizing a window (using the title bar or window border) raises it.
In my opinion these are the only things that need changes. What each mouse button does can be fixed by the window manager or intelligently figured out from the above settings.
Slashdot Mirror
(it is also true that the MSVC optimizer is full of bugs, though, forcing us to select which files we need to optimize. But this pain is easily worth it to get the speed increase).
match any pixelsize > 8 any pixelsize < 15 edit antialias = false;
This goes into ~/.xftconfig or into /etc/X11/XftConfig.
XRender provides an all-new and much nicer interface to fonts, and it makes sense for programs to use it. However it would be nice to see a rewrite of Xlib so that attempts to use old font calls cause emulation code to be run that draws Xft fonts.
MicroSoft deserves credit for implementing anti-aliased fonts while both Mac and X people were convincing themselves it was impossible or too slow. They also deserve credit for having the balls to change their already existing font interface to draw the new fonts, despite the fact that some programs that depended on the exact pixels drawn would break and make people mad. It did help them that thier font interface sucked less than 1/10th as much as Xlib, though...
This won't help the end-user much, but it is a huge deal because it removes the main impediment stopping all programs from immediatly switching to xft.
Normally when somebody makes an "extension" to an existing interface they write it so you cannot use the "extension" without also updating what you are talking to. This means that anybody writing a program using the new interface either has to say "you have to update your drivers" which is user-unfriendly, or they have to put in a big mess of code to "detect" the extension and then have to write two interfaces, one using the extension and one not. The real result is almost nobody uses the extension because it it too much of a pain to write to.
X is horrid with these things. Shared memory images (an interface now 15 years old) required you to detect whether the server did it and write totally different code for non-shared. The result is that the majority of programs don't use shared memory images. If they had written the detection and emulation into it, I'm sure *EVERY* program would use shared images today.
Congrats to Keith Packard for figuring this out!
Now lets see the same thing done for the rest of XRender, so we can get anti-aliased lines and shapes without having to write everything twice.
Normal screens do draw a round dot but there is the phosphor mask in front of that which are the pattern you see, diffraction by the screen makes the dots themselves overlap. On modern screens each pixel is then a blurry overlapping circle cut out of a pattern of vertical stripes of red, green, and blue. There is probably a way to take advantage of this for improved antialiasing but there seems to be no control over the exact registration of this pattern with the dot location, unlike the LCD.
Names like "fixed10" or "lucidasans10" (ie with a number on the end) are very old X fonts, which were only useful for terminal programs. Most modern programs ignore these, but in a list of all fonts they make up at least 50%.
Names like "-adobe-helvetica-p-a-crap-foo-*-*-*-more-crap-iso 8859-1" are the designed-by-committee attempt to make useful names for fonts and handle scaling fonts. It sucks but until Xft anybody programming X fonts had to deal with this.
Most common now you will see lists that look rather nice like "Helvetica" with some check marks for bold, italic, and a font size. Unfortunately these are made by the program by finding all the fonts with the above ugly dash names and attemting to extract something usable by mortals from it. The main problem is that all the programs and toolkits made up their own rules about how to extract this, so "helvetica at size 10" in one program may produce something different than in another program.
In modern programs you will also see "Helvetica" and you may see "Sans" and "Serif". These are names for Xft. Xft uses True-Type fonts and totally ignores the old X font mechanism, thus it is possible that the set of fonts is completely different than the "old" programs. In most cases however the fonts are shared by the old and new programs, so the "Helvetica" you see is the same one, but the "old" programs the "nice" name "Helvetica" has been translated into the "ugly" dash-name by X and then back-translated by the toolkit, so the names probably don't match very well. The big advantage is that Xft decides and controls the "nice" names so at least all programs using Xft will agree. I'm sure Xft will completely take over within a year so this horrid mess will be fixed.
Going from point-to-type to click-to-type is almost impossible and causes severe errors when commands are typed to the wrong window.
Granted everybody here is using a desktop mouse or trackball. There may be problems with adapting to point-to-type with an easily-moved thing like a pen tablet.
There are two clipboards called "Clipboard" and "Selection". When you select a block of text it is immediately copied into "Selection". When you click with the middle mouse button it inserts the current contents of "Selection". When you cut/copy it with a command (such as Ctrl+C) it is copied to "Clipboard" but that is unchanged otherwise, and pasting commands (such as Ctrl+V) paste the contents of "Clipboard".
This avoids confusing Windows users and still allows the drag&drop power of the older X selection and middle mouse click.
However older applications did not know anything about "Clipboard". Instead both selecting text and copy commands changed the value of "Selection", and both middle mouse click and paste commands pasted the contents of "Selection".
The result is that if you have program "New" and program "Old":
Selecting text and pasting (dropping) it with the middle mouse button works both ways between the programs.
If you "copy" in the New program, the Old program will not see it. Attempts to paste will get the last selection (this often is the same as the copied text but not always), the same as using the middle mouse.
If you "copy" in the Old program, if you try to "Paste" in the New program you will not get it, instead you will get the last "copy" from a New program. You need to click the middle mouse button to "paste". This is by far the most annoying incompatability.
Hopefully the "old" programs will vanish over time. I am trying to do my part...
There is no reason Linux cannot be modified so that every program can access every object by name. It is the way Unix was designed (remember what /dev was for?) And there is no reason this basic functionality should be in a user interface toolkit, it should be in the system (or at least in libc) so I don't have to think about it when writing software!
Honestly I expected this sort of interface 12 years ago. Plan9 did it but it seemed to not conflict with Unix. What is taking so long?
"Piracy" is only a smoke-screen and that region controls are much much more important to Sony. This is obvious if you calculate how much money they are losing:
Your friends probably would have bought *ZERO* of those games that they got for free, because there is a HUGE perceived price differential between free and any cost whatsoever. So Sony lost nothing. But anybody who *BUYS* the overseas disk (and pays to ship it!) would likely BUY the disk for an inflated price when it appears locally (the inflated price is probably less than the cost of getting that overseas disk). Thus Sony loses the difference between the inflated local price and the foreign disk.
They will talk all they want about "piracy" but Sony knows the real area they are losing money and they are attacking the region coding. They cannot admit it because they will lose their case, but there actions prove it.
As for "piracy" if Sony thought they could do anything about it they would go after the Asian manufacturers who are actually *selling* pirated games. In this case many of the people using those pirated games would have bought the real game (because the pirated copy is not free) so this represents real losses of potential sales.
Ok, I want to report that I have been abducted by aliens and taken to the far side of the moon. Why isn't Reuters reporting it? They don't have to believe it to report it, right?
As far as I can tell XFree86 is putting back the unchanged version but failing to send the expose event. Either that or when my software responds to the expose event the area is still obscured by the overlapping window so the update is thrown away, or some other bug causes it to draw the saved buffer a second time after I update. I gave up using save behind because of this but I could experiment some more to find out what is going on...
I don't recall transparency on the NeXT, but it double buffered to save apps the trouble of implmenting redraws
You are right the NeXT did not do transparency compositing of the windows. It was strictly used to avoid redraws, and to speed up the dragging of windows.
Backing store (as used by X) copies the part of the screen that is being hidden by a new window to an off-screen area. It can then copy parts of it back when that obscuring window is moved or removed.
Double buffering lets the program draw into the offscreen area, and then it copies that offscreen area to the screen (either automatically or on a program command).
Backing store sounded like a good idea when most overlapping windows were assummed to be pop-up menus. It does not work if the underlying window changes (which almost all modern toolkits do, due to them copying Windows's highlighting of menu titles, or due to the focus moving to the window). If the underlying area is drawn to, X is supposed to forget the backing store, but XFree86 seems to not do this, this indicates how little backing store is used that nobody bothers to fix this.
Double buffering is much more useful, though it uses a lot more memory. If the entire image of the window is stored then transparency of the windows is possible without having to draw them all from back to front. For this reason all X and Windows hacks that produce transparency of all windows use double-buffering, also OSX uses it. NeXT used it too. It is also possible and useful to double-buffer only the visible portion of the window, this is what OpenGL and probably DirectX and all other 3D systems do because the offscreen area is the same size as the screen, but you lose the ability to move or composite transparent windows without redrawing.
Other causes of flicker: multiple visuals (not a problem on most Linux XFree86 systems), and toolkits (fixable with double buffering and can be reduced though not eliminated by the programmer of the toolkit).
I think the window hould be put into the toolkit. The window borders are no different than any other widget. In fact I believe far more code is expended trying to talk to a window manager than would be needed to do this in a toolkit (which already contains code to draw the buttons and borders). This would allow new ideas in window management to be experimented with, such as getting rid of the borders entirely.
The system might provide a "Task Manager" (using the term taken from Windows) that any program creating a window would talk to. The program would indicate the task that window belonged to and the name of the window itself. The task manager would send commands like "raise this window" or "map this window" or "hide this window" to the program, and by watching the visiblity and positions of windows could provide pagers, icons, and taskbar type interfaces.
I strongly believe that putting widgets into the server is BAD. If X had done this we would be using Athena widgets right now and X would look laughably bad. The fact that X can emulate Windows and Mac interface designs invented 10 years after X was is definate proof that keeping UI elements out of it was the best possible design.
To the other poster who said there were technical reasons Apple did not do multitasking, that would appear to be false, as the Lisa already did (cooperative) multitasking, and so did GEM and several DOS clones, and Unix-like systems, all on hardware commonly available then. Memory protection and true time slicing multitasking was available for only a slightly greater price such as was in workstations or in the MicroVax. The lack of Multitasking in the Mac was probably one of the biggest mistakes they did, otherwise I think they would have wiped Unix and Windows off the desktop.
There was absolutely no Windows until fall of 1985, two years after I started work (the first project took 2 years). At this time we started looking at the "tiled" Windows system (I guess that is 3.0). Although our company did not posess any machines running X (they were too expensive) we did have the entire X reference manuals at that time, on the assumption (perhaps foolish) that MicroSoft might copy at least the names of the calls...
This system worked so badly that we started looking at Digital Research's GEM (which may have been worse, actually). I also considered writing a stream-based windowing system on top of DOS and implemented a DOS driver that worked on Hercules graphics cards and SVGA displays, this was strongly influenced by the knowledge that X used streams to communicate and that such an interface would be needed if there was memory protection (something that did not appear in DOS for ten years...). This successfully ran overlapping windows and drew proportionally spaced text and filled arbitrary polygons before I decided that it was pointless to compete with the upcoming Windows (which was still years away).
The Macintosh came out at the end of 1984, of course, but except for a silly game (Mouseapede) we did nothing about it for a year, then MOTU started working on music software for it. By that time I had worked with Xlib programming and NeWS at MIT in the media lab, not much, but at least some programs, I had written nothing for Windows because the instructions were completely opaque to me, talking about resources and all that crap, all of which I figured was to work around the lack of virtual memory (true) but I again foolishly thought MicroSoft would fix this really soon, since I knew far less powerful Unix workstations had had it for a decade now.
Anyway I know I saw my first machine running Windows in the real world in my second year at USC (1987). This was windows 3.2, I think, the first working one. I was aware they had scrapped the tiled windowing years earlier.
I do not clearly remember when there was not an "X" windowing system. Certainly it did not exist when I was at MIT, but the name and the manuals were well know in the spring of 1984, definately before the Macintosh annoucement. I remember being seriously disappoited that the Macintosh did not have multitasking (a mistake that has hurt them until today), considering the Lisa did (though it had a limit of 6 proceses).
Anyway, enough rambling, but it is clear to me that all aspects of X predate Windows. Windows 93 copied the keyboard navigation from the CDE desktop environment, which had been in development for several years before that (and was based somewhat on the Macintosh, and on existing X standards).
The name was obviously chosen because at the time (about 1990?) "kool" computers used something called "X".
In reality this is not a worry. They only have the rights to the old version of the code. Surely you have enhanced it some at the same time you decided to make it proprietary!
Display PostScript was an attempt by Adobe to add PostScript to X. It could only draw into a window, you needed to use Xlib to create the window. This was purchased by NeXT and the X part was thrown away and replaced with some simple PostScript calls to create windows to make the NeXT windowing system.
NeWS had an enourmousely simpler and faster method of compressing PostScript into a data stream that pretty much involved reserving some bytes to mean the most common postscript keywords and to introduce arrays of floating point numbers that were imbedded in the data stream. DPS required a compiler that produced machine-specific data structures that also appeared to be highly specific to their PostScript interpreter, I feel this was an infinitely worse design.
NeWS also used PostScript to advantage to control non-drawing things. For instance the shape of a window was controlled by a PostScript path and the position (and rotation!) by a PostScript transformation. Original DPS had none of this, requiring ugly Xlib stuff, and NeXTStep only had simple "create a rectangular window and return it's id" calls that did not integrate so well.
NeWS was enormously better than DPS and anything else out there and it was a shame Sun blew it by trying to charge for it.
I do agree that downloading widgets was NeWS's main defect. It made communication between app and server very difficult and the only programs that really worked were entirely written in PostScript to avoid this communication. But other than this mistake, the unified single interface to create windows, draw *advanced* graphics, and manage events with easy string-based interface was far ahead of anything that has been invented since.
You could make the claim that XRender is really the new X12. Of course you could also make that claim for most of the "extensions".
In some ways this was very nice. It certainly required the fewest possible operations to copy something, and did not require any key assignments. Technically it is exactly the same as drag & drop (which everybody ooh's and aah's over for some reason...) but with the advantage that you could rearrange windows before you "dropped" (ie no need for Mac "spring loaded folders" or any other hacks).
It has losing points that people are aware of: any selection anywhere destroys the clipboard, making *replacement* of text impossible without planning ahead and requiring extra mouse clicks. It also required you to point the mouse even if the cursor was already at the correct location for the paste (some programs made middle click only do the paste and not the click because of this, resulting in inconsistent behavior).
The Motif people did figure out the correct way to emulate Windows/Mac was to have a second buffer called the CLIPBOARD. This is obvious if you think about middle mouse as drag & drop, there is no reason that dragging data should change the clipboard! Fortunately X already had support for an arbitrary number of such buffers due to some bogus and best-forgotten ideas about "secondary selection" and so on so it was easy to do this.
However all other toolkits were concerned about interoperability between them and older programs that did not understand CLIPBOARD. So they tended to just use the SELECTION for Ctrl+C/Ctrl+V. This confused Windows users no end because selection of text still changed the clipboard, and made Ctrl+C be a no-op in most cases.
Motif died for very good reasons, but since it understood clipboard, this is why you hear complaints that you cannot cut/paste from Netscape into other programs. Middle-mouse has always worked, though.
Fortunately in the last year GTK decided to switch to the Motif model of CLIPBOARD. It sounds like the next version of Qt (and thus KDE) also does this. I personally have fixed my own software to obey this.
Unlike common perception the programs on X do not all use incompatable cut & paste, though. They all agree on the initial design. It is the attempts to emulate an outside design, with no standards, that they disagree on. If Windows added middle-mouse paste today you can be certain that years from now there would be many programs that still "can't cut and paste correctly" on that platform, too!
I truly believe that if Sun had open-sourced a reference implementation of NeWS back in 1985 that right now it would be Scott McNealy on the government witness stand right now and everybody as SlashDot would call them $un. This is because Sun would be in control of the NeWS standard and could propose and release any enhancements to it before anybody else. They could also close-source it, or close-source the enhancements (like people worry about MSoft doing with .net), if they wanted. But to do any of this it had to be accepted, and it was not going to be accepted when it cost vast amounts of money and there was another thing (X) that, while obviousy 100 times crappier, was free (well $115 for a tape of the source code).
You are assumming "open source" == "free". The actual question is whether this assumption is true or not (and, despite claims to the contrary here on SlashDot, I think it is possible that this assumption is true).
If you assumme this is true, a further question is whether some non-free product can somehow be linked to a free product so that the company makes money. Broadcast TV seems to indicate that vast sums of money can be made this way, but it is not clear if any such setup can be done for source code. Except for zealots on SlashDot, most people are asking if this is possible.
However you worded the question as though you assummed "open source"=="free" is a true statement. That has not been proven.
How? By putting a real "watermark" on the data. This watermark is not to prevent copying, and in fact it must have absolutely no effect on any consumer device. They then have an easy automated test they can do to data they find on the internet, and detect people selling or otherwise distributing copyrighted works, and go after them with the law. Once the illegal data has been detected humans can look at it and easily determine and prove that it is copyrighted, there is no need for the watermark's techniques to be revealed in court.
Unfortunately they are going to insist on blowing it by trying to avoid the need for law by making consumer devices recognize the watermark and trying to avoid copying that way. The problem with this is that it provides hackers with a trivial test to see if the watermark is there and allows them to remove it!
They could try both, but they shoud realize that if the hacker is encouraged to mess with the data due to the copy-prevention watermark, it is quite likely they will accidentally remove the other watermark, or they will detect the other watermark during their attempts to remove the copy-protection one (since it is likely the technologies will be tied together).
The people running the MPAA, etc. are idiots. They are sabotaging their own ability to stop pirates, and pissing off the consumers at the same time with difficult-to-use and overpriced equipment. Unfortunately there seems to be no way to change their mind because they have no knowledge of technology.
I have been meaning to look at the source code, I do think the kde people would be receptive to changes (I have also written a window manager of my own flwm, so I think I can do this).
One difficulty with both major window managers is the "what does this mouse button do" type of controls. These are not user friendly, allow you to set it to an infinite number of useless settings, and often do not allow you to set it to behave as wanted. I would prefer a few checkmarks to control the major unknowns about window management:
Click-to-type or point-to-type (for point to type just use sloppy focus, the others serve no reason).
Click in contents raises window.
Timeout to raise focused window (works in click-to-type as well as point-to-type).
Dragging or resizing a window (using the title bar or window border) raises it.
In my opinion these are the only things that need changes. What each mouse button does can be fixed by the window manager or intelligently figured out from the above settings.