However in *most* cases the metadata can be extracted from the file. I recommend it be put into comment fields whenever possible. Otherwise tack it on the end or wrap the file if possible. Notice also that some metadata (preview images, cache) by *definition* are extracted from the file!
"extended attributes" should be used for a "cache" of this extracted data, but a program should recreate it if at all possible from the data.
The problem with attributes is that they cannot be read/written by normal tools and are thus often lost when files are transferred or edited. When they are not lost you require seperate tools to alter them. It also appears that for best performance they should not be stored in the same filesystem, for instance you may prefer the "attributes" of web pages (ie the cached copy, things like "favicons", etc) to be stored on your machine rather than on the web server.
For these reasons I strongly recommend that all "attributes" be considered more like a cache of extracted data. It would still be very useful for there to be low-level support of this in the system, however. Since user-level programs would set the attributes you could set them arbitrary, but the programs should be designed with caching and extracting them, rather than generating them.
The problem is not that 24 or 32 bit hardware is needed, but that a "true color" visual is needed. A "true color visual" is where it is possible to calculate a resulting color quickly and easily from the value of a pixel in the frame buffer (which could be as small as 6 bits or 1), an incoming pixel (which can be much larger like 16 bits per component, or smaller, than the pixels in the frame buffer), and an incoming alpha value.
What this definately means is that it cannot happen in color-mapped mode, because the calculation produces an arbitrary resulting color. Finding the nearest match in a colormap is slow, and if the assignment of the color map is under program control and thus can change, is actually impossible.
It also means that the output is poor (but not impossible) on displays with few bits per pixel. A cheap algorithim would look posterized, or have really bad dithering (like Windows on an 8-bit card). Good algorithims (random error diffusion) look ok but require so much computing power that you might as well pay for more memory per pixel. Because of this most people say that it requires N bits per pixel, but that is not really true.
The problem with X is that it's horrid interface meant that huge numbers of programs are written to require colormapped mode. Fortunately almost all Linux software has been rewritten to avoid this, but Sun still has this as a problem. Windows did not have this problem because they added a "draw in this color" interface that worked even when you were in colormapped mode, so most programs work without it (some programs did not for the same reason X programs did not, but on X programs were *forced* to require colormaps).
I have written toolkits that are portable to Windows and I must point out that your claims that "policy" is why Windows look nicer are wrong. I can make a program that completely ignores every GUI guideline and "consistency" requirement in the world, and it will still look nicer on Windows, because I can do a call that take a single string name of a font to GDI32, and then I can draw any string, and I am absolutely 100% guaranteed that the user will see nicely-rendered letters. Nice fonts have absolutely ZERO to do with that "consistent user interface" and "policy" and everything to do with the developers scrapping some back compatability and writing actualy hard code to do the job.
Unfortunately the fact that X sucks is being used to force very bad ideas (such as toolkits in the server) that would condemn Linux to being totally unable to compete with any platform that allows innovation in the user interface.
What X needs is easy to program for and advanced rendering capabilities. I can draw a damn button, what I can't draw right now is UTF-8 text. Programmers using "consistency" as an excuse to force people to use their own implementation of a button, rather than getting to work on hard stuff like rendering, are causing more damage to Linux (and Windows, too!) than anything.
With an X-Box you can play your one game forever if you think a new game is too expensive. With the printer, once you use up the cartridge you either must buy a new one or stop using the printer at all.
This movie is, I belive, the first use of computer graphics to represent a real object in a movie (rather than to represent a computer display or other non-real-world thing).
Not that it works, but I think that was the intention of all the modelines in the XFree86 setup file. Supposedly you pick one by the resoulution and "everything else is calculated" by the fact that the other numbers were filled in in that sample modeline. In reality this is pretty much what Windows is doing internally. Problems are that not all desired combinations are listed (?), that a lot of ancient and useless combinations are listed, that a combination is listed more than once (ie with some options in that extra data changed but with no indication why, Windows would probably delete the less-used one of these), and that when listing all the options the programs show all the extra numbers, scaring users and making them think they have to correctly pick all of them.
Followed by: I don't have to worry about configuring my video card to run the right resolution and refresh rate becuase windows is so supported all I have to do is right click my desktop and change a couple slider bars.
Doesn't sound like a single-click to me...
Seriously though, are there really any Windows games left that require you to set the resolution before they work? Can't they either set it themselves, or (gasp!) work in the current resolution?
(I suppose the manufacturer could perform some kind of irreversable alteration to the chip when the clock speed is assigned, but AFAIK nobody does that yet)
My mistake, I thought what you describe here was already being done.
Doesn't the CPU ID indicate what clock speed it is supposed to be running at? It would seem that anybody in the know could see that the reseller is cheating by examining this and comparing it to the running speed. Anybody who does not know how to do that could probably be fooled by phony Windows "about your computer" messages or by just being told that the machine is faster than it really is.
There is a difference between *forcing* the speed to be a certain speed and *checking* if the speed is wrong.
Things might be clearer if you realized that X "cut & paste" is really drag & drop, with the advantage that you can move windows around between the drag and drop.
It could be a win to put structured graphical elements on the server, for instance "raised box with this centered text". This would I think produce the exact same reduction in communication as what you are suggesting.
However I am quite dubious about actual "widgets" with user interface rules, based on work I did with NeWS. The complexity of communicating with such widgets in NeWS basically meant that the only practical programs worked 100% on the NeWS end, and that a client program could do little other than wait for the user to close the window. This was because any useful program had to call dozens of methods on the NeWS widgets to get them to behave as desired. If you look at NeWS objects (or any of the current toolkit objects) it seems that 90% or more of the interface is to modify the behavior. Qt for instance lists dozens of "signals" for a button, and many methods of setting shortcuts or deciding when exactly the signals get done. Comparativly little is needed to actually set the text and color and icon on the button.
Some operations become extremely difficult if the widget interface is not designed for it. For instance shortcuts that depend on the current state of the program or are read from a user-configuration file that may be updated at any time, are a total pita with any current toolkit due to the need to immediatly update all possible shortcuts with any change. However they would be rather trivial to handle if the program could defer thinking about the shortcut until the moment it is typed. Now Fresco designers could say "oh that's a good idea, we will add that ability" but now you have made the interface to buttons more complicated with these new calls. IMHO this sort of work leads VERY fast to enormous bloat and complex bugs where programmers begin to use these complex interfaces in ways that were unexpected by the designers.
I also see this as locking us into user interface designs that will become obsolete. The concept of a menu that controls a simple hierarchy could be outdated soon, already there is lots of interest in user-reprogrammable menus. Now you may have this in Fresco, but if it was done five years ago you would not have it and until you added it nobody could. I also expect window borders and titles to disappear if we can get the idea of them out of the server/window manager and into programs. And I'm sure many other changes can happen that I have not thought of.
I may not have been too clear on that. What I want is shared "contexts" and obvious things like the current window, color, and clipping. I don't mean that 2D stuff must actually draw on a plane in 3D space, or obey lighting. For instance if you call the drawtext("text",x,y) call I would expect x,y to be transformed by the current 3D transform to a 2D location (and perhaps a Z value for z-buffering if it is enabled) but the letters themselves would be drawn in 2D, their scale and orientation would have been selected in another interface that picked the font. The image-drawing function I suggested would do the 3D projection but would not do any lighting, it's purpose is to make it easy to use the 3D hardware for transformations so images will scale and rotate quickly.
The biggest thing you said that almost everybody else suggesting alternatives ignores is that an Xlib compatability library is needed. I agree with your assessment that window managers, screensavers, and panels would need to be replaced, but this would allow everybody to run the majority old programs on the new system.
This compatability layer is much more important than anything else, including drivers. Right now it is *impossible* to work with any alternative to X on Linux.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected. First of all it makes it absolutely impossible to write such an emulation layer. Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED. Just take a look at how much code and X messages is used in Qt or GTK to talk to the windowing system, and try to estimate how many times less code would be needed to draw the borders and handle the resizing themselves.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Yes the window manager needs to go
on
XFree86 Politics
·
· Score: 2, Insightful
But it does not have to go into the application. It can go into the toolkits, just like all the buttons and menus and text fields and everything else. This will allow window managers to change and evolve, and would also allow lots of useful things like workable windows with no title bars or borders (the app would be allowed to select other areas to move/resize the window).
Lots of whiners will immediatly say "but that will allow window borders to be (horrors) INCONSISTENT and that will CONFUSE the poor stupid users!". To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
If you are right about what Keith wants to do, this sounds very good. I have heard though he is not too hot on merging the 2D and 3D drawing code and I have not been thrilled with how the interface to XRender looks (it is MUCH more complex than I think necessary).
I would like to see a (per thread) OpenGL rendering context that exists the moment you create a window (or perhaps before) and a simple call "draw_in_window(xid)" that changes it to draw into that window, with NO preliminary setup of that window. Then I would like to see him add to OpenGL the missing things: support for arbitrary clip regions, real support for anti-aliased UTF-8 fonts, reliable transparency in the current color, and a simple 1-call "draw this image in my memory through the current 3D transform as a big flat 3D rectangle" call, so that all programs can use OpenGL for all drawing. This new drawing interface would be simple and even *fun* to program, rather than the pain we have now, and would allow graphics display libraries to be toolkit-independent.
The old X interface would be emulated ATOP this (not "beside" it like the stupid idea that killed NeWS), and can be made quite easy by making it report only a single 32-bit TrueColor visual, no matter what the hardware does, and ignoring most of the bitblt modes. Old programs would get anti-aliased fonts and double-buffering and many other advantages this way.
The vast majority of extensions are not used by any programs, and except for GLx and Xft none made after about 1988 are used. There is a serious problem with how they are implemented in that in virtually every case, the program must do an elaborate test to see if the extension is installed, and then write two versions of the code, one that uses the extension, and one that emulates it. This is way too much work for most developers and the time is better spent making that emulation as fast as possible and ignoring the extension.
This is true of every X extension I have ever seen except Xft. Xft, amazingly enough, is a client-side library that detects itself if the extension is missing from the server and emulates it, so the poor programmer does not have to write two versions of their code! The result is obvious: huge numbers of programs and toolkits support Xft already.
This amazing breakthrough (emulating extensions for you) is almost always done by Microsoft in DirectX, and the fact that the X developers cannot do it should be considered a shameful and embarrassing defeat.
The other problem with extensions is they rarely, if ever, simplify things. The interface to SHM is much more complex than the already agonizingly bad interface to XPutImage. The interface to XRender requires much larger and complex and confusing context objects than normal X drawing. Selecting a font in Xft still cannot be done with a single "name of the font" string. There is no reason why all this complex added code cannot make the programmer's life easier, rather than harder!
if software package X was put on the market with this new MS license, then developers improved X and bundled or linked to GPLed Y and Z packages and redistributed the improved version under GPL, then nobody, including MS, would have the ability to even further modify and sell the new and improved X (not lined to Y and Z) software without giving out the source
Though technically true, you seem to be wording this in a way to make it sound worse than it is. The important part of your wording is in bold, but a cursory reading of this would not see that portion of the wording and would read the normal FUD about the GPL that somehow just somebody using the code causes the original author to lose their copyright.
In the real world, and not in Microsoft's and your straw-man fantasy, nobody actually "improves" X in this way. Programmers who are really fixing things like to see their changes incorporated into the real thing, and will license their changes as required. Otherwise they would keep patching over and over and over, which is insane. If you don't believe this, check what lots of GPL-zealots do when they fix BSD or LGPL code: they don't fork, they instead license to match.
As for patents, the GPL does not force you to give up patents. Such a requirement without a signed contract is not legal. You are certainly allowed to copyright an expression of an idea that is patented. I think the GPL license goes into it's own FUD in an attempt to obfuscate this fact.
Actually "piracy" is a long-established term for distributing copies of a copyrighted work without permission, though usually associated with a person doing this for profit.
People also talk about "ticket scalpers" and that term is probably more recent, but nobody seems confused about what they do.
MicroSoft has given out plenty of sample code pretty much public-domain for much of their history. So if this is sample code this is a HUGE restricition on their previous behavior. However I get the impression that this code is actual implementations and in general the restrictions are less than before when this code was secret.
Under the MS license you can redistribute software either in source/binary or binary form only, i.e. you are not obligated to include source code, also allowing you to effectively sell commercial software. If they allowed the GPL compatibility they would lose this feature of the license.
Wrong! They would not lose anything. What they have done is make it impossible to make a program using both their code and GPL code. Allowing this would have absolutely no effect on what you can do with a program that does not use GPL code.
If the requirement to return changes has been removed, then the no-GPL restriction is just Billy being a baby. Before it required that anything you wrote with their code was free for use by MicroSoft (since you had to send them the changes and you were not allowed to claim any copyright over them, because if you could claim copyright then you could also claim the GPL because the GPL is less restrictive than plain copyright.)
With this new version you still can't coypright your code, but you can keep it secret, so MicroSoft gets no gain at all but instead just makes people mad (some of who would be happy to work cooperatively with them to make better products). This is quite childish on their part.
The "will" is the same "will" that is being talked about when a physics professor says "these particles want to go into the lowest-energy state". It's called *anamorpizing* an inanimate object. Show some imagination.
Slashdot Mirror
Drag & drop from the finder into the terminal types the full path name into the terminal. This is quite uesful for "integrating" them.
"extended attributes" should be used for a "cache" of this extracted data, but a program should recreate it if at all possible from the data.
The problem with attributes is that they cannot be read/written by normal tools and are thus often lost when files are transferred or edited. When they are not lost you require seperate tools to alter them. It also appears that for best performance they should not be stored in the same filesystem, for instance you may prefer the "attributes" of web pages (ie the cached copy, things like "favicons", etc) to be stored on your machine rather than on the web server.
For these reasons I strongly recommend that all "attributes" be considered more like a cache of extracted data. It would still be very useful for there to be low-level support of this in the system, however. Since user-level programs would set the attributes you could set them arbitrary, but the programs should be designed with caching and extracting them, rather than generating them.
What this definately means is that it cannot happen in color-mapped mode, because the calculation produces an arbitrary resulting color. Finding the nearest match in a colormap is slow, and if the assignment of the color map is under program control and thus can change, is actually impossible.
It also means that the output is poor (but not impossible) on displays with few bits per pixel. A cheap algorithim would look posterized, or have really bad dithering (like Windows on an 8-bit card). Good algorithims (random error diffusion) look ok but require so much computing power that you might as well pay for more memory per pixel. Because of this most people say that it requires N bits per pixel, but that is not really true.
The problem with X is that it's horrid interface meant that huge numbers of programs are written to require colormapped mode. Fortunately almost all Linux software has been rewritten to avoid this, but Sun still has this as a problem. Windows did not have this problem because they added a "draw in this color" interface that worked even when you were in colormapped mode, so most programs work without it (some programs did not for the same reason X programs did not, but on X programs were *forced* to require colormaps).
Unfortunately the fact that X sucks is being used to force very bad ideas (such as toolkits in the server) that would condemn Linux to being totally unable to compete with any platform that allows innovation in the user interface.
What X needs is easy to program for and advanced rendering capabilities. I can draw a damn button, what I can't draw right now is UTF-8 text. Programmers using "consistency" as an excuse to force people to use their own implementation of a button, rather than getting to work on hard stuff like rendering, are causing more damage to Linux (and Windows, too!) than anything.
Because the *application* crashed.
With an X-Box you can play your one game forever if you think a new game is too expensive. With the printer, once you use up the cartridge you either must buy a new one or stop using the printer at all.
This movie is, I belive, the first use of computer graphics to represent a real object in a movie (rather than to represent a computer display or other non-real-world thing).
Not that it works, but I think that was the intention of all the modelines in the XFree86 setup file. Supposedly you pick one by the resoulution and "everything else is calculated" by the fact that the other numbers were filled in in that sample modeline. In reality this is pretty much what Windows is doing internally. Problems are that not all desired combinations are listed (?), that a lot of ancient and useless combinations are listed, that a combination is listed more than once (ie with some options in that extra data changed but with no indication why, Windows would probably delete the less-used one of these), and that when listing all the options the programs show all the extra numbers, scaring users and making them think they have to correctly pick all of them.
Followed by: I don't have to worry about configuring my video card to run the right resolution and refresh rate becuase windows is so supported all I have to do is right click my desktop and change a couple slider bars.
Doesn't sound like a single-click to me...
Seriously though, are there really any Windows games left that require you to set the resolution before they work? Can't they either set it themselves, or (gasp!) work in the current resolution?
bool click_on_link(const char* link) {
if (i_understand(link)) {
return open(link);
} else {
return fork_and_execp("open", link);
}
}
Then there can be lots of versions of the "start" program, and you can even replace it if you don't like it's behavior.
One very annoying fact is that it is easier to do this on Windows and OS/X than on Linux. Very very bad.
My mistake, I thought what you describe here was already being done.
There is a difference between *forcing* the speed to be a certain speed and *checking* if the speed is wrong.
Things might be clearer if you realized that X "cut & paste" is really drag & drop, with the advantage that you can move windows around between the drag and drop.
However I am quite dubious about actual "widgets" with user interface rules, based on work I did with NeWS. The complexity of communicating with such widgets in NeWS basically meant that the only practical programs worked 100% on the NeWS end, and that a client program could do little other than wait for the user to close the window. This was because any useful program had to call dozens of methods on the NeWS widgets to get them to behave as desired. If you look at NeWS objects (or any of the current toolkit objects) it seems that 90% or more of the interface is to modify the behavior. Qt for instance lists dozens of "signals" for a button, and many methods of setting shortcuts or deciding when exactly the signals get done. Comparativly little is needed to actually set the text and color and icon on the button.
Some operations become extremely difficult if the widget interface is not designed for it. For instance shortcuts that depend on the current state of the program or are read from a user-configuration file that may be updated at any time, are a total pita with any current toolkit due to the need to immediatly update all possible shortcuts with any change. However they would be rather trivial to handle if the program could defer thinking about the shortcut until the moment it is typed. Now Fresco designers could say "oh that's a good idea, we will add that ability" but now you have made the interface to buttons more complicated with these new calls. IMHO this sort of work leads VERY fast to enormous bloat and complex bugs where programmers begin to use these complex interfaces in ways that were unexpected by the designers.
I also see this as locking us into user interface designs that will become obsolete. The concept of a menu that controls a simple hierarchy could be outdated soon, already there is lots of interest in user-reprogrammable menus. Now you may have this in Fresco, but if it was done five years ago you would not have it and until you added it nobody could. I also expect window borders and titles to disappear if we can get the idea of them out of the server/window manager and into programs. And I'm sure many other changes can happen that I have not thought of.
I may not have been too clear on that. What I want is shared "contexts" and obvious things like the current window, color, and clipping. I don't mean that 2D stuff must actually draw on a plane in 3D space, or obey lighting. For instance if you call the drawtext("text",x,y) call I would expect x,y to be transformed by the current 3D transform to a 2D location (and perhaps a Z value for z-buffering if it is enabled) but the letters themselves would be drawn in 2D, their scale and orientation would have been selected in another interface that picked the font. The image-drawing function I suggested would do the 3D projection but would not do any lighting, it's purpose is to make it easy to use the 3D hardware for transformations so images will scale and rotate quickly.
This compatability layer is much more important than anything else, including drivers. Right now it is *impossible* to work with any alternative to X on Linux.
Several responses mention Fresco. However I feel that any attempt to put "toolkit" into the server is a bad idea, and will be rejected. First of all it makes it absolutely impossible to write such an emulation layer. Also despite claims to the contrary, it actually *increases* the amount of communication Why? Because widgets quickly grow complicated with many many cofiguration options and it gets COMPLICATED. Just take a look at how much code and X messages is used in Qt or GTK to talk to the windowing system, and try to estimate how many times less code would be needed to draw the borders and handle the resizing themselves.
Also Fresco lacks any attempt at the Xlib emulation library, so it is not going to be a viable replacement.
Lots of whiners will immediatly say "but that will allow window borders to be (horrors) INCONSISTENT and that will CONFUSE the poor stupid users!". To that ancient "inconsistent" argument I say it is totall BS and I challenge anybody to find a real user who is "confused" by the difference between a KDE and Gnome button or menu.
I would like to see a (per thread) OpenGL rendering context that exists the moment you create a window (or perhaps before) and a simple call "draw_in_window(xid)" that changes it to draw into that window, with NO preliminary setup of that window. Then I would like to see him add to OpenGL the missing things: support for arbitrary clip regions, real support for anti-aliased UTF-8 fonts, reliable transparency in the current color, and a simple 1-call "draw this image in my memory through the current 3D transform as a big flat 3D rectangle" call, so that all programs can use OpenGL for all drawing. This new drawing interface would be simple and even *fun* to program, rather than the pain we have now, and would allow graphics display libraries to be toolkit-independent.
The old X interface would be emulated ATOP this (not "beside" it like the stupid idea that killed NeWS), and can be made quite easy by making it report only a single 32-bit TrueColor visual, no matter what the hardware does, and ignoring most of the bitblt modes. Old programs would get anti-aliased fonts and double-buffering and many other advantages this way.
This is true of every X extension I have ever seen except Xft. Xft, amazingly enough, is a client-side library that detects itself if the extension is missing from the server and emulates it, so the poor programmer does not have to write two versions of their code! The result is obvious: huge numbers of programs and toolkits support Xft already.
This amazing breakthrough (emulating extensions for you) is almost always done by Microsoft in DirectX, and the fact that the X developers cannot do it should be considered a shameful and embarrassing defeat.
The other problem with extensions is they rarely, if ever, simplify things. The interface to SHM is much more complex than the already agonizingly bad interface to XPutImage. The interface to XRender requires much larger and complex and confusing context objects than normal X drawing. Selecting a font in Xft still cannot be done with a single "name of the font" string. There is no reason why all this complex added code cannot make the programmer's life easier, rather than harder!
Though technically true, you seem to be wording this in a way to make it sound worse than it is. The important part of your wording is in bold, but a cursory reading of this would not see that portion of the wording and would read the normal FUD about the GPL that somehow just somebody using the code causes the original author to lose their copyright.
In the real world, and not in Microsoft's and your straw-man fantasy, nobody actually "improves" X in this way. Programmers who are really fixing things like to see their changes incorporated into the real thing, and will license their changes as required. Otherwise they would keep patching over and over and over, which is insane. If you don't believe this, check what lots of GPL-zealots do when they fix BSD or LGPL code: they don't fork, they instead license to match.
As for patents, the GPL does not force you to give up patents. Such a requirement without a signed contract is not legal. You are certainly allowed to copyright an expression of an idea that is patented. I think the GPL license goes into it's own FUD in an attempt to obfuscate this fact.
People also talk about "ticket scalpers" and that term is probably more recent, but nobody seems confused about what they do.
MicroSoft has given out plenty of sample code pretty much public-domain for much of their history. So if this is sample code this is a HUGE restricition on their previous behavior. However I get the impression that this code is actual implementations and in general the restrictions are less than before when this code was secret.
Wrong! They would not lose anything. What they have done is make it impossible to make a program using both their code and GPL code. Allowing this would have absolutely no effect on what you can do with a program that does not use GPL code.
If the requirement to return changes has been removed, then the no-GPL restriction is just Billy being a baby. Before it required that anything you wrote with their code was free for use by MicroSoft (since you had to send them the changes and you were not allowed to claim any copyright over them, because if you could claim copyright then you could also claim the GPL because the GPL is less restrictive than plain copyright.)
With this new version you still can't coypright your code, but you can keep it secret, so MicroSoft gets no gain at all but instead just makes people mad (some of who would be happy to work cooperatively with them to make better products). This is quite childish on their part.
If you say "readline" you lose.
The "will" is the same "will" that is being talked about when a physics professor says "these particles want to go into the lowest-energy state". It's called *anamorpizing* an inanimate object. Show some imagination.