Easily solved -- some sort of daemon for the palm that can perform housekeeping functions in the background... like replacing 'dickhead' with 'mr. cooper.' Why should you have to remember such a trivial thing? Let the computer handle that mundane crap.
Well, two points.
1) Monopolies are not capitalistic. Their closest relationship could be analogized as perhaps cancerous. Monopolies are, by and large, not at all effected by supply/demand curves. Because of the lack of viable alternatives (e.g. if there were only one water company, the fact that it rains doesn't erase the monopoly; rain's not enough) price can be arbitrarily increased, supply arbitrarily restricted, and consumers will, against their best interests, be compelled to continue supporting it.
In order for capitalism to function properly, we need perfect competition. Fully interchangable vendors and consumers. The ability to take advantage of even the slightest niches. Precisely the opposite from what you get with a monopoly. Natural monopolies may be tolerated, but they're not particularly good, and as it turns out, perhaps not as inevitable even in their rare niches, as previously imagined.
2) Screw capitalism. Why do you want capitalism? I would vastly prefer an economic system that was perfectly compatable with notions of justice and humanity and societal goals than capitalism.
Capitalism may be, in part, the closest we have yet come, but it is inherently no more deserving of our support than anything else. That is, adopt a capitalistic approach in choosing economic models!;) Don't give into brand loyalty if it is disadvantageous for you to do so.
Furthermore, because we have laws, and desires that may be quite divorced from those of a perfect capitalist (e.g. I have no desire to see children employed in factories because it is inhumane) and we have therefore, the ability to pick certain parts of capitalism that we like (the efficiencies afforded through vigorous total competition, for example) and throw out the bits we don't like (like monopolies) by, in effect, putting our thumb on the scales and weighting it to the side that we most favor.
Thus, not all capitalistic endeavors are permitted. Not because they make economic sense, but because social concerns may be of greater importance. (e.g. not letting people pollute, not letting drugs go out untested, workplace safety standards, antitrust laws, banking regulations....)
Well, if you don't like it, you're going to have to either 1)make an _AMAZING_ case to overturn a finding of fact, which almost never ever happens or 2)redesign the entire American legal system from the ground up.
Like it or lump it, trial courts find facts, and all any appellate court in the nation can do is to determine if the law was properly applied to those unchangable facts. No one really even bothers making arguments on appeal regarding the facts -- it's a guaranteed loser.
Deal with the fact that they are a monopoly. You want to defend them -- you're going to have to find some way to do it that accounts for that. It's entirely possible. ATT was a monopoly in the 20's IIRC, and lasted for ~60 years with no more problems than being denied the ability to move into different markets, and strict governmental regulation. Then they elected to go with a breakup route and discovered, to their chagrin, that competition was a damn lot better for everyone.
MS ought to be thrilled about the possibility of a breakup -- it's better in the long run. But I could live with merely handing over the reins to the courts and Congress, if I must.
There are flaws with the Mac way, but most of them revolve around the implementation, and not the idea, AFAICT. The codes should be fully human readable. (one way or another) Better use should be made of widgets in selecting codes. Additional granularity should be built in, rather like BeOS. (where a file is simultaneously known to be text, ascii text, html, and js, because it matches all of those in some way) Type codes should be more standardized between apps. Alternate creators: e.g. if there's no Photoshop, try Graphics Editor. Suffixes to be added on export from the system. Etc.
It's actually a bad idea, 99% of the time to change type -- it is really supposed to mesh with the format of the file. Changing creator is comparatively minor, but the system ought to make it so easy to change to another creator that is compatable with that file that it is rare to need to exercise the ability to change it to anything at all.
The point is marginally moot at the moment, because I'm no longer at my old job, where this came up. But it is still a highly desirable feature for me.
I used to write html for a living, and so I needed a bunch of html files that would open in my preferred editor by default. While I would preview them, I edited them far more, and could just hit some keys in the editor to preview in the browser anyway.
However, because I'm really lazy, and enjoy reading, I used to download fiction in html and plain text format, and read it. I never edited it. (perhaps only once when I first dl'd it, to strip out some junk at the top and bottom) And I preferred reading it in a web browser, because I could wham the space key, and page down. (were I looking at it in an editor, I'd have to hit the smaller pagedown key, and be careful not to hit any letter keys, as they'd pop the view back to the cursor location and change the file, neither of which I wanted)
And I hate having to explicitly open any of my files in some program that's not their default, unless it's something I want to do. Since I will always open/work/index.html in BBEdit, and I will always open/fic/index.html in IE, there's no reason to make me choose which one I will have to assume a permanent burden of manually opening.
There are other situations where this comes up. (picture viewers v. photoshop) Enjoy.
Well, allow me then to append a caveat that I ought to have added anyway. It's dumb to actually roll out UIs that have not been tested, revised, and retested very frequently, from the very beginning.
So given these comments, it implies that a better algorithim controlling the autocomplete is in order. But I'm still drawn to the idea, I have to admit. Academic though it is, however... I have no ability to make one.
I disagree regarding shells, though. Honestly, the point of open standards is supposed to be that people can improve on one anothers' work if able to. Yet terminals have not substantially changed -- or gotten easier to use, which is a shame, because they're important and powerful -- since probably the late 70's. I think it has a lot more to do with preconceived notions of what a terminal is, than actual technical difficulties.
(what's the worst thing that happens -- release the standard to use the GUI shell, tweak the fairly standard utilities like ls and chmod, etc. and let people modify their own if they care, and if not, let people type it in as normal...)
Yep. On all counts, actually. You're an unusually perceptive AC, I've got to say.
Nevertheless, I'm totally right on this one. (although I am willing to allow that there are multiple methods by which we can accomplish the task of the computer more or less reading the mind of the user)
Do me a favor, and discover why it is that the computer should have to handle the busy work of remembering file associations. Set the association for a file type you use a lot to a program you hate, and never use. Then force yourself to have to right click on it all the time.
Would you feel better if only half of your files were that annoying? Would it not be superior for NONE of your files to be that annoying, barring unusual circumstances?
Because I would _always_ have to right click. If I slipped up and accidently double clicked, I'd waste time. Even if I go through the hassle, mentally and temporally of doing the Open With thing, it would become tedious in, curiously, 0.5 seconds.
Computers are supposed to make our lives easier dammit. Why should I have to waste my precious time and thought cycles when I know for a fact that for the given file I will NEVER open it in the otherwise default app. Never ever. Users should not have to assume the computer's role. They should not be burdened with keeping track of and performing repetitive actions. It's even more useless than the godawful Print dialog.
Actually, on a Mac, a file is reassociated with the last app to SAVE the file. Opening has no effect. (with a few rare exceptions -- MacAST has an option to do it on an open)
But of course, a file having a particular binding does not have ANY effect at all on alternative methods of opening it, e.g. through Open dialogs. So this is better than your CLI example. You can _still_ explicitly open a file with a particular application. But if there's one that is used more than the others, you can bind it, and that's the default. It has the ability to work out faster, and in the worst case, is no slower.
What's wrong with the Mac metadata scheme, BTW? I realize that HFS+ isn't the greatest filesystem... But BFS, NTFS, HFS+ and XFS all have their different appealing points. Could you be more specific?
Oh, a number had been canned all through the 90's, ever since System 7 finally came out. (plus, to add insult to injury, the trigger for the Blue Meanies' ULTIMATE easter egg was removed. Bastards!)
But yeah, basically, Steve is supreme. Hell, the stupid bastard didn't even understand the benefits of GUIs until the two PARC trips were arranged SOLELY for his benefit. Everyone else had gotten it -- but not him. (then he thought it was his own idea... jeesh)
However, I think that a combination of modified popup folders and spring loaded folders would make a better Apple menu than the Apple menu itself. It's too long to discuss here, but look for my posts on Ars Open Forum for more details
Tabs blow. Compare tab autocomplete to the autocomplete found in most browser URL fields. The latter blows it away.
I mean, why do so many people seem to think that terminals must be bad imitations of 60's era teletypes? Brain damage from sitting in front of CRTs all day long? Throw in some GUI widgets... they'll do wonders. I'd frickin' love to right-click on a command like LS and have additional options be selectable, which insert themselves in between the command and the pattern. But God forbid, huh?
If I open file FRED.FOO with the FOO program 90% of the time, and with the BAR program 10% of the time, it makes sense for it to default to FOO.
If I open file BARNEY.FOO with the BAR program 90% of the time, and with the FOO program 10% of the time, it makes sense for it to default to BAR.
Even though the files are identical in data and format. Otherwise you are subjecting the user to the hassle of using a slower opening method (e.g. drag and drop, Open menus) for the 90% of the time that they open that file that doesn't conform to the overall rule. And that rule itself may be unclear, if there's a fairly even split of files set for FOO and BAR
Heh. It's been called metadata for ages. Longer than I can remember. It's a pretty predictable moniker for anyone to come up with, and probably predates any of us. (file NAMES are metadata, for God's sake... they've been around for many decades)
Ideally, as John pointed out, you adopt a multi-pronged approach. The stored metadata is primarily a cache for performance purposes. It can be erroneous, but ideally it should be checked once (usually as an incidental thing the user is doing) and then left alone. As fallbacks, you can examine the file for magic numbers, as Unix does, or just admit it, and ask the user.
BeOS and MacOS have had the best methods, combined with the Unix magic numbers as a method of last resort. Large disks, and forked files could permit definition forks to accompany files invisibly and at almost no performance penalty. Better behaved apps that recognize these things via APIs, and some affordance for backwards compatability in recognizing legacy extensions and codes would all be good starting places
Er, no. Resource forks are functionally equivalent to NTFS streams, and features Linus has called for in Linux. Think of it as a very low-level support for tarring files together. There's a data file, and a resource file, and they wind up sharing the same icon and metadata as far as the user can tell. They are joined at the hip, though in fact seperate entities. They are not metadata, they _are_ data.
Creator/Type bindings are stored in the filesystem proper, and are basically the same type of thing as filename (not stored in the file, but associated with it!) modification date, read/write permissions, etc.
There was a good article on ArsTechnica a while back about this sort of thing. Read it; it's very good.
Law is of course, applicable. The reasons we don't have 'KILL PATIENT NOW' buttons on medical software UI is not entirely market-driven, you know. There's nothing whatsoever special about software as distinguished from any other product people make, no matter how high an opinion of themselves technical people may think.
(e.g. the term 'boilerplate' derives from the practice of boiler manufacturers of putting disclaimers on their products to avoid responsibility when they exploded and killed people... this wasn't really the greatest solution in the world to boiler explosions, as I'm sure you'll agree. It is mirrored eerily in the realm of software, however.
Because FIRST, those commands should be in the main menu. That way there is an alternative, more visible means for newbie users to get to them. Contextual menus are great, but they must not be the only means of accessing a particular command. (even if they are often a more efficient way; not everyone is efficient)
So yeah, I love 2dary mouse buttons. As an option that I can use or ignore at my lesiure.
Why? They can both coexist. Or you can choose to have some files open in one (e.g. html files I am involved in writing open in BBEdit) or others in a different app. (e.g. html files I keep around for readin' purposes open in IE)
BeOS was, I understand, pretty elegant about this. There was a default type generally, but any specific file could have a specific creator associated with it alone.
What if you create all your html files in a text editor, save them, and want to open them back up in a text editor? Except for the hundreds of megabytes of html files you download off the net and NEVER edit, of course.
I really loathe the Windows 'either/or' proposition. I have some files I edit by default, and some files I only read by default, and I do not want them opening in the same program when I double-click, despite the total lack of difference in the structure or content. Drag and drop, using the Open, or Open With commands to more explicitly choose the app to open a file with on an infrequent basis is great, no problem. Making me do it routinely, forever, on files that I will _never_ open with a 'default' program, is an exercise in extreme annoyance
Plainly, you cannot restore the resources. They're GONE. It is as foolish to think that it is possible to do so as it would be to use notepad to delete the contents of notepad.exe and then try to run it.
Nevertheless, resources are a really good idea.* So good that they're in NTFS, under the moniker 'Streams.' Since most Mac software automatically encodes dual-forked files to preserve the data as it is sent out, and decodes it as it comes back in, it is almost never a problem. Ironically however, if you send a streamed file from an NTFS volume to a FAT volume, the data will simply be lost, with no automagic encoding method employed.
*and yeah, forks _are_ a good idea. Basically it is taking the messy-ass contents of an application folder (e.g. MS Office) and tarring them all together into a single file that nevertheless runs when you click on it. Had they only integrated a decent feature into the finder to probe around in the contents reasonably, it would've kicked ass and taken names. I'm still fond of forked files
Oh yeah, four bytes is eight-billion times worse than _three_ bytes. You betcha.
Yeah, there are stupid technical reasons dating back to the early eighties for the four byte codes. (though there were some funny hacks that you could perform with them as well) Something more readable really _would_ be better, through a sham if necessary, but ideally right in the fs, a la BeOS. (though MIME itself is not as readable as would yet be preferred)
Really? Wow. One wonders how drag and drop, the open dialog, the save as dialog, etc. all operate then.... (Incidentally, ResEdit is by Apple, and therefore a first-party program -- or is it second party? -- well not third, at any rate)
Open With is okay for ocassional use, and I'd like to see it on the Mac. I'd like to see Snitch-like functionality integrated with the Finder. But of course, retaining creator metadata is a _great_ idea as well....
Really the problem is not with right clicking, per se. Contextual menus are in fact, a really good idea. There was never any particular reason at Apple for the one button rule, other than that Raskin hadn't predicted the eventual need for added functionality (e.g. shift-drag for multiple discontiginous select) and didn't like the old PARC methodology, which relied almost completely on menus. (e.g. there was no concept of dragging icons places, by and large)
Before you go spouting off the old myths about user testing to determine the number of buttons, GO READ UP. There are _frickin'_ interviews with Raskin, with people that designed the mice, etc. that plainly show that the decision was made before there had been any testing, or even software _to_ test. (the Stanford pages are a godsend for this)
Anyway though, the main problem Windows has always had is that there were typically commands that could only be accessed contextually. That's a big dumb mistake, and one that Apple's HIG specifically addresses. Contextual commands should invariably be available in the menus anyway, so that the UI pillar of 'multiple ways to do things' is properly employed. When I get home, I'm actually going to check on the Win2K box to see if Open With is in the File menu or not. It had better be, but for all the money MS supposedly blows on user testing, they seem to really ignore the test results
That's why headers are only one method to determine file type. In fact, it's about the worst possible method, because it involves a much more significant performance hit, and doesn't always work. (quick -- is a file js, txt, html? -- hard to tell)
Personally I like the Mac and BeOS methods, where information regarding the creator of the file is attached to the file itself. It permits you to have certain files open with certain apps by default, and others of an identical type open with a different app by default. Handy if you write html code in an editor program, and keep archives of web pages that are for display only that open in a browser.
usually it's a good idea to go with belt and suspender solutions.
Nevertheless, you're dodging the issue that you brought up. Before you condemn on that point, you must first determine whether or not the Mac solution (or the BeOS solution, or various other proposals floating about, etc.) are more elegant. If not, why not?
Slashdot Mirror
Easily solved -- some sort of daemon for the palm that can perform housekeeping functions in the background... like replacing 'dickhead' with 'mr. cooper.' Why should you have to remember such a trivial thing? Let the computer handle that mundane crap.
Well, two points.
;) Don't give into brand loyalty if it is disadvantageous for you to do so.
1) Monopolies are not capitalistic. Their closest relationship could be analogized as perhaps cancerous. Monopolies are, by and large, not at all effected by supply/demand curves. Because of the lack of viable alternatives (e.g. if there were only one water company, the fact that it rains doesn't erase the monopoly; rain's not enough) price can be arbitrarily increased, supply arbitrarily restricted, and consumers will, against their best interests, be compelled to continue supporting it.
In order for capitalism to function properly, we need perfect competition. Fully interchangable vendors and consumers. The ability to take advantage of even the slightest niches. Precisely the opposite from what you get with a monopoly. Natural monopolies may be tolerated, but they're not particularly good, and as it turns out, perhaps not as inevitable even in their rare niches, as previously imagined.
2) Screw capitalism. Why do you want capitalism? I would vastly prefer an economic system that was perfectly compatable with notions of justice and humanity and societal goals than capitalism.
Capitalism may be, in part, the closest we have yet come, but it is inherently no more deserving of our support than anything else. That is, adopt a capitalistic approach in choosing economic models!
Furthermore, because we have laws, and desires that may be quite divorced from those of a perfect capitalist (e.g. I have no desire to see children employed in factories because it is inhumane) and we have therefore, the ability to pick certain parts of capitalism that we like (the efficiencies afforded through vigorous total competition, for example) and throw out the bits we don't like (like monopolies) by, in effect, putting our thumb on the scales and weighting it to the side that we most favor.
Thus, not all capitalistic endeavors are permitted. Not because they make economic sense, but because social concerns may be of greater importance. (e.g. not letting people pollute, not letting drugs go out untested, workplace safety standards, antitrust laws, banking regulations....)
Well, if you don't like it, you're going to have to either 1)make an _AMAZING_ case to overturn a finding of fact, which almost never ever happens or 2)redesign the entire American legal system from the ground up.
Like it or lump it, trial courts find facts, and all any appellate court in the nation can do is to determine if the law was properly applied to those unchangable facts. No one really even bothers making arguments on appeal regarding the facts -- it's a guaranteed loser.
Deal with the fact that they are a monopoly. You want to defend them -- you're going to have to find some way to do it that accounts for that. It's entirely possible. ATT was a monopoly in the 20's IIRC, and lasted for ~60 years with no more problems than being denied the ability to move into different markets, and strict governmental regulation. Then they elected to go with a breakup route and discovered, to their chagrin, that competition was a damn lot better for everyone.
MS ought to be thrilled about the possibility of a breakup -- it's better in the long run. But I could live with merely handing over the reins to the courts and Congress, if I must.
Perfectly good company? We're talking about MS here, you know. They've been found in court to be anything but a perfectly good company.
And that tool would be Snitch, I know.
There are flaws with the Mac way, but most of them revolve around the implementation, and not the idea, AFAICT. The codes should be fully human readable. (one way or another) Better use should be made of widgets in selecting codes. Additional granularity should be built in, rather like BeOS. (where a file is simultaneously known to be text, ascii text, html, and js, because it matches all of those in some way) Type codes should be more standardized between apps. Alternate creators: e.g. if there's no Photoshop, try Graphics Editor. Suffixes to be added on export from the system. Etc.
It's actually a bad idea, 99% of the time to change type -- it is really supposed to mesh with the format of the file. Changing creator is comparatively minor, but the system ought to make it so easy to change to another creator that is compatable with that file that it is rare to need to exercise the ability to change it to anything at all.
The point is marginally moot at the moment, because I'm no longer at my old job, where this came up. But it is still a highly desirable feature for me.
/work/index.html in BBEdit, and I will always open /fic/index.html in IE, there's no reason to make me choose which one I will have to assume a permanent burden of manually opening.
I used to write html for a living, and so I needed a bunch of html files that would open in my preferred editor by default. While I would preview them, I edited them far more, and could just hit some keys in the editor to preview in the browser anyway.
However, because I'm really lazy, and enjoy reading, I used to download fiction in html and plain text format, and read it. I never edited it. (perhaps only once when I first dl'd it, to strip out some junk at the top and bottom) And I preferred reading it in a web browser, because I could wham the space key, and page down. (were I looking at it in an editor, I'd have to hit the smaller pagedown key, and be careful not to hit any letter keys, as they'd pop the view back to the cursor location and change the file, neither of which I wanted)
And I hate having to explicitly open any of my files in some program that's not their default, unless it's something I want to do. Since I will always open
There are other situations where this comes up. (picture viewers v. photoshop) Enjoy.
Well, allow me then to append a caveat that I ought to have added anyway. It's dumb to actually roll out UIs that have not been tested, revised, and retested very frequently, from the very beginning.
So given these comments, it implies that a better algorithim controlling the autocomplete is in order. But I'm still drawn to the idea, I have to admit. Academic though it is, however... I have no ability to make one.
I disagree regarding shells, though. Honestly, the point of open standards is supposed to be that people can improve on one anothers' work if able to. Yet terminals have not substantially changed -- or gotten easier to use, which is a shame, because they're important and powerful -- since probably the late 70's. I think it has a lot more to do with preconceived notions of what a terminal is, than actual technical difficulties.
(what's the worst thing that happens -- release the standard to use the GUI shell, tweak the fairly standard utilities like ls and chmod, etc. and let people modify their own if they care, and if not, let people type it in as normal...)
Yep. On all counts, actually. You're an unusually perceptive AC, I've got to say.
Nevertheless, I'm totally right on this one. (although I am willing to allow that there are multiple methods by which we can accomplish the task of the computer more or less reading the mind of the user)
Do me a favor, and discover why it is that the computer should have to handle the busy work of remembering file associations. Set the association for a file type you use a lot to a program you hate, and never use. Then force yourself to have to right click on it all the time.
Would you feel better if only half of your files were that annoying? Would it not be superior for NONE of your files to be that annoying, barring unusual circumstances?
Because I would _always_ have to right click. If I slipped up and accidently double clicked, I'd waste time. Even if I go through the hassle, mentally and temporally of doing the Open With thing, it would become tedious in, curiously, 0.5 seconds.
Computers are supposed to make our lives easier dammit. Why should I have to waste my precious time and thought cycles when I know for a fact that for the given file I will NEVER open it in the otherwise default app. Never ever. Users should not have to assume the computer's role. They should not be burdened with keeping track of and performing repetitive actions. It's even more useless than the godawful Print dialog.
Actually, on a Mac, a file is reassociated with the last app to SAVE the file. Opening has no effect. (with a few rare exceptions -- MacAST has an option to do it on an open)
But of course, a file having a particular binding does not have ANY effect at all on alternative methods of opening it, e.g. through Open dialogs. So this is better than your CLI example. You can _still_ explicitly open a file with a particular application. But if there's one that is used more than the others, you can bind it, and that's the default. It has the ability to work out faster, and in the worst case, is no slower.
What's wrong with the Mac metadata scheme, BTW? I realize that HFS+ isn't the greatest filesystem... But BFS, NTFS, HFS+ and XFS all have their different appealing points. Could you be more specific?
Oh, a number had been canned all through the 90's, ever since System 7 finally came out. (plus, to add insult to injury, the trigger for the Blue Meanies' ULTIMATE easter egg was removed. Bastards!)
But yeah, basically, Steve is supreme. Hell, the stupid bastard didn't even understand the benefits of GUIs until the two PARC trips were arranged SOLELY for his benefit. Everyone else had gotten it -- but not him. (then he thought it was his own idea... jeesh)
However, I think that a combination of modified popup folders and spring loaded folders would make a better Apple menu than the Apple menu itself. It's too long to discuss here, but look for my posts on Ars Open Forum for more details
Tabs blow. Compare tab autocomplete to the autocomplete found in most browser URL fields. The latter blows it away.
I mean, why do so many people seem to think that terminals must be bad imitations of 60's era teletypes? Brain damage from sitting in front of CRTs all day long? Throw in some GUI widgets... they'll do wonders. I'd frickin' love to right-click on a command like LS and have additional options be selectable, which insert themselves in between the command and the pattern. But God forbid, huh?
But that's better, really.
If I open file FRED.FOO with the FOO program 90% of the time, and with the BAR program 10% of the time, it makes sense for it to default to FOO.
If I open file BARNEY.FOO with the BAR program 90% of the time, and with the FOO program 10% of the time, it makes sense for it to default to BAR.
Even though the files are identical in data and format. Otherwise you are subjecting the user to the hassle of using a slower opening method (e.g. drag and drop, Open menus) for the 90% of the time that they open that file that doesn't conform to the overall rule. And that rule itself may be unclear, if there's a fairly even split of files set for FOO and BAR
Heh. It's been called metadata for ages. Longer than I can remember. It's a pretty predictable moniker for anyone to come up with, and probably predates any of us. (file NAMES are metadata, for God's sake... they've been around for many decades)
Ideally, as John pointed out, you adopt a multi-pronged approach. The stored metadata is primarily a cache for performance purposes. It can be erroneous, but ideally it should be checked once (usually as an incidental thing the user is doing) and then left alone. As fallbacks, you can examine the file for magic numbers, as Unix does, or just admit it, and ask the user.
BeOS and MacOS have had the best methods, combined with the Unix magic numbers as a method of last resort. Large disks, and forked files could permit definition forks to accompany files invisibly and at almost no performance penalty. Better behaved apps that recognize these things via APIs, and some affordance for backwards compatability in recognizing legacy extensions and codes would all be good starting places
Er, no. Resource forks are functionally equivalent to NTFS streams, and features Linus has called for in Linux. Think of it as a very low-level support for tarring files together. There's a data file, and a resource file, and they wind up sharing the same icon and metadata as far as the user can tell. They are joined at the hip, though in fact seperate entities. They are not metadata, they _are_ data.
Creator/Type bindings are stored in the filesystem proper, and are basically the same type of thing as filename (not stored in the file, but associated with it!) modification date, read/write permissions, etc.
There was a good article on ArsTechnica a while back about this sort of thing. Read it; it's very good.
Law is of course, applicable. The reasons we don't have 'KILL PATIENT NOW' buttons on medical software UI is not entirely market-driven, you know. There's nothing whatsoever special about software as distinguished from any other product people make, no matter how high an opinion of themselves technical people may think.
(e.g. the term 'boilerplate' derives from the practice of boiler manufacturers of putting disclaimers on their products to avoid responsibility when they exploded and killed people... this wasn't really the greatest solution in the world to boiler explosions, as I'm sure you'll agree. It is mirrored eerily in the realm of software, however.
Because FIRST, those commands should be in the main menu. That way there is an alternative, more visible means for newbie users to get to them. Contextual menus are great, but they must not be the only means of accessing a particular command. (even if they are often a more efficient way; not everyone is efficient)
So yeah, I love 2dary mouse buttons. As an option that I can use or ignore at my lesiure.
Why? They can both coexist. Or you can choose to have some files open in one (e.g. html files I am involved in writing open in BBEdit) or others in a different app. (e.g. html files I keep around for readin' purposes open in IE)
BeOS was, I understand, pretty elegant about this. There was a default type generally, but any specific file could have a specific creator associated with it alone.
What if you create all your html files in a text editor, save them, and want to open them back up in a text editor? Except for the hundreds of megabytes of html files you download off the net and NEVER edit, of course.
I really loathe the Windows 'either/or' proposition. I have some files I edit by default, and some files I only read by default, and I do not want them opening in the same program when I double-click, despite the total lack of difference in the structure or content. Drag and drop, using the Open, or Open With commands to more explicitly choose the app to open a file with on an infrequent basis is great, no problem. Making me do it routinely, forever, on files that I will _never_ open with a 'default' program, is an exercise in extreme annoyance
Plainly, you cannot restore the resources. They're GONE. It is as foolish to think that it is possible to do so as it would be to use notepad to delete the contents of notepad.exe and then try to run it.
Nevertheless, resources are a really good idea.* So good that they're in NTFS, under the moniker 'Streams.' Since most Mac software automatically encodes dual-forked files to preserve the data as it is sent out, and decodes it as it comes back in, it is almost never a problem. Ironically however, if you send a streamed file from an NTFS volume to a FAT volume, the data will simply be lost, with no automagic encoding method employed.
*and yeah, forks _are_ a good idea. Basically it is taking the messy-ass contents of an application folder (e.g. MS Office) and tarring them all together into a single file that nevertheless runs when you click on it. Had they only integrated a decent feature into the finder to probe around in the contents reasonably, it would've kicked ass and taken names. I'm still fond of forked files
Oh yeah, four bytes is eight-billion times worse than _three_ bytes. You betcha.
Yeah, there are stupid technical reasons dating back to the early eighties for the four byte codes. (though there were some funny hacks that you could perform with them as well) Something more readable really _would_ be better, through a sham if necessary, but ideally right in the fs, a la BeOS. (though MIME itself is not as readable as would yet be preferred)
Really? Wow. One wonders how drag and drop, the open dialog, the save as dialog, etc. all operate then.... (Incidentally, ResEdit is by Apple, and therefore a first-party program -- or is it second party? -- well not third, at any rate)
Open With is okay for ocassional use, and I'd like to see it on the Mac. I'd like to see Snitch-like functionality integrated with the Finder. But of course, retaining creator metadata is a _great_ idea as well....
Really the problem is not with right clicking, per se. Contextual menus are in fact, a really good idea. There was never any particular reason at Apple for the one button rule, other than that Raskin hadn't predicted the eventual need for added functionality (e.g. shift-drag for multiple discontiginous select) and didn't like the old PARC methodology, which relied almost completely on menus. (e.g. there was no concept of dragging icons places, by and large)
Before you go spouting off the old myths about user testing to determine the number of buttons, GO READ UP. There are _frickin'_ interviews with Raskin, with people that designed the mice, etc. that plainly show that the decision was made before there had been any testing, or even software _to_ test. (the Stanford pages are a godsend for this)
Anyway though, the main problem Windows has always had is that there were typically commands that could only be accessed contextually. That's a big dumb mistake, and one that Apple's HIG specifically addresses. Contextual commands should invariably be available in the menus anyway, so that the UI pillar of 'multiple ways to do things' is properly employed. When I get home, I'm actually going to check on the Win2K box to see if Open With is in the File menu or not. It had better be, but for all the money MS supposedly blows on user testing, they seem to really ignore the test results
That's why headers are only one method to determine file type. In fact, it's about the worst possible method, because it involves a much more significant performance hit, and doesn't always work. (quick -- is a file js, txt, html? -- hard to tell)
Personally I like the Mac and BeOS methods, where information regarding the creator of the file is attached to the file itself. It permits you to have certain files open with certain apps by default, and others of an identical type open with a different app by default. Handy if you write html code in an editor program, and keep archives of web pages that are for display only that open in a browser.
usually it's a good idea to go with belt and suspender solutions.
Nevertheless, you're dodging the issue that you brought up. Before you condemn on that point, you must first determine whether or not the Mac solution (or the BeOS solution, or various other proposals floating about, etc.) are more elegant. If not, why not?