Actually most (all?) commercial software I have seen for Linux copies the Windows model of putting the program under a subdirectory named after the company (if indeed they actually put anything on the menu, but that is another problem). That's copying a mistake, I think. With the level of submenus used on Linux (ie Graphics/Text/Games) and the smaller amount of available software, compainies could probably work fine by installing the item "SuperFoo(TM) by ProductCo(R)" on a top submenu, because the menu would not get really big.
Thanks for the info, that is obviously a start page for Firefox.
I think mine did go to that, but I changed the start page so quick I forgot it. And another poster says there is a "restore to default" setting but I don't see it, perhaps it was added in a newer version. I guess I could rename my firefox setup dir so I get the defaults, that would have allowed a test.
Is this a new feature? Firefox for me defaulted to a blank page, I think (I changed it and I don't see any way to "change to default" so I can't check). I think you may be confusing the default page with the default search for the search entry?
In case 1: A has patented, B has released in the wild. A sues B for tech A. B can't do anything.
What the parent proposes is that B publish the details of tech B. This prevents A from getting a patent on tech B, true, so there is the slight improvement that A can't sue for both tech A and B.
But it has no effect on the patent for tech A.
So getting a patent on tech B is a defensive move.
Definatly agree that there has been zero progress. Although I disagree about Vista, I don't think there has been progress their, and probably for the same reasons.
The biggest problem is that people complain that Linux does not "innovate" and copies Microsoft, but when anything comes out that is slightly different than Windows in even the most trivial way, those exact same people immediately claim it is not "user friendly". This is not just trolls, but actually people working on the systems. I also suspect this same problem is why Vista, or even OS/X, is not much different, they also have to be compatable with Windows, "user friendly" trumps innovation everywhere.
The second problem is the insane complex mess of libraries you must use to get anything done. This is not the Unix way. In some ways it is even worse than Windows.
Concrete suggestions, from most important downward, for actually improving and "innovating" the Linux desktop:
1. STOP RAISING WINDOWS ON CLICK! Change ALL window managers so that BY DEFAULT you can click in a window, move it, and resize it, iconize and reopen it, without raising it. This will instantly give Linux the ability to work with more than one application window at the same time, something that was easy in 1995 but is impossible now due to the slavish copying of Windows. This would make a huge distinctive advantage between Linux and the other systems. And to all the dimwits who will whine "that's not user friendly": it is TRIVIAL for the program itself to raise the window in response to the click, so this is an api problem, not a gui one!
2. Put the "big GUI chunks" into executables, following the Unix design. Lots of complaints about "inconsistent user interface" but too many think that means that all the pixels in the buttons have to match. That is NOT the problem, what people want is the FILE CHOOSERS to match. Everybody seems to think the file chooser is part of the toolkit, but it is not, it is just that they have no imagination of any other way to call it. What I want to see is an executable file that programs run to pop up the file chooser (or the print panel or font selector or all the popup yes/no and warnings, and a far better "dialog" program for most control panels). Then it can be replaced, and people with good ideas can try them out without joining the KDE/Gnome team. As people are freely able to replace their file choosers, I think within months Linux will switch from having the worst file choosers to having the best ones. Also give these programs good names, I don't care if they are the same as some obsolete Unix utility like "open", and I should be a simple "exec". Note that this will also allow shell scripts to have a "gui".
3. Some stuff people think is "gui" is actually basic system operations and should be part of the kernel and libc. Reproducing the effect of a double-click on a file icon should be a simple call (probably exec of that file), not require a huge gui-specific library. GnomeFS/KFS should be part of the system (use Fuse?) so that I can open() any url without thinking about it, and use cat and other Unix utilities. It should be possible to execute a program, wait till it is certain it is running and showing a window, then fork it. Locating an already-running copy of the same executable and communicating with it should be built in.
4. As much as possible, configuration should be controlled by the existence and contents of text files, NOT from any daemon! For a very short time applications were appearing on the desktop menus when they were installed, this was because the installer could cause a file to exist in the gnome hieararchy and the item would appear. This is no longer true, officially you are supposed to use a library call with 30 pages of complex rules, but they did add back-compatability but you have to log out/in to make it appear. The result is we are back again at where no installers create the menu item. Try learning something from this.
But if you lose the cable then you will need a special Nokia/Samsung-only cable with a patented connector, replacements available for $55 or whatever price they can get away with.
Standards should be required for every connection to the phone that can logically be assummed to be removable by the consumer. Otherwise the above scenario happens, just like it is happening now with the wall warts.
Considering that USB is designed to transmit data as well as power, I don't think a manufacturer will have any trouble designing a new innovative power supply where both the phone and power supply check each other for compatability and then switch into new innovative mode. If the cable needs to be thicker (perhaps to carry high current) then the cable can be attached to the power supply. If the connecter needs to be beefier, engineers have been very clever with adding such details while remaining compatable with the old plugs.
1. Because most purchasers insist on having color all the time.
2. Because lots of software will draw about 1/2 size on a 200 dpi screen, and fixing this would require rewriting lots of it and the system to get around huge amounts of assumption that 1-unit == 1-pixel. The OLPC can just claim to not run this software, as it won't run lots of stuff. Also such software requires color which will switch the OLPC into a lower-resolution mode.
First, it took quite awhile to figure out it is a Zune. Oddly enough (for Microsoft especially) there is no logo printed on the case anywhere, just a serial number on the bottom-back. There was fortunatly a display, but not anywhere near the sample, that I was able to match against the picture of. I was able to identify the several iPod products (especially a very tiny clip-on thing I had not seen before) because it said Apple (though tiny) somewhere on the back.
Second, it was dead. The iPod and the 3rd party machines were all working. Not sure what this indicates, it could mean far more people tried it? Or that the hardware can break?
I searched around and tried to find one so I could see what the api was. There on the other side of the aisle was some sort of Zune-dock, with what looked like a Zune plugged into it showing a picture. I went to try it, and the controls did not work! Despite being clamped down with a plastic bracket and not removable, it was a "non funcional unit" according to printing on the base, with a transparency (!) stuck in the display and lit by the backlight. Right next to it was a Bose iPod dock, with a real, working, nano in it (also clamped down so it could not be stolen).
So after a bit of searching I was completely unable to see the Zune's display or try it's user interface, yet I managed to try 3 or 4 apple products and something from sanyo (?) even though I was not searching for them. So far I think complete incompetence of their sales department is responsible for everything.
Unless the machine is so bad that it is better for them to prevent people from trying it before buying it? That is the impression I got, but I know Microsoft hardware is very high quality so I was able to dismiss that impression, but others might not.
Designing a universe where life will evolve, especially if you assumme that evolution must lead to a "man in his own form", is FAR more complex and difficult than just making the finished universe. Which do you think is more difficult: writing a computer game, or writing a program that creates an equally-good computer game? People who argue against evolution are basically saying that their god is too stupid and incapable to be able to create evolution, that is basically what their arguments amount to. That should be considered blashphamy (sp?) by their own religion!
The Macintosh had the shift keys in the lower-left labelled ctrl, option, "apple". There was no key marked "alt". They used option to shift to foreign letters on the keyboard, and always intended "apple" to be the shortcut key.
PC's at the time had ctrl, Alt. The "Windows" key was added later, after all these decisions were made.
The shift+insert stuff was the Microsoft and CDE standard. Early versions of Word used this exclusively. I don't think Mac ever did it, and support on Windows and Linux is spotty, while every program in the world now supports the Mac ZXCV shortcuts. Despite the probably-good intention of not using up shortcut letters for editing keystrokes, it was obviously too hard to remember and everybody immediatly adopted the Mac shortcuts.
Well that is just incredibly stupid. All these people have got to get through their thick skulls that they should attach NO meaning to the bytes in a filename. On Unix the '/' and null have some meaning, which is not really right, but as good as we are going to get without significant changes to the API. Past that, it should be *absolutely* irrelevant to the OS, *ALL* possible arrangements of bytes should be allowed, whether they are legal UTF-8 or not, and if the two byte strings do not match bit for bit, THEY ARE DIFFERENT FILES!!!!!
Doing anything else results in horrible problems, because different systems will disagree on exactly what strings are equivalent and as you noticed this results in extremely confusing incompatabilities.
How the string is displayed and distinguished to the user is strictly a GUI problem. Thinking you can fix it by somehow magically making the hard-to-display strings "illegal" is burying your head in the sand. The GUI will have to be able to display arbitrary strings anyway, as the program may produce them without actually reading a file name.
All you morons who think "case independence" is a good thing should listen up as well.
I think Windows got this wrong (Linux copied Windows). Windows should have used the Alt key. In fact if you look at DOS programs, the vast majority used the Alt key for letter-based shortcuts (they also tended to use the numbered function keys a lot more). Control keys either were shortcuts for navigation and text editing only (often emulating Emacs or Wordstar), or just inserted weird smily faces and cards. X applications also used the Alt key almost exclusively for shortcuts. The Alt key was much more equivalent to the location of the Apple key on Macs. And as X programs showed, using Ctrl made a consistent interface to a terminal application impossible. So it is unclear why Microsoft ignored all this precedent and chose Ctrl.
One possible explanation is that they wanted to run DOS programs in windows, and since they used the Alt key, they might be unusable if the Alt key did shortcuts such as open/close windows and thus blocked a shortcut the DOS program required. Another I have heard is that Alt was used by foreign keyboard layouts (the Mac used the "option" key which was placed where Ctrl is), however I am confused how this was done without breaking all the DOS programs anyway. Also Alt+numkeypad was hard-wired into many users brains for inserting foreign letters, though this should not have been a problem as the numeric keypad is not used for shortcuts anyway.
Apple kind of messed up with the "Library" stuff. Everything you "uninstall" should be under the.app directory, so you can uninstall by throwing the thing in the trash.
"Library" should be for stuff shared by *multiple* applications and is data that might change. All those applications should work without the files being there (in particular this means that.so files go into the app, not "Library", unless you really expect people to customize and update that.so file). Uninstalling the applications should not remove things from the library, even if you remove the last one that uses the library item, you might reinstall one later.
Your text input question is silly. What happens if you have two documents open in the *same* application? There is no problem typing into one or the other. Same thing here, if there is some way for two applications to be "active" at the same time, then you click on the windows and nothing happens other than that the text input goes to one or the other. Shortcuts would go to the menubar for the window getting text input.
I would agree. I never knew Return had something to do with renaming, and I also certainly expected it to open the file or otherwise act like double-click (and I never use Windows or a Linux finder, so this is completely without preconcieved notions of how these should work).
Certainly "F2" is not intuitive. When I have to use Windows I just keep clicking on the filename until I get the magic point that makes it go into text-editing mode. I also did this on the Mac.
The best solution is probably to have Return act like double-click, which would match a lot of other GUI. This probably means it opens it, though maybe it means that double-click renames files? Certainly F2 is stupid (I am also annoyed at how many people think F4 is a logical thing to close windows with). But how about a command+letter such as 'r' or 'n' or something that might be deduced from "rename"?
I absolutely agree. "Click to front" is by far the biggest problem with the user interface on Windows, Mac, and Linux.
Now let's get this straight, as you are recommending an even worse thing with your "layers" idea. The actual solution is simple:
1. When the user clicks in a window, that app gets the mouse click. NOTHING ELSE HAPPENS!!!!
2. There is an API so an application can raise it's own window, or place it immediatly above or below some other window.
Notice that it is TRIVIAL to emulate current behavior (call the "raise window" api on any mouse click). This means by definition that there is absoltely NO question that this is the proper api, no matter what the proper GUI is. There is no argument about this, so don't even try. If you think there is some problem with the system not doing something that the program can do easily itself, you are not thinking very hard.
This simple change will enable actual use of overlapping windows. It will allow a program to display two different UI windows whose total area is greater than the screen and still be usable (such as, in my case, a large data flow graph and a large picture showing the result), rather than the tiled interface we are forced to use today. It will allow floating toolbars that really work and let you work with more than one document and thus eliminate a huge kludge of toolbars and methods of managing them. It will allow programs to change their mind about whether a window is "modal" or not. It will eliminate a big mess of complex "child/modal/transient-for" api to the window manager, all of which are simply methods of stopping windows from raising on clicks.
The tiled interface was rejected back in 1984 when the CMU Andrew project died and was replaced by X. It was actually debated for awhile which is why the api to X window managers is so complex and programs are supposed to not assumme their windows are the requested size, but it is gone. X11 removed the "click to top" behavior that was in X10 and it was clear then that this is the correct solution. But somehow, mostly due to Windows compatability but even NeXT had this, it has snuck back. And people are apparently BLIND to the problem, they instead propose enormous complex systems of child/modal/transient-for and "layers" and window types and having the system know about toolbars and OS/X gadgets and all kinds of horrible stuff that all boils down to stopping windows from raising on click. The frustration of seeing people completely ignore the simple and obvous solution, for 20 years now, is incredibly frustrating!
PS: no-click-to-top has nothing to do with focus-follows-mouse (though I like that too). It is just more blindness, people are apparently unable to concieve of clicking without raising, so they cannot see a way to type to a lower window except by using focus-follows-mouse.
I worked with both VMS and Unix (at that time BSD ported to the VAX) at DEC itself in 1983, the job was to port the CLU (an early object-oriented language) compiler from BSD to VMS. Even then, and in the middle of DEC, it was blatently obvious what every single person there preferrered. When I discovered that you could read *ANY* file with the same call (read()) rather than using RMS I was sold. And many others around me with much more experience were praising it. I was quite certain that VMS was doomed within a few years, as DEC itself was going to switch.
NT was available for developers in 1992 (I saw one running at Sun) and running a network connection of some sort. I was certainly unaware of a usable Linux until about 1996 or so. Yes it existed back then but I very much suspect that a lot of the reason for it's growing in popularity was triggered by the discovery in 1992 that NT was not going to be Unix compatable.
On mine the Return key also has "Enter" printed in gray on it. You hold down the lower-left "fn" key and hit it. Maybe they changed this on more recent models?
Everybody claiming this guy is too stupid to figure out that applications are in/Applications does not understand the problem.
Here, simply, is where Apple drops the ball on the CLI or on anything an expert user wants to do: mount a disk, perhaps by double-clicking one of those disk images. You can see the files in a window. Now, quick, tell me what the path name is for any of those files.
As far as I can tell, Apple has NO GUI to reveal this information. Even the most complete "get info" does not show it.
Linux and Windows would show the pathname in the window title.
Yes, I know you look in/Volumes and search around. But it does seem insane that they will not reveal this information.
Slashdot Mirror
Actually most (all?) commercial software I have seen for Linux copies the Windows model of putting the program under a subdirectory named after the company (if indeed they actually put anything on the menu, but that is another problem). That's copying a mistake, I think. With the level of submenus used on Linux (ie Graphics/Text/Games) and the smaller amount of available software, compainies could probably work fine by installing the item "SuperFoo(TM) by ProductCo(R)" on a top submenu, because the menu would not get really big.
Thanks for the info, that is obviously a start page for Firefox.
I think mine did go to that, but I changed the start page so quick I forgot it. And another poster says there is a "restore to default" setting but I don't see it, perhaps it was added in a newer version. I guess I could rename my firefox setup dir so I get the defaults, that would have allowed a test.
Is this a new feature? Firefox for me defaulted to a blank page, I think (I changed it and I don't see any way to "change to default" so I can't check). I think you may be confusing the default page with the default search for the search entry?
You are right, but I was initially confused, too.
In case 1: A has patented, B has released in the wild. A sues B for tech A. B can't do anything.
What the parent proposes is that B publish the details of tech B. This prevents A from getting a patent on tech B, true, so there is the slight improvement that A can't sue for both tech A and B.
But it has no effect on the patent for tech A.
So getting a patent on tech B is a defensive move.
Definatly agree that there has been zero progress. Although I disagree about Vista, I don't think there has been progress their, and probably for the same reasons.
The biggest problem is that people complain that Linux does not "innovate" and copies Microsoft, but when anything comes out that is slightly different than Windows in even the most trivial way, those exact same people immediately claim it is not "user friendly". This is not just trolls, but actually people working on the systems. I also suspect this same problem is why Vista, or even OS/X, is not much different, they also have to be compatable with Windows, "user friendly" trumps innovation everywhere.
The second problem is the insane complex mess of libraries you must use to get anything done. This is not the Unix way. In some ways it is even worse than Windows.
Concrete suggestions, from most important downward, for actually improving and "innovating" the Linux desktop:
1. STOP RAISING WINDOWS ON CLICK! Change ALL window managers so that BY DEFAULT you can click in a window, move it, and resize it, iconize and reopen it, without raising it. This will instantly give Linux the ability to work with more than one application window at the same time, something that was easy in 1995 but is impossible now due to the slavish copying of Windows. This would make a huge distinctive advantage between Linux and the other systems. And to all the dimwits who will whine "that's not user friendly": it is TRIVIAL for the program itself to raise the window in response to the click, so this is an api problem, not a gui one!
2. Put the "big GUI chunks" into executables, following the Unix design. Lots of complaints about "inconsistent user interface" but too many think that means that all the pixels in the buttons have to match. That is NOT the problem, what people want is the FILE CHOOSERS to match. Everybody seems to think the file chooser is part of the toolkit, but it is not, it is just that they have no imagination of any other way to call it. What I want to see is an executable file that programs run to pop up the file chooser (or the print panel or font selector or all the popup yes/no and warnings, and a far better "dialog" program for most control panels). Then it can be replaced, and people with good ideas can try them out without joining the KDE/Gnome team. As people are freely able to replace their file choosers, I think within months Linux will switch from having the worst file choosers to having the best ones. Also give these programs good names, I don't care if they are the same as some obsolete Unix utility like "open", and I should be a simple "exec". Note that this will also allow shell scripts to have a "gui".
3. Some stuff people think is "gui" is actually basic system operations and should be part of the kernel and libc. Reproducing the effect of a double-click on a file icon should be a simple call (probably exec of that file), not require a huge gui-specific library. GnomeFS/KFS should be part of the system (use Fuse?) so that I can open() any url without thinking about it, and use cat and other Unix utilities. It should be possible to execute a program, wait till it is certain it is running and showing a window, then fork it. Locating an already-running copy of the same executable and communicating with it should be built in.
4. As much as possible, configuration should be controlled by the existence and contents of text files, NOT from any daemon! For a very short time applications were appearing on the desktop menus when they were installed, this was because the installer could cause a file to exist in the gnome hieararchy and the item would appear. This is no longer true, officially you are supposed to use a library call with 30 pages of complex rules, but they did add back-compatability but you have to log out/in to make it appear. The result is we are back again at where no installers create the menu item. Try learning something from this.
But if you lose the cable then you will need a special Nokia/Samsung-only cable with a patented connector, replacements available for $55 or whatever price they can get away with.
Standards should be required for every connection to the phone that can logically be assummed to be removable by the consumer. Otherwise the above scenario happens, just like it is happening now with the wall warts.
Considering that USB is designed to transmit data as well as power, I don't think a manufacturer will have any trouble designing a new innovative power supply where both the phone and power supply check each other for compatability and then switch into new innovative mode. If the cable needs to be thicker (perhaps to carry high current) then the cable can be attached to the power supply. If the connecter needs to be beefier, engineers have been very clever with adding such details while remaining compatable with the old plugs.
how come regular LCD monitors are *not* 200 dpi?
1. Because most purchasers insist on having color all the time.
2. Because lots of software will draw about 1/2 size on a 200 dpi screen, and fixing this would require rewriting lots of it and the system to get around huge amounts of assumption that 1-unit == 1-pixel. The OLPC can just claim to not run this software, as it won't run lots of stuff. Also such software requires color which will switch the OLPC into a lower-resolution mode.
First, it took quite awhile to figure out it is a Zune. Oddly enough (for Microsoft especially) there is no logo printed on the case anywhere, just a serial number on the bottom-back. There was fortunatly a display, but not anywhere near the sample, that I was able to match against the picture of. I was able to identify the several iPod products (especially a very tiny clip-on thing I had not seen before) because it said Apple (though tiny) somewhere on the back.
Second, it was dead. The iPod and the 3rd party machines were all working. Not sure what this indicates, it could mean far more people tried it? Or that the hardware can break?
I searched around and tried to find one so I could see what the api was. There on the other side of the aisle was some sort of Zune-dock, with what looked like a Zune plugged into it showing a picture. I went to try it, and the controls did not work! Despite being clamped down with a plastic bracket and not removable, it was a "non funcional unit" according to printing on the base, with a transparency (!) stuck in the display and lit by the backlight. Right next to it was a Bose iPod dock, with a real, working, nano in it (also clamped down so it could not be stolen).
So after a bit of searching I was completely unable to see the Zune's display or try it's user interface, yet I managed to try 3 or 4 apple products and something from sanyo (?) even though I was not searching for them. So far I think complete incompetence of their sales department is responsible for everything.
Unless the machine is so bad that it is better for them to prevent people from trying it before buying it? That is the impression I got, but I know Microsoft hardware is very high quality so I was able to dismiss that impression, but others might not.
Designing a universe where life will evolve, especially if you assumme that evolution must lead to a "man in his own form", is FAR more complex and difficult than just making the finished universe. Which do you think is more difficult: writing a computer game, or writing a program that creates an equally-good computer game? People who argue against evolution are basically saying that their god is too stupid and incapable to be able to create evolution, that is basically what their arguments amount to. That should be considered blashphamy (sp?) by their own religion!
This sounds like accurate information about what was going on at the time, and where the shift+insert came from:
http://en.wikipedia.org/wiki/Common_User_Access
The Macintosh had the shift keys in the lower-left labelled ctrl, option, "apple". There was no key marked "alt". They used option to shift to foreign letters on the keyboard, and always intended "apple" to be the shortcut key.
PC's at the time had ctrl, Alt. The "Windows" key was added later, after all these decisions were made.
The shift+insert stuff was the Microsoft and CDE standard. Early versions of Word used this exclusively. I don't think Mac ever did it, and support on Windows and Linux is spotty, while every program in the world now supports the Mac ZXCV shortcuts. Despite the probably-good intention of not using up shortcut letters for editing keystrokes, it was obviously too hard to remember and everybody immediatly adopted the Mac shortcuts.
Emacs shortcuts work on the Mac: Ctrl+E for end, Ctrl+A for start of line.
Well that is just incredibly stupid. All these people have got to get through their thick skulls that they should attach NO meaning to the bytes in a filename. On Unix the '/' and null have some meaning, which is not really right, but as good as we are going to get without significant changes to the API. Past that, it should be *absolutely* irrelevant to the OS, *ALL* possible arrangements of bytes should be allowed, whether they are legal UTF-8 or not, and if the two byte strings do not match bit for bit, THEY ARE DIFFERENT FILES!!!!!
Doing anything else results in horrible problems, because different systems will disagree on exactly what strings are equivalent and as you noticed this results in extremely confusing incompatabilities.
How the string is displayed and distinguished to the user is strictly a GUI problem. Thinking you can fix it by somehow magically making the hard-to-display strings "illegal" is burying your head in the sand. The GUI will have to be able to display arbitrary strings anyway, as the program may produce them without actually reading a file name.
All you morons who think "case independence" is a good thing should listen up as well.
I think Windows got this wrong (Linux copied Windows). Windows should have used the Alt key. In fact if you look at DOS programs, the vast majority used the Alt key for letter-based shortcuts (they also tended to use the numbered function keys a lot more). Control keys either were shortcuts for navigation and text editing only (often emulating Emacs or Wordstar), or just inserted weird smily faces and cards. X applications also used the Alt key almost exclusively for shortcuts. The Alt key was much more equivalent to the location of the Apple key on Macs. And as X programs showed, using Ctrl made a consistent interface to a terminal application impossible. So it is unclear why Microsoft ignored all this precedent and chose Ctrl.
One possible explanation is that they wanted to run DOS programs in windows, and since they used the Alt key, they might be unusable if the Alt key did shortcuts such as open/close windows and thus blocked a shortcut the DOS program required. Another I have heard is that Alt was used by foreign keyboard layouts (the Mac used the "option" key which was placed where Ctrl is), however I am confused how this was done without breaking all the DOS programs anyway. Also Alt+numkeypad was hard-wired into many users brains for inserting foreign letters, though this should not have been a problem as the numeric keypad is not used for shortcuts anyway.
Apple kind of messed up with the "Library" stuff. Everything you "uninstall" should be under the .app directory, so you can uninstall by throwing the thing in the trash.
.so files go into the app, not "Library", unless you really expect people to customize and update that .so file). Uninstalling the applications should not remove things from the library, even if you remove the last one that uses the library item, you might reinstall one later.
"Library" should be for stuff shared by *multiple* applications and is data that might change. All those applications should work without the files being there (in particular this means that
Your text input question is silly. What happens if you have two documents open in the *same* application? There is no problem typing into one or the other. Same thing here, if there is some way for two applications to be "active" at the same time, then you click on the windows and nothing happens other than that the text input goes to one or the other. Shortcuts would go to the menubar for the window getting text input.
I would agree. I never knew Return had something to do with renaming, and I also certainly expected it to open the file or otherwise act like double-click (and I never use Windows or a Linux finder, so this is completely without preconcieved notions of how these should work).
Certainly "F2" is not intuitive. When I have to use Windows I just keep clicking on the filename until I get the magic point that makes it go into text-editing mode. I also did this on the Mac.
The best solution is probably to have Return act like double-click, which would match a lot of other GUI. This probably means it opens it, though maybe it means that double-click renames files? Certainly F2 is stupid (I am also annoyed at how many people think F4 is a logical thing to close windows with). But how about a command+letter such as 'r' or 'n' or something that might be deduced from "rename"?
I absolutely agree. "Click to front" is by far the biggest problem with the user interface on Windows, Mac, and Linux.
Now let's get this straight, as you are recommending an even worse thing with your "layers" idea. The actual solution is simple:
1. When the user clicks in a window, that app gets the mouse click. NOTHING ELSE HAPPENS!!!!
2. There is an API so an application can raise it's own window, or place it immediatly above or below some other window.
Notice that it is TRIVIAL to emulate current behavior (call the "raise window" api on any mouse click). This means by definition that there is absoltely NO question that this is the proper api, no matter what the proper GUI is. There is no argument about this, so don't even try. If you think there is some problem with the system not doing something that the program can do easily itself, you are not thinking very hard.
This simple change will enable actual use of overlapping windows. It will allow a program to display two different UI windows whose total area is greater than the screen and still be usable (such as, in my case, a large data flow graph and a large picture showing the result), rather than the tiled interface we are forced to use today. It will allow floating toolbars that really work and let you work with more than one document and thus eliminate a huge kludge of toolbars and methods of managing them. It will allow programs to change their mind about whether a window is "modal" or not. It will eliminate a big mess of complex "child/modal/transient-for" api to the window manager, all of which are simply methods of stopping windows from raising on clicks.
The tiled interface was rejected back in 1984 when the CMU Andrew project died and was replaced by X. It was actually debated for awhile which is why the api to X window managers is so complex and programs are supposed to not assumme their windows are the requested size, but it is gone. X11 removed the "click to top" behavior that was in X10 and it was clear then that this is the correct solution. But somehow, mostly due to Windows compatability but even NeXT had this, it has snuck back. And people are apparently BLIND to the problem, they instead propose enormous complex systems of child/modal/transient-for and "layers" and window types and having the system know about toolbars and OS/X gadgets and all kinds of horrible stuff that all boils down to stopping windows from raising on click. The frustration of seeing people completely ignore the simple and obvous solution, for 20 years now, is incredibly frustrating!
PS: no-click-to-top has nothing to do with focus-follows-mouse (though I like that too). It is just more blindness, people are apparently unable to concieve of clicking without raising, so they cannot see a way to type to a lower window except by using focus-follows-mouse.
Well perhaps the programs could, um, *hide* the mouse cursor until you move it? Just a thought.
I worked with both VMS and Unix (at that time BSD ported to the VAX) at DEC itself in 1983, the job was to port the CLU (an early object-oriented language) compiler from BSD to VMS. Even then, and in the middle of DEC, it was blatently obvious what every single person there preferrered. When I discovered that you could read *ANY* file with the same call (read()) rather than using RMS I was sold. And many others around me with much more experience were praising it. I was quite certain that VMS was doomed within a few years, as DEC itself was going to switch.
NT was available for developers in 1992 (I saw one running at Sun) and running a network connection of some sort. I was certainly unaware of a usable Linux until about 1996 or so. Yes it existed back then but I very much suspect that a lot of the reason for it's growing in popularity was triggered by the discovery in 1992 that NT was not going to be Unix compatable.
In fact it is exactly the same. DUH.
On mine the Return key also has "Enter" printed in gray on it. You hold down the lower-left "fn" key and hit it. Maybe they changed this on more recent models?
Everybody claiming this guy is too stupid to figure out that applications are in /Applications does not understand the problem.
/Volumes and search around. But it does seem insane that they will not reveal this information.
Here, simply, is where Apple drops the ball on the CLI or on anything an expert user wants to do: mount a disk, perhaps by double-clicking one of those disk images. You can see the files in a window. Now, quick, tell me what the path name is for any of those files.
As far as I can tell, Apple has NO GUI to reveal this information. Even the most complete "get info" does not show it.
Linux and Windows would show the pathname in the window title.
Yes, I know you look in
Did you know that economics is a science, too?
Apparently not.