I actually think all the information should be moved to the "data" of a file, if at all possible. This means the date, owner, permissions, etc, are all embedded in a common format of parsable text at the start of the file. Even the file name would be imbedded.
The problem is that this introduces all kinds of back-compatability problems in that any file format that cannot have an arbitrary-length comment imbedded within the first 4 characters or so would have no attributes or name (it could be opened by using the correct index into the directory).
There are also obvious security problems with a system where anybody can change the owner and permissions of a file. Permissions would have to be an "and" of those in the file and of all parent directories leading to it.
I think the ResierFS has talked about things like this. The problem they are having with their "many tiny files" design is that the required file attributes is far larger than the size of the files themselves.
An intermediate form is to have such a system, but have all "back compatable" files be directories. Inside this directory is a "name", "data", "permission", "date", etc.
Can anybody translate this into english? I can't figure out if it is VA Linux or GoldmanSachsMorganStanly or CS First Boston, or some unnamed third party, that is being accused of doing something wrong. Though it does sound like it is the underwriters, not VA Linux.
Good question if SlashDot is showing a bias. If MicroSoft happened to do some deal with another company and that other company did something illegal that only benefited that company (ie it did not help MicroSoft) would that story get posted here?
I remember there being a Windows clone window manager for Linux that duplicated the Windows 98 desktop down to the pixels including the Windows logo on the "start" button. It was a variation of FVWM98. Running the correct applications and the GUI was indistinguishable from Windows unless the user tried to change the menu items.
There are also plenty of themes that copy MicroSoft's, including the default appearance of KDE, and also the default appearance of most non-themed toolkits such as FLTK, FOX, and JX.
Yet MicroSoft did not threaten anybody over this!
We are all damn lucky the meglomaniac who is in charge is Bill Gates. Just imaging Steve Jobs in that position! (or Scott McNealy, for that matter...)
I think adding attributes to files is a mistake. This is because it does not match the way a user thinks of objects. If you have a car, you can tell it is a car by looking at it, not because it has a tag next to it that says "car". If you give the car to a friend, he can also tell it is a car, even though he does not get the tag.
The solution is to analyze the contents of the objects. Like the Unix "file" command, which runs rules that examine the starting bytes of a file to determine what it is. The advantage here is that when the file is copied somewhere, it's "type" is preserved, because it is part of the data.
What is missing is a file system where accessing the first 100 or so bytes of a file is as quick as reading that file's name, so that we could display the type as quickly as the current filename or attribute based hacks. Does ReiserFS or anything do this?
There should be a command line program to do exactly what "open" does in Explorer, or clicking a file in KDE, and we should require GUI's to exec this program so that all the GUI's agree on this system.
Re: If you can drag a lasso around the old fruit (sorted by date via the sort bar, one click)
Take a good look at exactly what "Sorted by date via the sort bar" implies. You idiot, if that was possible it would also be trivial to do that with a CLI-program that deletes by date. In fact the command could be reused with no brain power at all, while the GUI would require you to keep clicking on the correct date (unless the GUI had a field that said "date to delete before", but if you think a usable GUI would provide that and all the billions of other possible reusable commands you are really mistaken).
An awful lot of attacks on command lines make this same mistake: that the GUI computer magically has information that the CLI computer cannot access. The most common example is "I can click on the document in the GUI and it opens". This requires the computer to know a lot of information, like "what program to run when this file is identified and how to tell that program about it". This information is not magically there just because it has a GUI. If the computer knows it there is no reason a CLI program cannot do it, for instance a shell should be able to let you "type a file name in and it opens it".
What is true is that the developers of the new Linux GUI are making the same crappy mistakes as Windoze, in that they are not improving the CLI at the same time. Why doesn't KDE provide a "launch" command that takes a list of arguments and does exactly the same thing as the user clicking on those icons?
Nothing is preventing it. The correct Win32 api is called GDI and is well documented in older Windows programming books. Newer books do not talk about it because MicroSoft is very interested in stopping any such portable libraries and running MFC everywhere, but since they need to run older programs the interface remains.
It is so similar in capabilities to Xlib that I really am suprised that fewer toolkits are not ported. A large number of calls have 1:1 correspondence. The biggest problem is that their event model sucks, while Xlib's fonts suck, requiring a portable kit to use the worst of each.
I think the fear is of the opposite scenario: MS Linux runs anything written for Linux, but all MS software for Linux fails to work on anything other than MS Linux.
IMHO, size_t is an unfortunate mistake. C should define int and pointers and differences between pointers as all being the same size and losslessly convertable between each other.
Basically C is full of assumptions that an integer can store the difference between pointers. You can change all the arguments that you know are "sizes" to size_t, but you will eventually find code that takes this and calls functions (like math functions) where it is perfectly legit to pass an integer and you don't want to change those to size_t, so you end up with impossible-to-remove type conflicts. Size_t is also causing all kinds of portability problems when trying to go between platforms that make it the same or different than int, or that don't define it, for instance I have to type in a prototype for the missing snprintf function a lot and it is different on every machine.
The problem is of course huge amounts of code that assumme int==32 bits. C should have defined some syntax to say exactly how many bits a variable has, perhaps "int var:32", much like a bitfield (the compiler is not required to support all possible sizes, only 8,16,32,sizeof(int)*8 and can round smaller sizes up and can produce an error if larger than the largest is requested).
Unfortunately that did not happen and we are in the mess we are now with all these typedefs and the inability to do clean pointer arithmetic.
Like you said the human retina has logarithmic response, thus you want a monitor where the mapping of the numbers put into the display buffer to the output light levels is logarithmic as well. If you don't, you are not allocating the numbers in the most efficient way possible.
The steps are not Mach banding. Mach banding is the eye/brain detecting non-continuous first derivatives in a scene and making the appear to be an "edge" (since they probably are a corner in a real-world scene).
I am talking about non-continuous levels themselves (ie not the derivative). The human eye can detect these obviously, but if the two levels are close enough together it is very hard. Ideally all the steps in the gray ramp (255 of them for an 8-bit display) should be equally hard to see. This requires a logarithimic mapping from the integers to the light levels.
The reason the display on this monitor and the real world would look "identical" is that the mapping from the real-world light levels to the numbers stored in the image file is not linear either, instead it is the inverse of the monitor.
I am well aware that the human response is logarithmic and the monitor is exponential plus a constant, and that it is impossible to make these curves match exactly. However they match far better than a straight line!
Now that it appears you cannot use the KDE environment without the KDE window manager, I would really like to see some simple fixes to the window manager. They copied some of the most annoying bugs off of Windoze and it would really help if these were fixed:
If double-click is going to maximize the window, please wait until the second click is released, and don't accept it as a double click if the mouse is moved more than a trivial amount since the second mouse-down. This is NUMBER 1 ANNOYING BEHAVIOR of the Windoze and KDE interface! PLEASE FIX IT! The reason is that if you click a window to the top and then decide to drag it, the push to drag it maximizes the window.
There is no way to configure it so that you can move the window with the left mouse button without raising it, yet allow you to click the left button and raise the window. This behavior is common in most X window managers and is really good.
Please set the default so that clicking in a window's contents does not raise it! This very annoying behavior of Windoze makes it impossible to make multi-window interfaces that are usable (and results in bastardizations like "MDI" and tiled windows). If this default was changed I think we would see some innovative user interfaces come up for KDE that we won't see on Windoze. Although this can be set, as a software developer I would really like to see the default changed so that I can assumme this in my GUI design.
But you don't want to change the DAC converters, because adjusting the monitor to be "linear" would spread the samples at the dark end out so much that the steps between them would be easily visible, while compressing the samples at the white end so close together that thye cannot be distinguished, thus wasting a lot of your intensity resolution up there.
An unadjusted monitor, through fortunate circumstances, very closely matches the non-linear response of the human eye.
There has been a long and sad history of people thinking the monitor has to be linear to be "correct", espeically in the Mac area (where they built-in a gamma correction in the software of about 1.7) and in SGI's which were often set to corrections of 2.5 or more. This was all wrong and we are finally getting away from it.
You are completely mistaken. Small font resolutions are much more readable with antialaising.
Obvious example is to look at text broadcast on the TV verses the text displayed on the screen by your VCR or cable box. It should be obvious that you can read the TV text at sizes that are far smaller than the box will attempt. This is because the box is not antialiased, while text used by the stations is (especially if it is a video image of a printed piece of text).
I also don't know what AutoCAD is talking about. Antialiased lines are far easier to see than aliased ones, especially if there are many almost-parallel ones at angles slightly off horizontal and vertical. Antialising of thin lines has been done for 25 years in top-of-the-line CAD workstations, despite the extreme (for then) computation overhead. Take a look at any old graphics book.
ClearType is a form of antialiasing. In an idealized form the centers of the red, green, and blue filters are offset to match the centers of the colored lcds. In addition an "error diffusion" pass is done to alter this result so that the output does not have any color bias (the XFree86 code does not seem to be doing this, resulting in the blue letters, but the MicroSoft sample was rather simple-minded in that their error diffusion oscillated without damping all the way to the right of the image resulting in a pattern in the clear area).
ClearType is actually a clever idea, but it is not a complex idea. The best ideas often are.
Hey: A CRT version of ClearType could be done if there was a percise way to set where the colored phosphers are in relation to the pixels, too. Perhaps a program could be used which displayed patterns and the user adjusted knobs to make those patterns as brightly colored as possible and this was used to figure the phospher position and pitch. This idea is (C)2000 ME and may not be used in commercial software by companies whose name starts with 'M'.
Your O2 did not do antialiasing. Perhaps you had a better monitor, or perhaps a better font? The very small bitmap fonts on Irix were pretty good, but they can easily be copied to another X server.
But why the hell can't they fix the existing Xlib calls to do antialiasing!
Certainly, add new and intelligent interfaces to draw text. But there is no excuse for not changing the existing interface to make it's output as nice as possible. Without that, all existing X programs will still produce ugly text.
And I don't give a s**t about back compatability. I know it won't color in the exact same pixels, but anybody who wrote a program that relied on that is an idiot anyway! I also don't care about this working on non-TrueColor visuals, those should have been eliminated long ago as well.
Besides coming out with antialiased text SIX YEARS AGO, MicroSoft modified their existing code so older programs got antialiased text. The fact that XFree86 seems incapable of doing the same thing is an insult to the entire Linux industry!
Almost everything contains traces of elements like uranium. Is this coal dust really a better source than if the bad guys just dug up their own dirt, or if they processed the coal on purpose to extract uranium rather than burn it to produce electricity? I have to say this claim that it assists in building weapons to be rather dubious and I wonder if the nuclear proponents are grasping at straws because a rather useful argument they used to have may have ended:
What was true is that the trace amounts of uranium and other elements, when multiplied by the huge quantaties of coal burned, and with the rather efficient method of spewing it into the atmosphere that we used to use, produced far more radiation than most plausable nuclear power plant accidents. Environmental activists are notoriously bad at weighing relative risks! Unfortunately it sounds to me that modern pollution-control may have cut the ash so much that this rather good argument is no longer true. That old radiation is now collected at the plant in the ash, where it is no longer threating people (or not any more than the spent fuel at a nuke plant, anyway).
From your description it sounds like nuke defenders, instead of giving up on this argument, have mutated it into something that, honestly, I find a little hard to buy.
It should be obvious by now that the vast majority of creators of web pages do not want document formatting, they want precise descriptions of the image. The standards organizations have to realize this, and realize that any document formatter will be bastardized by the users and the implementors (like MicroSoft and Netscape) to make it into a layout language.
If HTML had simply had a "go to pixel x,y" we would not be in this horrid mess of incompatable browsers and be in constant fear of MicroSoft screwing the world by changing their browser. Yes the purists would have cringed at such a command, but the masses would have rejoiced!
If I could design it from scratch, the language understood by the browser would be have had commands like this:
Push a rectangle. A rectangle is specified with dimensions that can be in pixels, or in percentages of the enclosing rectangle's size, or relative to the bottom of the current text. When the page starts the rectangle is equal to the browser window.
Pop back to the previous rectangle, leaving the text position below it.
Ascii (or UTF-8 text now) is formatted into the width of the current rectangle (if too big it will go out the bottom). There are no special characters so quoting is never needed. Paragraph breaks are indicated by ^J followed by another ^J or whitespace. There are imbedded commands but they are introduced with control characters, perhaps ^[command^].
Commands to change the font by name (browser is free to substitute another font), set the size
(given as pixel line spacing), color, etc.
Simple graphics, like rectangles and polygons, filled with solid color or tiled images, and clipped to the current rectangle.
Images exactly the same as HTML does them (this is the only thing they got right!)
A command to include the contents of another document here.
If this had been done browsers would probably be small programs, about as hard to write as IRC clients, and there would be hundreds of them.
For an X Client there is a bunch of Xlib calls that draw fonts and they could easily draw antialiased, without changing any API at all. Yes it would require a TrueColor visual and only the copy transfer function would work (any other combination would give you 1-bit fonts), but this if implemented would be immediately useful by almost all X programs.
Windows did not have antialiased text at first either, you know. They successfully added it so that programs using the old calls could draw the antialiased text. They had exactly the same limitations I propose for X, ie it does not work for non-true-color modes and does not work for binary functions other than copy.
The fact that the interface to the font server would have to change is not an excuse. The font server is an internal api as far as the majority of applications are concerned! Besides the X server could interface to old font servers by asking for the fonts 4 times bigger and doing down-rez antialiasing.
The real problem is complete laziness and a paranoia far worse than MicroSoft about back compatability from the X Consortium.
The amount of light produced on the screen is not equal to the number placed into the screen buffer multiplied by some constant. Instead it is a power, or "gamma" function, a reasonable estimate is that the light produced is equal to pow(v,2) where v is the number in the buffer scaled to the 0-1 range.
If your antialiased calculation is that a pixel is 50% filled (a =.5), the simple but wrong answer for the output pixel is.5*f+.5*b (where f is the color of the letter you are drawing and b is the color that is already there). But say f=1 and b=0, the result is.5, which is not half as bright as f, but instead only about 25% as bright.
The correct result should be about.71, which is the pixel value that is halfway in brightness between 0 and 1.
An easy way to do this is to calculate an alpha value instead of.5 of.71, and then use the normal linear compositing rule. This will result in perfect white on black text. However if you use it to draw black on white you will get.29 in the pixel, which is more wrong than the.5 the simple rule produces (the correct answer should again be.71). It appears this is the solution being done here (except he calculated the alpha for black on white), this can be seen by the rather bad appearance of the reverse-video text.
The correct solution is to composite an output value that is pow(pow(f*a,g)+pow(b*(1-a),g),1/g) where g is the alpha value. This is computationally ridiculous so some kind of approximation must be used, though I'm not sure what yet.
Your claim about the coal releasing more radiation sounds quite plausible (though I have only heard this for coal-generated electricity, by your own claim PV cells would only release 3% as much radiation this way).
But I don't understand the "nuclear proliferation danger". I doubt the coal exaust is really that much use for making nuclear weapons!
Don't make yourself look more like an idiot than you already have!
The ozone "hole" is really a "hole" in that there is a very steep gradient "edge" to it, this gradient in density is enormously steeper than the gradient inside the hole. Are you also going to claim that there is not such things as warm and cold fronts and that air temprature is uniformally distributed as well?
Although environmentalists may be too extreme at times, it always seems to me that when it gets to scientific arguments, the environmentalists seem to quote real science (plus a lot of extraneous emotion). When anti-environmentalists like you try to quote science it always seems to be pseudo-science and made-up facts. Sorry, but this does not help your position with people who used to be in the middle on this, like me (I used to think environmentalists were complete whackos).
Excellent idea! The need is different from the normal need of a "watermark". It is ok if it is trivial to remove the watermark or change it to another watermark, but it should be impossible to fake the watermark from a device you don't control.
How the hell did you know what "folder" to click?
I guess it was intuitive, huh?
However, font support on Linux sucks. Trying to argue otherwise is pointless and idiotic. I should be able to put a font in a directory and have it be immediately usable on my screen and printer (like Windoze except without the reboot).
You should return to your original arguments, which made a lot of sense, you have allowed the Linux zealots to get you into a rather inane arguemnt about a very obscure area (counting fonts) where Linux obviously wins.
In my experience it is better to draw the rectangles than to make up a widget-level interface. The widget interface will end up *more complicated* and slower than the drawing interface. Drawing is quite well understood and we can be reasonably certain that a well-designed set of drawing functions covers everything anybody will want to draw. I don't think that is possible for a widget interface.
This was part of the design of NeWS, incidentally, but it is where I thought NeWS failed. NeWS was a great drawing model, all postscript, and it was a joy to write widgets in NeWS that ran on the server, since I had access to a powerful "rectangle-level" graphics interface. NeWS totally failed to provide a usable interface between the client program and these widgets, however, the result was that NeWS programs tended to be entirely written in PostScript on the server.
In general I am very scared of widget-level interfaces. They are going to be complex and bug prone and will lock out the possibilities to innovate new GUI designs.
I believe that if X had been made with a widget-level interface it would look like Athena and have been locked at that design for a decade. Yes it would be "configurable" but that would be limited to setting it to reverse-video, since that was the only configuration option back then. The fact that X, with all it's flaws, is able to match much more recent designs of GUI is a testament to the power of a low-level interface.
Despite the sentiment here, the client/server model is NOT a problem, in fact it is quite good, even for local display. Properly done client/server with a stream-like interface will VASTLY reduce context switches and is far easier to implement on multiprocessors. It should also be much easier to migrate the work to hardware accelerators. Though faster due to the reduced context switches, the client/server model does have a problem with latency, but in my opinion latency is an additive element in speed, while context switches are multiplicative, and thus as machines get faster the pain of latency is reduced far faster than the context switches. Also latency is unavoidable in network applications anyway so we should design systems to allow it.
Where X blows is the horrid rendering model. Your comments are very accurate, the current "solution" that all those graphics libraries use is to render a bitmap locally and send it. This completely destroys the whole point of the client/server and makes the sent data so huge that direct rendering makes a difference and is becoming a design requirement. It is insane that we are forced to link gigantic graphics libraries that are bigger than all that stuff would be if put in the server and that if you run 10 programs you have 10 copies of those libraries and their data, rather than one in the server!
Another problem is the huge number of badly designed X calls that require synchronous communication to the server. This replaces the "zero" context switches needed by a well-designed client/server with *two* context switches, reducing the performance to that of older NT, and reducing it to half that of NT when the graphics are in the kernel. Actually it is far worse than NT as there are *more* synchronous things than Windows has, despite the fact that the designers of original Windows did not lose anything for syncrhonous calls.
I wish people would stop trying to chuck the client/server and attack the real problem: We should scrap the entire rendering system and the current gc's and make a new type of X gc:
The GC would contain the display connection and current window and would be per-thread implied, like OpenGL GC's, so that drawing functions do not need any arguments other than the values actually used by that function.
Scrap colormaps and visuals! When you create a window, you can request any color (as a 32 or 64 bit number) and the server can figure out how to do it on the display. To run old xlib programs there would be an emulator, it would claim the X server provides a single truecolor visual.
Merge OpenGL completely. You should be able to draw OpenGL into any window, in sync with any new drawing operations.
Simple support of multiple buffers and overlays through the same gc. You can set the gc to draw into any layer, and there is a command to flush all changes from one layer into another. The back buffers are created when first used.
Real fonts support. Fonts are selected by a simple text string, ie "Helvetica". Arbitrary 2-d transformations of the font (perhaps 3d perspective too) and antialiasing, and UTF-8 support as the *ONLY* encoding it accepts, and every character ALWAYS draws no matter what the current font is (there is a 16x16 bitmap of every unicode character that is used if the font does not provide anything else).
Easy, programmer-friendly image support. Draw a image of 8-bit/color or 16-bit/color with RGB or RGBA through an arbitrary 3-D transoform. Alpha compositing with correct gamma math above whatever is already in the window.
And tons more. This is not particularily hard to implement. It's not easy either. But we really really need it.
Slashdot Mirror
The problem is that this introduces all kinds of back-compatability problems in that any file format that cannot have an arbitrary-length comment imbedded within the first 4 characters or so would have no attributes or name (it could be opened by using the correct index into the directory).
There are also obvious security problems with a system where anybody can change the owner and permissions of a file. Permissions would have to be an "and" of those in the file and of all parent directories leading to it.
I think the ResierFS has talked about things like this. The problem they are having with their "many tiny files" design is that the required file attributes is far larger than the size of the files themselves.
An intermediate form is to have such a system, but have all "back compatable" files be directories. Inside this directory is a "name", "data", "permission", "date", etc.
Good question if SlashDot is showing a bias. If MicroSoft happened to do some deal with another company and that other company did something illegal that only benefited that company (ie it did not help MicroSoft) would that story get posted here?
There are also plenty of themes that copy MicroSoft's, including the default appearance of KDE, and also the default appearance of most non-themed toolkits such as FLTK, FOX, and JX.
Yet MicroSoft did not threaten anybody over this!
We are all damn lucky the meglomaniac who is in charge is Bill Gates. Just imaging Steve Jobs in that position! (or Scott McNealy, for that matter...)
The solution is to analyze the contents of the objects. Like the Unix "file" command, which runs rules that examine the starting bytes of a file to determine what it is. The advantage here is that when the file is copied somewhere, it's "type" is preserved, because it is part of the data.
What is missing is a file system where accessing the first 100 or so bytes of a file is as quick as reading that file's name, so that we could display the type as quickly as the current filename or attribute based hacks. Does ReiserFS or anything do this?
There should be a command line program to do exactly what "open" does in Explorer, or clicking a file in KDE, and we should require GUI's to exec this program so that all the GUI's agree on this system.
Take a good look at exactly what "Sorted by date via the sort bar" implies. You idiot, if that was possible it would also be trivial to do that with a CLI-program that deletes by date. In fact the command could be reused with no brain power at all, while the GUI would require you to keep clicking on the correct date (unless the GUI had a field that said "date to delete before", but if you think a usable GUI would provide that and all the billions of other possible reusable commands you are really mistaken).
An awful lot of attacks on command lines make this same mistake: that the GUI computer magically has information that the CLI computer cannot access. The most common example is "I can click on the document in the GUI and it opens". This requires the computer to know a lot of information, like "what program to run when this file is identified and how to tell that program about it". This information is not magically there just because it has a GUI. If the computer knows it there is no reason a CLI program cannot do it, for instance a shell should be able to let you "type a file name in and it opens it".
What is true is that the developers of the new Linux GUI are making the same crappy mistakes as Windoze, in that they are not improving the CLI at the same time. Why doesn't KDE provide a "launch" command that takes a list of arguments and does exactly the same thing as the user clicking on those icons?
It is so similar in capabilities to Xlib that I really am suprised that fewer toolkits are not ported. A large number of calls have 1:1 correspondence. The biggest problem is that their event model sucks, while Xlib's fonts suck, requiring a portable kit to use the worst of each.
I think the fear is of the opposite scenario: MS Linux runs anything written for Linux, but all MS software for Linux fails to work on anything other than MS Linux.
Basically C is full of assumptions that an integer can store the difference between pointers. You can change all the arguments that you know are "sizes" to size_t, but you will eventually find code that takes this and calls functions (like math functions) where it is perfectly legit to pass an integer and you don't want to change those to size_t, so you end up with impossible-to-remove type conflicts. Size_t is also causing all kinds of portability problems when trying to go between platforms that make it the same or different than int, or that don't define it, for instance I have to type in a prototype for the missing snprintf function a lot and it is different on every machine.
The problem is of course huge amounts of code that assumme int==32 bits. C should have defined some syntax to say exactly how many bits a variable has, perhaps "int var:32", much like a bitfield (the compiler is not required to support all possible sizes, only 8,16,32,sizeof(int)*8 and can round smaller sizes up and can produce an error if larger than the largest is requested).
Unfortunately that did not happen and we are in the mess we are now with all these typedefs and the inability to do clean pointer arithmetic.
The steps are not Mach banding. Mach banding is the eye/brain detecting non-continuous first derivatives in a scene and making the appear to be an "edge" (since they probably are a corner in a real-world scene).
I am talking about non-continuous levels themselves (ie not the derivative). The human eye can detect these obviously, but if the two levels are close enough together it is very hard. Ideally all the steps in the gray ramp (255 of them for an 8-bit display) should be equally hard to see. This requires a logarithimic mapping from the integers to the light levels.
The reason the display on this monitor and the real world would look "identical" is that the mapping from the real-world light levels to the numbers stored in the image file is not linear either, instead it is the inverse of the monitor.
I am well aware that the human response is logarithmic and the monitor is exponential plus a constant, and that it is impossible to make these curves match exactly. However they match far better than a straight line!
If double-click is going to maximize the window, please wait until the second click is released, and don't accept it as a double click if the mouse is moved more than a trivial amount since the second mouse-down. This is NUMBER 1 ANNOYING BEHAVIOR of the Windoze and KDE interface! PLEASE FIX IT! The reason is that if you click a window to the top and then decide to drag it, the push to drag it maximizes the window.
There is no way to configure it so that you can move the window with the left mouse button without raising it, yet allow you to click the left button and raise the window. This behavior is common in most X window managers and is really good.
Please set the default so that clicking in a window's contents does not raise it! This very annoying behavior of Windoze makes it impossible to make multi-window interfaces that are usable (and results in bastardizations like "MDI" and tiled windows). If this default was changed I think we would see some innovative user interfaces come up for KDE that we won't see on Windoze. Although this can be set, as a software developer I would really like to see the default changed so that I can assumme this in my GUI design.
Thanks, thats all for now.
But you don't want to change the DAC converters, because adjusting the monitor to be "linear" would spread the samples at the dark end out so much that the steps between them would be easily visible, while compressing the samples at the white end so close together that thye cannot be distinguished, thus wasting a lot of your intensity resolution up there.
An unadjusted monitor, through fortunate circumstances, very closely matches the non-linear response of the human eye.
There has been a long and sad history of people thinking the monitor has to be linear to be "correct", espeically in the Mac area (where they built-in a gamma correction in the software of about 1.7) and in SGI's which were often set to corrections of 2.5 or more. This was all wrong and we are finally getting away from it.
Obvious example is to look at text broadcast on the TV verses the text displayed on the screen by your VCR or cable box. It should be obvious that you can read the TV text at sizes that are far smaller than the box will attempt. This is because the box is not antialiased, while text used by the stations is (especially if it is a video image of a printed piece of text).
I also don't know what AutoCAD is talking about. Antialiased lines are far easier to see than aliased ones, especially if there are many almost-parallel ones at angles slightly off horizontal and vertical. Antialising of thin lines has been done for 25 years in top-of-the-line CAD workstations, despite the extreme (for then) computation overhead. Take a look at any old graphics book.
ClearType is actually a clever idea, but it is not a complex idea. The best ideas often are.
Hey: A CRT version of ClearType could be done if there was a percise way to set where the colored phosphers are in relation to the pixels, too. Perhaps a program could be used which displayed patterns and the user adjusted knobs to make those patterns as brightly colored as possible and this was used to figure the phospher position and pitch. This idea is (C)2000 ME and may not be used in commercial software by companies whose name starts with 'M'.
Your O2 did not do antialiasing. Perhaps you had a better monitor, or perhaps a better font? The very small bitmap fonts on Irix were pretty good, but they can easily be copied to another X server.
But why the hell can't they fix the existing Xlib calls to do antialiasing!
Certainly, add new and intelligent interfaces to draw text. But there is no excuse for not changing the existing interface to make it's output as nice as possible. Without that, all existing X programs will still produce ugly text.
And I don't give a s**t about back compatability. I know it won't color in the exact same pixels, but anybody who wrote a program that relied on that is an idiot anyway! I also don't care about this working on non-TrueColor visuals, those should have been eliminated long ago as well.
Besides coming out with antialiased text SIX YEARS AGO, MicroSoft modified their existing code so older programs got antialiased text. The fact that XFree86 seems incapable of doing the same thing is an insult to the entire Linux industry!
What was true is that the trace amounts of uranium and other elements, when multiplied by the huge quantaties of coal burned, and with the rather efficient method of spewing it into the atmosphere that we used to use, produced far more radiation than most plausable nuclear power plant accidents. Environmental activists are notoriously bad at weighing relative risks! Unfortunately it sounds to me that modern pollution-control may have cut the ash so much that this rather good argument is no longer true. That old radiation is now collected at the plant in the ash, where it is no longer threating people (or not any more than the spent fuel at a nuke plant, anyway).
From your description it sounds like nuke defenders, instead of giving up on this argument, have mutated it into something that, honestly, I find a little hard to buy.
If HTML had simply had a "go to pixel x,y" we would not be in this horrid mess of incompatable browsers and be in constant fear of MicroSoft screwing the world by changing their browser. Yes the purists would have cringed at such a command, but the masses would have rejoiced!
If I could design it from scratch, the language understood by the browser would be have had commands like this:
If this had been done browsers would probably be small programs, about as hard to write as IRC clients, and there would be hundreds of them.
For an X Client there is a bunch of Xlib calls that draw fonts and they could easily draw antialiased, without changing any API at all. Yes it would require a TrueColor visual and only the copy transfer function would work (any other combination would give you 1-bit fonts), but this if implemented would be immediately useful by almost all X programs.
Windows did not have antialiased text at first either, you know. They successfully added it so that programs using the old calls could draw the antialiased text. They had exactly the same limitations I propose for X, ie it does not work for non-true-color modes and does not work for binary functions other than copy.
The fact that the interface to the font server would have to change is not an excuse. The font server is an internal api as far as the majority of applications are concerned! Besides the X server could interface to old font servers by asking for the fonts 4 times bigger and doing down-rez antialiasing.
The real problem is complete laziness and a paranoia far worse than MicroSoft about back compatability from the X Consortium.
If your antialiased calculation is that a pixel is 50% filled (a = .5), the simple but wrong answer for the output pixel is .5*f+.5*b (where f is the color of the letter you are drawing and b is the color that is already there). But say f=1 and b=0, the result is .5, which is not half as bright as f, but instead only about 25% as bright.
The correct result should be about .71, which is the pixel value that is halfway in brightness between 0 and 1.
An easy way to do this is to calculate an alpha value instead of .5 of .71, and then use the normal linear compositing rule. This will result in perfect white on black text. However if you use it to draw black on white you will get .29 in the pixel, which is more wrong than the .5 the simple rule produces (the correct answer should again be .71). It appears this is the solution being done here (except he calculated the alpha for black on white), this can be seen by the rather bad appearance of the reverse-video text.
The correct solution is to composite an output value that is pow(pow(f*a,g)+pow(b*(1-a),g),1/g) where g is the alpha value. This is computationally ridiculous so some kind of approximation must be used, though I'm not sure what yet.
But I don't understand the "nuclear proliferation danger". I doubt the coal exaust is really that much use for making nuclear weapons!
The ozone "hole" is really a "hole" in that there is a very steep gradient "edge" to it, this gradient in density is enormously steeper than the gradient inside the hole. Are you also going to claim that there is not such things as warm and cold fronts and that air temprature is uniformally distributed as well?
Although environmentalists may be too extreme at times, it always seems to me that when it gets to scientific arguments, the environmentalists seem to quote real science (plus a lot of extraneous emotion). When anti-environmentalists like you try to quote science it always seems to be pseudo-science and made-up facts. Sorry, but this does not help your position with people who used to be in the middle on this, like me (I used to think environmentalists were complete whackos).
Excellent idea! The need is different from the normal need of a "watermark". It is ok if it is trivial to remove the watermark or change it to another watermark, but it should be impossible to fake the watermark from a device you don't control.
However, font support on Linux sucks. Trying to argue otherwise is pointless and idiotic. I should be able to put a font in a directory and have it be immediately usable on my screen and printer (like Windoze except without the reboot).
You should return to your original arguments, which made a lot of sense, you have allowed the Linux zealots to get you into a rather inane arguemnt about a very obscure area (counting fonts) where Linux obviously wins.
This was part of the design of NeWS, incidentally, but it is where I thought NeWS failed. NeWS was a great drawing model, all postscript, and it was a joy to write widgets in NeWS that ran on the server, since I had access to a powerful "rectangle-level" graphics interface. NeWS totally failed to provide a usable interface between the client program and these widgets, however, the result was that NeWS programs tended to be entirely written in PostScript on the server.
In general I am very scared of widget-level interfaces. They are going to be complex and bug prone and will lock out the possibilities to innovate new GUI designs.
I believe that if X had been made with a widget-level interface it would look like Athena and have been locked at that design for a decade. Yes it would be "configurable" but that would be limited to setting it to reverse-video, since that was the only configuration option back then. The fact that X, with all it's flaws, is able to match much more recent designs of GUI is a testament to the power of a low-level interface.
Despite the sentiment here, the client/server model is NOT a problem, in fact it is quite good, even for local display. Properly done client/server with a stream-like interface will VASTLY reduce context switches and is far easier to implement on multiprocessors. It should also be much easier to migrate the work to hardware accelerators. Though faster due to the reduced context switches, the client/server model does have a problem with latency, but in my opinion latency is an additive element in speed, while context switches are multiplicative, and thus as machines get faster the pain of latency is reduced far faster than the context switches. Also latency is unavoidable in network applications anyway so we should design systems to allow it.
Where X blows is the horrid rendering model. Your comments are very accurate, the current "solution" that all those graphics libraries use is to render a bitmap locally and send it. This completely destroys the whole point of the client/server and makes the sent data so huge that direct rendering makes a difference and is becoming a design requirement. It is insane that we are forced to link gigantic graphics libraries that are bigger than all that stuff would be if put in the server and that if you run 10 programs you have 10 copies of those libraries and their data, rather than one in the server!
Another problem is the huge number of badly designed X calls that require synchronous communication to the server. This replaces the "zero" context switches needed by a well-designed client/server with *two* context switches, reducing the performance to that of older NT, and reducing it to half that of NT when the graphics are in the kernel. Actually it is far worse than NT as there are *more* synchronous things than Windows has, despite the fact that the designers of original Windows did not lose anything for syncrhonous calls.
I wish people would stop trying to chuck the client/server and attack the real problem: We should scrap the entire rendering system and the current gc's and make a new type of X gc:
The GC would contain the display connection and current window and would be per-thread implied, like OpenGL GC's, so that drawing functions do not need any arguments other than the values actually used by that function.
Scrap colormaps and visuals! When you create a window, you can request any color (as a 32 or 64 bit number) and the server can figure out how to do it on the display. To run old xlib programs there would be an emulator, it would claim the X server provides a single truecolor visual.
Merge OpenGL completely. You should be able to draw OpenGL into any window, in sync with any new drawing operations.
Simple support of multiple buffers and overlays through the same gc. You can set the gc to draw into any layer, and there is a command to flush all changes from one layer into another. The back buffers are created when first used.
Real fonts support. Fonts are selected by a simple text string, ie "Helvetica". Arbitrary 2-d transformations of the font (perhaps 3d perspective too) and antialiasing, and UTF-8 support as the *ONLY* encoding it accepts, and every character ALWAYS draws no matter what the current font is (there is a 16x16 bitmap of every unicode character that is used if the font does not provide anything else).
Easy, programmer-friendly image support. Draw a image of 8-bit/color or 16-bit/color with RGB or RGBA through an arbitrary 3-D transoform. Alpha compositing with correct gamma math above whatever is already in the window.
And tons more. This is not particularily hard to implement. It's not easy either. But we really really need it.