Case insensitivity is *not* a good idea. There are many other mappings between "similar" names (ie misspellings, different numbers of spaces or different punctuations, same word in different languages). Saying that case makes no difference means you are supporting one such mapping, but not *all* such mappings, which is inconsistent. Differentiating files on the exact binary representation of their name is the only consistent thing to do, and is the only way to cleanly allow more powerful matching capabilities to be built atop the system (in the libraries, where this should be).
People do not type in names of existing files by hand, or perhaps you have not seen any GUI's from the past ten years. They do not need case insensitive file names, in fact most would like it if they could make many files with identical names!
Allowing the disk to store more information (case preserving) than it is allowed to use is also a source of enormous bugs. What are we going to do with Unicode when systems, due to bugs, disagree about case mapping those 65000 characters?
Please, get rid of case-insensitve now, while we still can.
Of course they have to have backwards compatability, I'm not complaining about that. I don't mean get rid of the backslashes, I just mean change the documentation and gui of new programs to encourage the use of forward slashes. This would not break any programs, they have supported both types of slashes in the system interface since DOS 2.0.
They don't go out of their way to not be interoperable, it simply is that interoperability never crosses their minds when creating software.
Wish this were true, but it does not explain numererous gratuitious incompatabilities. Why for instance do they insist on showing & using backslash in all file names in all interfaces, even though their internal interfaces (no doubt under the influence of Unix users) accept forward slash. It has nothing to do with user friendliness: the forward slash is easier to type and would be consistent with http names. The original need for the backslash (back compatabilitye with DOS 1.0's COMMAND.COM) is long gone.
Another example is that they have refused to add real symbolic links, in fact deleting a somewhat sybolic-link like facility (the assign command in DOS 5). This would actually be very useful to users by allowing them to pretend multiple disks are a single one, and to installation programs that want to reuse files. I also suspect it is trivial to implement. However it would also allow the Unix filename space to be simulated by setting these links, allowing easy back & forth porting, and the fact that they don't want this is the only plausible reason why they have never done it.
This has got to be a joke. Visitors to SlashDot: this is not a typical SlashDot user and this should not be taken as an example of how people here think.
I am quite happy that the average idiot can now create a web page with pictures of their dog. And I actually think I'm pretty good at computers but I have no idea what UDP is or what port HTTP uses.
I see nothing wrong with how IE works (except it sounds like they check both MIME and extensions, and that the extensions take precedence over MIME, this should be swapped).
All data interpreters should be able to "barf" and complain that the code is unrecognized, without crashing and with only a few bytes read.
1. Try the interpreter for the "MIME type". Skip over "interpreters" like "x-octet-stream" which do nothing useful. If it barfs, continue.
2. Try the interpreter determined from the file name, or from any other random garbage in the data headers being sent over http.
3. Try every interpreter, one after another, trying to find one that does not barf.
4. Offer to save the file to disk as binary. Believe me, the file is not text!
This sort of solution would allow us to read pages no matter how badly set up the http server is. It has always annoyed me that I cannot put a.gz or.bz2 file on most servers and be able to download it with NetScape, though IE downloads it just fine!
I would agree with most people here that MicroSoft is not stupid enough to allow undeclared variables, and that this means uninitialized variables are automatically initialized.
However it seems there are cleaner methods of doing this. One simple one is to require an initialization value. I.e "int i" is an illegal statement, but "int i = 0" is legal.
Another alternative is to have compilation fail. Every C compiler I know of has the ability to warn about the use of an uninitialized variable.
I thought for a contract to be enforceable, there has to be an element of "consideration". The wording and spirit of the GPL doesn't seem to include any consideration, since it is a one-way process - the software author gives her code to the world providing they follow her wishes with regard to keeping the source open.
The part in bold is the "consideration". Software authors derive pleasure from having their software be visible and used, and this part of the contract increases that benefit to the author. Therefore the GPL does have "consideration".
I think he meant that HFS has the advantage that the file numbers are not reusued. Ie if you have a file number, you either will get the original file, or you will get an indication that the file has been deleted. You will not get some other file that reused the number.
When I started writing this I thought this was a good idea, but I realized that the Apple scheme lets you accidently delete the pointed-to data, and you cannot restore it in any way without fixing every link. Perhaps the file numbers can be reused if you create a file with the same name and location as the one that last used that file number?
This is very similar to Unix hard links, though. If there is a hard link, the file cannot get deleted, and thus cannot be replaced, so the hard link continues to point at the original data.
The Unix structure actually makes far more logical sense because it is symmetric. However it apparently is not the way human minds work, which is why we have symbolic links and hard links have pretty much been relegated to making file system operations atomic.
The Apple scheme actually sounds like a good compromise with the advantages of both hard and soft links. You can move the pointed-to data just like hard links, and you can delete it just like symbolic links.
Aren't file permissions stored with the inode on Unix? The existence of the fstat() call seems to indicate this. If so there would be no speed loss in making a secure open(inode) call. But I am ignorant of this area, so pardon me if I am wrong.
No, the NT "solution" is hardly that. Files created with the POSIX part cannot be seen by the Win32 part. This is of course inane but they did this on purpose so they could claim "posix compatability" while making it impossible to use Posix to write NT programs.
Making the files visible would introduce all the interoperability problems that OS/X is trying to solve.
However I'm not sure why the OS/X people did not refer to Linux more. Linux has been mounting NTFS and DOS disks for a long time and apparently have addressed and solved a lot of problems here.
I do think they should stop putting case-insensitivity into the file system. It is a sure source of bugs if you are preserving case (I know, having managed to make two files with different cases on NT, it is as bad as making a file with a '/' in it on Unix). Case insensitivity is not needed with modern filename-completion shells, and certainly are not needed for user-friendly interfaces where the user clicks on the file!
Sorry, apparently my statement was unclear. I was recommending the ".app" type directories (or ALBOD's as another letter called them). However I worked with these on the NeXT, and it seems like we need kernel (or libc) support for these:
In these examples "app" is one of these directories, and "part" is one of the many files or other app/normal directories, or links (including symbolic) inside it.
1. If a program does open(app) and then read() and writes the output to another file, the output file will act exactly like app did, ie it is also one of these directories. This was not true on NeXT and it sounds like it is not true on OS/X or any Unix, on these attempting to open the file either produces an error, or produces data that when copied does not reproduce the file (on my Irix machine it produces 4 zero bytes). Same thing for mmap(). Of course it should also work if you cp a directory, though that may turn off the stat directory bit, thus converting a directory to an "app".
2. A program can open("app/part") and get a working file that it can read or copy somewhere. It can try to open("app/nopart") (the name of a non-existent part) it will get a "no such file" error.
3. A program can readdir("app") and get a list of all the files inside it.
3. A program doing stat("app") will get an indicator of a normal file. This is so the majority of programs will make them look like a single file, which is what the user expects. In fact the only difference between normal directories and "app" is that normal directories have this bit set.
4. To determine if a random file really is one of these directories, you must readdir() it. Also it will be possible to determine it from the read() data, since this is a requirement so that cp will work.
My complaint was that this should be well-defined as a directory, there should NOT be a "data fork". Any data can be defined as being in a file inside this.
I don't know how this should be implemented. The raw read() data could be stored on existing file systems and the system (or libc) recognizes it and makes readdir() and open(app/part) work. Or the file system could recognize the data as it is written and build the hierarchy. Or a hybrid where the first readdir() causes the file system to convert the flat data. There are a lot of possibilities.
I would also get rid of the ".app" extension. Even without system support I see no reason why the command you type to the shell to run PhotoShop cannot be "PhotoShop/main" rather than "PhotoShop.app/PhotoShop" that it is now. With os support of course you would just type "PhotoShop".
When you open the file you should be able to read all the data. It is a lot easier for any program that open()'s a file to just skip the "metadata" if it only wants the "data". The Mac system makes it impossible to make simple programs that copy files and also provided a fertile breeding ground for viruses.
What is needed is perhaps "meta directories" which are directories that look like regular files to most programs, but if you open a subfile by name in them you get that subfile: ie you can open "foo" and read data, or you can open "foo/bar" and get a subsctream of data. The parent data would be the entire contents of all subdirectories, so that a brain-dead "cp" would reproduce the entire tree somewhere else.
This would not conflict with anything (because you have been unable to read() a directory in any modern Unix) and would be incredibly useful.
Of course Linux does not follow a formal spec. Nor does Windows, or BSD, or probably the system the NSA uses, or the SABRE airline system, or your bank or insurance company, or anything even remotely interesting.
A "spec" is just as complex, or more so, than the system it describes. Exactly how do mortal humans write a "spec" that does not itself have "bugs"?
In fact the source code is probably the most accurate "spec" around. At least we are guaranteed that the implementation matches...
I think the point was that it was a little map program, not an operating system. Both Windows and Linux come in equal-sized bloated boxes (an odd example of Linux being Windows-compatable!)
Looking in the computer store though it seems the real bad culprits are games. Those boxes are HUGE and weird dimensions so it is impossible to make a neat shelf, this is obviously on purpose so that each box can stick out.
The biggest non-game is certainly MicroSoft Office, it was about 6 inches thick. But other than the thickness it conformed to the 8.5x11 standard size.
I do agree with some other suggestions that they should slim these down to no thicker than a CD jewel case plus 2 sheets of cardstock. Still 8.5x11, it will still prevent shoplifting. Companies with extra bucks can pay the store to stick an example flat to the wall over the shelves for advertising purposes.
Re:Steep learning curve means easy to learn
on
Who's Afraid Of C++?
·
· Score: 1
It makes sense if the horizontal axis is "how good you are at it" and the vertical axis is "how much you know". To get to a certain amount of proficiency you have to climb a very steep curve of learning.
I think he means that the interface should not require a GUI. Ie. if the basic component architecture requires an xid or QtWidget* as one of the arguments, it is wrong.
This is an area where COM fails pretty badly. Win32 window id's are needed a lot for interfaces that don't need to draw anything to be useful. This is not a COM problem, but an object implementation problem (I personally don't see the problem with an architecture-specific solution like COM, it seems that it can be translated to a different architecture, while CORBA has to be translated for *EVERY* architecture).
Actually a rather poor example. I think that anything that can be presented as a file should have a file-like interface. So the editor can just open "/ftp/machine.bar.baz/subdir/file" and read/write it. Yes this will cause a large "component" to be linked in but it would be linked through the kernel.
The components are for where the interface is more object-specific, if I understand this correctly. You can send a message like "display your user interface in this x window id", which is meaningless for data files.
Your are confusing this with "mouse grab" which remains true only as long as the mouse is held down. Window managers (and actually every program) need this. But since the grab goes away when the mouse is released there is no problem with lock-up.
You may also be thinking about "passive grab" which is used by Window managers so they get the clicks that would normally go to a program. A bad WM can use this to stop a program from getting any clicks, but it is more obvious what is wrong (and is similar to the fact that a program can wedge X or any system like Windows by putting up a window that covers the screen and refusing to exit).
The problem is "active grab" which causes *all* mouse clicks (and keyboard) to go to a window. "Active grab" is used for exactly two things: to dismiss pop-up menus with a click anywhere on the screen, and for "snapshot" or "magnify" programs to indicate a place on the screen that is outside their control. I propose that active grab be cancelled when the mouse is released. This will not break the menu things (since the menu is dismissed). It will require the snapshot programs to have you click on the program again to restart (or maybe require you to hold down a shift key).
Yes we all know the Athena scrollbars are very very bad. They would be bad even if everybody used them and thus they were "consistent". Just because some authors are idiots does not provide a useful couterexample.
I want to see an example of a user that is confused because the borders on the buttons are different, or the font used inside them is different, or the color is different, or any of the few differences that exist between MODERN Windows/Mac/KDE/Gnome applications.
I don't believe these exist, and this stuff is being foisted on us by programmers who want to control things and are too lazy to do the hard part, which is to provide powerful graphics.
Believe me, it is trivial to draw a button or a pull-down menu, when compared to drawing an image with accurate dithering and arbitrary transformations. I wish all the time wasted making these built-in toolkits (by both commercial and free software writers) was spent doing the hard part.
Toolkits have their place, but there should be no reason there cannot be hundreds of them.
Actually I would rather see floating point support. Truncating the mantissa of 32-bit floats so they are 16 bits would actually be a much better use of 16 bits, allowing far higher resolution in the darker colors, where the resolution is needed.
An extra bit of resolution could be achieved by shifting away the sign bit before truncation. (negative colors are not needed).
Better dithering algorithims are much more important to getting a good representation than throwing more bits at it. The vast majority of popular image file formats are 8-bit only, so a good converter to 8 bits is more important than handling 16 bits. A 16-bit file is likely to be run through a bad 16->8 converter, resulting in a *worse* result than if Gimp produced 16 bits.
A png-like standard that saves the exponent with reasonable compression would allow "lossless" storage.
Having now read the docs, I don't like the sound of the "widgets". I would much rather that they concentrate on advanced graphics capabilites.
One reason X still works, despite problems, is that it did not have "widgets". If X had "widgets" we would right now be stuck using an interface that was designed in 1982 (it would probably look like Athena or XView). Actually, more likely, X would be long dead and obsolete.
The complaints about X all center on the graphics capabilities (or lack of them). These graphics capabilities also date back to 1982, but the interesting thing is that there really has not been as much advancement in that area, and that even old graphics can be used to emulate new graphics. I don't hear people complaining that X's problem is the lack of a native call to draw a button or a menu!
I personally feel Berlin should concentrate on their (admittedly awsome) graphics capabilities. "Widgets" should be display lists provided by the client program, and events should be sent directly to the client program. There should be no classes of widgets. "Themes" can be done in a graphics-oriented way (rather than widget-oriented), by having calls to do things like "draw a raised area" that a theme can replace the code for.
The designers should exercise some humility and not try to solve problems that the client software can solve itself.
I would also like some proof that "different looking widgets" somehow "confuse users". I think this is a giant piece of FUD being given to everybody by the toolkit-mongers.
Windows has "grab" as well, but they release it after any mouse click that is not in the window that did the "grab". I believe this could be added to existing X and not break any applications that use grab, since 99% of the time they are doing this just to see if the user is dismissing a menu by clicking outside (other things like snapshot programs can just re-grab after the click). Unless the program maps a window over the entire screen I would think this would fix X so that grabs do not wedge the system.
I think the reason the windows drag around smoother is that Windows can have the "server" (the system) lock a window to the mouse cursor. In X moving the cursor just sends an event to the program which must echo back a "move the window to here" event, by then the cursor has moved further.
The reason I believe this is that there *is* latency just like X when you first try to move a window, this would be the echo of the "lock the window to the cursor" command. You can also see obvious latency in the redrawing of the exposed windows. Also it seems to me that the windows often overshoot if you move them quickly, indicating latency for the "unlock the window" command (having the internals unlock on mouse release would be a reasonable fix).
This seems like a pretty good idea to add to X. If you have transparency/shapes to windows it also allows arbitrarily complex cursors.
X has another problem with "multiple visuals" (though this does not plague XFree86 on Linux, as only one visual is supported). On Irix at least, it changes the "visual" of the exposed window, changing it's color, before drawing the new pixels (even the background color), resulting in the horrid flashing that you get from X. I don't know the hardware limitations, but it seems that changing the "visual" of a pixel could be deferred until the pixel is actually drawn.
This does not have much impact on bandwidth use - all display changes still have to be sent by the client to the server, and these are more frequent by far than window-damage repaints.
Actually it should be faster: a client program can defer creating changes until there are no events pending from the server, which is the same method used by most toolkits use now to avoid latency problems. This means exactly the same amount of information is sent, if you assumme a display change is the same size as the instructions to draw a widget.
From the comments, Berlin is sounding much more interesting to me than before. I thought they were trying to shove another toolkit down our throats, which I do not want. Instead it is sounding like they are attacking the real (and difficult) problems of getting efficient graphics. Any idiot can make a button (I did), drawing scalable device-independent graphics is hard and useful work!
The normal antialiased example is not really fair. The "61 point lancos filter" sounds impressive, and it is (it is a 61-pixel wide filter with 31 positive numbers and 30 negatives and is a very accurate simulation of the infinitely-wide "sync" filter). Unfortunately it also strongly biased towards preserving frequency information, at an extreme it could consider representing a 1-pixel wide 1.0 line as n lines that sum to 1 with a 0 line between each of them. This can be very good for photographic information but fails a bit for high contrast fine detail, which text is probably an excellent example.
A better filter for text would be a cheapo box filter. The worst it can turn a 1-pixel black line into is two.5 lines that are adjacent. Adjusting for the screen gamma (their examples *do* do this) will make a much more "even" result than this fancy filter (and would be dozens of times faster). In particular the thin lines would all appear to be much closer to the same weight (it is also necessary that the original binary image have lines of even thickness).
The "cleartype" I think looks somewhat sharper because it uses this simpler filter. You can also see dithering artifacts all over the white area to the right, so I believe they are rendering at 3x width and then translating this to the rgb values of each pixel, but using something like error diffusion to keep the average total color rendered "gray". I think they should reset the error after some number of pixels of solid color because your eye will not see this:
RGBRGB.....RGBR
as more red than this:
RGBRGB.....RGB
This would get rid of the dithering artifacts on the right.
In any case it actually is an innovative idea. The truth about innovative ideas is that they seem quite obvious once somebody thinks of them. It also means that it is almost impossible to stop real "innovation" from being used by everybody, since just seeing the output provides enough information for the innovation to be recreated. In fact I would expect this to appear in lots of commercial and free products quite soon.
Re:And X still doesn't have anti-aliasing?
on
Cleartype In Depth
·
· Score: 2
I hope you mean a FONT protocol, not another damn "extension".
If anti-aliasing requires using different X calls (and thus does not cause existing programs to antialias) I will kill the first XF86 representative I see.
(To be realistic, I expect antialiasing to work if a truecolor visual is used and copy transfer function is in use.)
The only "extension" I want is to add a simple X call: XSetTheDamnFont("Name of font goes here", point_size); This should ALWAYS set the font no matter what garbage I put in the name, set it to a default font if not found. And I should be able to get italic if the string contains the word "italic" in it.
Slashdot Mirror
People do not type in names of existing files by hand, or perhaps you have not seen any GUI's from the past ten years. They do not need case insensitive file names, in fact most would like it if they could make many files with identical names!
Allowing the disk to store more information (case preserving) than it is allowed to use is also a source of enormous bugs. What are we going to do with Unicode when systems, due to bugs, disagree about case mapping those 65000 characters?
Please, get rid of case-insensitve now, while we still can.
Of course they have to have backwards compatability, I'm not complaining about that. I don't mean get rid of the backslashes, I just mean change the documentation and gui of new programs to encourage the use of forward slashes. This would not break any programs, they have supported both types of slashes in the system interface since DOS 2.0.
Wish this were true, but it does not explain numererous gratuitious incompatabilities. Why for instance do they insist on showing & using backslash in all file names in all interfaces, even though their internal interfaces (no doubt under the influence of Unix users) accept forward slash. It has nothing to do with user friendliness: the forward slash is easier to type and would be consistent with http names. The original need for the backslash (back compatabilitye with DOS 1.0's COMMAND.COM) is long gone.
Another example is that they have refused to add real symbolic links, in fact deleting a somewhat sybolic-link like facility (the assign command in DOS 5). This would actually be very useful to users by allowing them to pretend multiple disks are a single one, and to installation programs that want to reuse files. I also suspect it is trivial to implement. However it would also allow the Unix filename space to be simulated by setting these links, allowing easy back & forth porting, and the fact that they don't want this is the only plausible reason why they have never done it.
I am quite happy that the average idiot can now create a web page with pictures of their dog. And I actually think I'm pretty good at computers but I have no idea what UDP is or what port HTTP uses.
I see nothing wrong with how IE works (except it sounds like they check both MIME and extensions, and that the extensions take precedence over MIME, this should be swapped).
All data interpreters should be able to "barf" and complain that the code is unrecognized, without crashing and with only a few bytes read.
1. Try the interpreter for the "MIME type". Skip over "interpreters" like "x-octet-stream" which do nothing useful. If it barfs, continue.
2. Try the interpreter determined from the file name, or from any other random garbage in the data headers being sent over http.
3. Try every interpreter, one after another, trying to find one that does not barf.
4. Offer to save the file to disk as binary. Believe me, the file is not text!
This sort of solution would allow us to read pages no matter how badly set up the http server is. It has always annoyed me that I cannot put a .gz or .bz2 file on most servers and be able to download it with NetScape, though IE downloads it just fine!
However it seems there are cleaner methods of doing this. One simple one is to require an initialization value. I.e "int i" is an illegal statement, but "int i = 0" is legal.
Another alternative is to have compilation fail. Every C compiler I know of has the ability to warn about the use of an uninitialized variable.
The part in bold is the "consideration". Software authors derive pleasure from having their software be visible and used, and this part of the contract increases that benefit to the author. Therefore the GPL does have "consideration".
When I started writing this I thought this was a good idea, but I realized that the Apple scheme lets you accidently delete the pointed-to data, and you cannot restore it in any way without fixing every link. Perhaps the file numbers can be reused if you create a file with the same name and location as the one that last used that file number?
This is very similar to Unix hard links, though. If there is a hard link, the file cannot get deleted, and thus cannot be replaced, so the hard link continues to point at the original data.
The Unix structure actually makes far more logical sense because it is symmetric. However it apparently is not the way human minds work, which is why we have symbolic links and hard links have pretty much been relegated to making file system operations atomic.
The Apple scheme actually sounds like a good compromise with the advantages of both hard and soft links. You can move the pointed-to data just like hard links, and you can delete it just like symbolic links.
Aren't file permissions stored with the inode on Unix? The existence of the fstat() call seems to indicate this. If so there would be no speed loss in making a secure open(inode) call. But I am ignorant of this area, so pardon me if I am wrong.
Making the files visible would introduce all the interoperability problems that OS/X is trying to solve.
However I'm not sure why the OS/X people did not refer to Linux more. Linux has been mounting NTFS and DOS disks for a long time and apparently have addressed and solved a lot of problems here.
I do think they should stop putting case-insensitivity into the file system. It is a sure source of bugs if you are preserving case (I know, having managed to make two files with different cases on NT, it is as bad as making a file with a '/' in it on Unix). Case insensitivity is not needed with modern filename-completion shells, and certainly are not needed for user-friendly interfaces where the user clicks on the file!
In these examples "app" is one of these directories, and "part" is one of the many files or other app/normal directories, or links (including symbolic) inside it.
1. If a program does open(app) and then read() and writes the output to another file, the output file will act exactly like app did, ie it is also one of these directories. This was not true on NeXT and it sounds like it is not true on OS/X or any Unix, on these attempting to open the file either produces an error, or produces data that when copied does not reproduce the file (on my Irix machine it produces 4 zero bytes). Same thing for mmap(). Of course it should also work if you cp a directory, though that may turn off the stat directory bit, thus converting a directory to an "app".
2. A program can open("app/part") and get a working file that it can read or copy somewhere. It can try to open("app/nopart") (the name of a non-existent part) it will get a "no such file" error.
3. A program can readdir("app") and get a list of all the files inside it.
3. A program doing stat("app") will get an indicator of a normal file. This is so the majority of programs will make them look like a single file, which is what the user expects. In fact the only difference between normal directories and "app" is that normal directories have this bit set.
4. To determine if a random file really is one of these directories, you must readdir() it. Also it will be possible to determine it from the read() data, since this is a requirement so that cp will work.
My complaint was that this should be well-defined as a directory, there should NOT be a "data fork". Any data can be defined as being in a file inside this.
I don't know how this should be implemented. The raw read() data could be stored on existing file systems and the system (or libc) recognizes it and makes readdir() and open(app/part) work. Or the file system could recognize the data as it is written and build the hierarchy. Or a hybrid where the first readdir() causes the file system to convert the flat data. There are a lot of possibilities.
I would also get rid of the ".app" extension. Even without system support I see no reason why the command you type to the shell to run PhotoShop cannot be "PhotoShop/main" rather than "PhotoShop.app/PhotoShop" that it is now. With os support of course you would just type "PhotoShop".
When you open the file you should be able to read all the data. It is a lot easier for any program that open()'s a file to just skip the "metadata" if it only wants the "data". The Mac system makes it impossible to make simple programs that copy files and also provided a fertile breeding ground for viruses.
What is needed is perhaps "meta directories" which are directories that look like regular files to most programs, but if you open a subfile by name in them you get that subfile: ie you can open "foo" and read data, or you can open "foo/bar" and get a subsctream of data. The parent data would be the entire contents of all subdirectories, so that a brain-dead "cp" would reproduce the entire tree somewhere else.
This would not conflict with anything (because you have been unable to read() a directory in any modern Unix) and would be incredibly useful.
A "spec" is just as complex, or more so, than the system it describes. Exactly how do mortal humans write a "spec" that does not itself have "bugs"?
In fact the source code is probably the most accurate "spec" around. At least we are guaranteed that the implementation matches...
Looking in the computer store though it seems the real bad culprits are games. Those boxes are HUGE and weird dimensions so it is impossible to make a neat shelf, this is obviously on purpose so that each box can stick out.
The biggest non-game is certainly MicroSoft Office, it was about 6 inches thick. But other than the thickness it conformed to the 8.5x11 standard size.
I do agree with some other suggestions that they should slim these down to no thicker than a CD jewel case plus 2 sheets of cardstock. Still 8.5x11, it will still prevent shoplifting. Companies with extra bucks can pay the store to stick an example flat to the wall over the shelves for advertising purposes.
It makes sense if the horizontal axis is "how good you are at it" and the vertical axis is "how much you know". To get to a certain amount of proficiency you have to climb a very steep curve of learning.
This is an area where COM fails pretty badly. Win32 window id's are needed a lot for interfaces that don't need to draw anything to be useful. This is not a COM problem, but an object implementation problem (I personally don't see the problem with an architecture-specific solution like COM, it seems that it can be translated to a different architecture, while CORBA has to be translated for *EVERY* architecture).
Actually a rather poor example. I think that anything that can be presented as a file should have a file-like interface. So the editor can just open "/ftp/machine.bar.baz/subdir/file" and read/write it. Yes this will cause a large "component" to be linked in but it would be linked through the kernel.
The components are for where the interface is more object-specific, if I understand this correctly. You can send a message like "display your user interface in this x window id", which is meaningless for data files.
You may also be thinking about "passive grab" which is used by Window managers so they get the clicks that would normally go to a program. A bad WM can use this to stop a program from getting any clicks, but it is more obvious what is wrong (and is similar to the fact that a program can wedge X or any system like Windows by putting up a window that covers the screen and refusing to exit).
The problem is "active grab" which causes *all* mouse clicks (and keyboard) to go to a window. "Active grab" is used for exactly two things: to dismiss pop-up menus with a click anywhere on the screen, and for "snapshot" or "magnify" programs to indicate a place on the screen that is outside their control. I propose that active grab be cancelled when the mouse is released. This will not break the menu things (since the menu is dismissed). It will require the snapshot programs to have you click on the program again to restart (or maybe require you to hold down a shift key).
I want to see an example of a user that is confused because the borders on the buttons are different, or the font used inside them is different, or the color is different, or any of the few differences that exist between MODERN Windows/Mac/KDE/Gnome applications.
I don't believe these exist, and this stuff is being foisted on us by programmers who want to control things and are too lazy to do the hard part, which is to provide powerful graphics.
Believe me, it is trivial to draw a button or a pull-down menu, when compared to drawing an image with accurate dithering and arbitrary transformations. I wish all the time wasted making these built-in toolkits (by both commercial and free software writers) was spent doing the hard part.
Toolkits have their place, but there should be no reason there cannot be hundreds of them.
An extra bit of resolution could be achieved by shifting away the sign bit before truncation. (negative colors are not needed).
Better dithering algorithims are much more important to getting a good representation than throwing more bits at it. The vast majority of popular image file formats are 8-bit only, so a good converter to 8 bits is more important than handling 16 bits. A 16-bit file is likely to be run through a bad 16->8 converter, resulting in a *worse* result than if Gimp produced 16 bits.
A png-like standard that saves the exponent with reasonable compression would allow "lossless" storage.
One reason X still works, despite problems, is that it did not have "widgets". If X had "widgets" we would right now be stuck using an interface that was designed in 1982 (it would probably look like Athena or XView). Actually, more likely, X would be long dead and obsolete.
The complaints about X all center on the graphics capabilities (or lack of them). These graphics capabilities also date back to 1982, but the interesting thing is that there really has not been as much advancement in that area, and that even old graphics can be used to emulate new graphics. I don't hear people complaining that X's problem is the lack of a native call to draw a button or a menu!
I personally feel Berlin should concentrate on their (admittedly awsome) graphics capabilities. "Widgets" should be display lists provided by the client program, and events should be sent directly to the client program. There should be no classes of widgets. "Themes" can be done in a graphics-oriented way (rather than widget-oriented), by having calls to do things like "draw a raised area" that a theme can replace the code for.
The designers should exercise some humility and not try to solve problems that the client software can solve itself.
I would also like some proof that "different looking widgets" somehow "confuse users". I think this is a giant piece of FUD being given to everybody by the toolkit-mongers.
Windows has "grab" as well, but they release it after any mouse click that is not in the window that did the "grab". I believe this could be added to existing X and not break any applications that use grab, since 99% of the time they are doing this just to see if the user is dismissing a menu by clicking outside (other things like snapshot programs can just re-grab after the click). Unless the program maps a window over the entire screen I would think this would fix X so that grabs do not wedge the system.
The reason I believe this is that there *is* latency just like X when you first try to move a window, this would be the echo of the "lock the window to the cursor" command. You can also see obvious latency in the redrawing of the exposed windows. Also it seems to me that the windows often overshoot if you move them quickly, indicating latency for the "unlock the window" command (having the internals unlock on mouse release would be a reasonable fix).
This seems like a pretty good idea to add to X. If you have transparency/shapes to windows it also allows arbitrarily complex cursors.
X has another problem with "multiple visuals" (though this does not plague XFree86 on Linux, as only one visual is supported). On Irix at least, it changes the "visual" of the exposed window, changing it's color, before drawing the new pixels (even the background color), resulting in the horrid flashing that you get from X. I don't know the hardware limitations, but it seems that changing the "visual" of a pixel could be deferred until the pixel is actually drawn.
Actually it should be faster: a client program can defer creating changes until there are no events pending from the server, which is the same method used by most toolkits use now to avoid latency problems. This means exactly the same amount of information is sent, if you assumme a display change is the same size as the instructions to draw a widget.
From the comments, Berlin is sounding much more interesting to me than before. I thought they were trying to shove another toolkit down our throats, which I do not want. Instead it is sounding like they are attacking the real (and difficult) problems of getting efficient graphics. Any idiot can make a button (I did), drawing scalable device-independent graphics is hard and useful work!
A better filter for text would be a cheapo box filter. The worst it can turn a 1-pixel black line into is two .5 lines that are adjacent. Adjusting for the screen gamma (their examples *do* do this) will make a much more "even" result than this fancy filter (and would be dozens of times faster). In particular the thin lines would all appear to be much closer to the same weight (it is also necessary that the original binary image have lines of even thickness).
The "cleartype" I think looks somewhat sharper because it uses this simpler filter. You can also see dithering artifacts all over the white area to the right, so I believe they are rendering at 3x width and then translating this to the rgb values of each pixel, but using something like error diffusion to keep the average total color rendered "gray". I think they should reset the error after some number of pixels of solid color because your eye will not see this:
RGBRGB.....RGBR
as more red than this:
RGBRGB.....RGB
This would get rid of the dithering artifacts on the right.
In any case it actually is an innovative idea. The truth about innovative ideas is that they seem quite obvious once somebody thinks of them. It also means that it is almost impossible to stop real "innovation" from being used by everybody, since just seeing the output provides enough information for the innovation to be recreated. In fact I would expect this to appear in lots of commercial and free products quite soon.
If anti-aliasing requires using different X calls (and thus does not cause existing programs to antialias) I will kill the first XF86 representative I see.
(To be realistic, I expect antialiasing to work if a truecolor visual is used and copy transfer function is in use.)
The only "extension" I want is to add a simple X call: XSetTheDamnFont("Name of font goes here", point_size); This should ALWAYS set the font no matter what garbage I put in the name, set it to a default font if not found. And I should be able to get italic if the string contains the word "italic" in it.
Well, I could also use UTF-8 encoding.