Finder disappointment
in [UK Mac]
|
Prev: Do Vodafone speak English?
Next: Label printing
From: Rowland McDonnell on 11 Aug 2010 17:45 Tim Streater <timstreater(a)waitrose.com> wrote: [snip] > I didn't think we did paths in OS X. [snip] I don't know the details of this sort of thing, but: Paths and filename extensions used to be more or less irrelevant from the point of view of the MacOS *before* MacOS X. (and if you had an original Mac with the MFS filing system, you actually had a completely flat filing system - folders weren't directories, merely a convenience for the user and invisble to the actual filing system as such. You can look up when HFS appeared as easily as I can, I suspect...) Filename extensions are now the only way MacOS X 10.6 works out what to do with a file (boo, hiss). And I'd not be surprised if, by the same token, paths are now significant to this and that. Certainly they are when dealing with some `normal' Unix software ported to Macs that I've used on OS X. Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: David Empson on 11 Aug 2010 21:46 Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > Tim Streater <timstreater(a)waitrose.com> wrote: > > [snip] > > > I didn't think we did paths in OS X. > [snip] > > I don't know the details of this sort of thing, but: > > Paths and filename extensions used to be more or less irrelevant from > the point of view of the MacOS *before* MacOS X. > > (and if you had an original Mac with the MFS filing system, you actually > had a completely flat filing system - folders weren't directories, > merely a convenience for the user and invisble to the actual filing > system as such. You can look up when HFS appeared as easily as I can, I > suspect...) The Mac OS X Finder has changed the user interface to be based around the concept of a browser, and it supports features like column view (which are explicitly based on absolute paths), so it doesn't surprise me if open windows exhibit this behaviour. The window is effectively showing a file:/// URL, and part of the URL no longer exists. > Filename extensions are now the only way MacOS X 10.6 works out what to > do with a file (boo, hiss). The file type is still supported, you can assign individual files to specific applications, and there are mechanisms based on other metadata attached to files (details of which elude me at present). The only change in 10.6 in this area is is that the creator code is ignored. Even that one change is enough for me to agree with you on the "boo, hiss" front. > And I'd not be surprised if, by the same token, paths are now > significant to this and that. Certainly they are when dealing with some > `normal' Unix software ported to Macs that I've used on OS X. There is a difference in behaviour between Mac-specific aliases (which are used in alias files and internally by many applications), and text-based pathnames (used in symbolic links, which are common in Unix). Aliases to files on an HFS or HFS+ volume can track a file or folder as it moves around within a volume or it or any parent is renamed, by referencing the unique file ID, parent folder ID and other clues. It only reverts to behaving like an absolute pathname if the file or a parent is deleted. Symbolic links reference an absolute path and won't follow a file or folder which is renamed or moved. -- David Empson dempson(a)actrix.gen.nz
From: Rowland McDonnell on 12 Aug 2010 04:12 David Empson <dempson(a)actrix.gen.nz> wrote: > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > > > Tim Streater <timstreater(a)waitrose.com> wrote: > > > > [snip] > > > > > I didn't think we did paths in OS X. > > [snip] > > > > I don't know the details of this sort of thing, but: > > > > Paths and filename extensions used to be more or less irrelevant from > > the point of view of the MacOS *before* MacOS X. > > > > (and if you had an original Mac with the MFS filing system, you actually > > had a completely flat filing system - folders weren't directories, > > merely a convenience for the user and invisble to the actual filing > > system as such. You can look up when HFS appeared as easily as I can, I > > suspect...) > > The Mac OS X Finder has changed the user interface to be based around > the concept of a browser, You wot? The `concept' is just what it always was, from what I can tell. I recall quotes from Apple bods say that they couldn't understand why MS was moving towards a `browser' type interface for its `Finder-stand-in'. I don't think you're at all right on this. > and it supports features like column view > (which are explicitly based on absolute paths), Eh? NThey are based on files, surely? - they show you the path to the file. It's based on the filing system, and the column view is simply a convenience for the user which could just have well have been implemented with System 7. Or so it seems to me. > so it doesn't surprise > me if open windows exhibit this behaviour. Which behaviour do you mean? > The window is effectively > showing a file:/// URL, and part of the URL no longer exists. Given that the Finder has a pointer to the file itself, and can look up the path to that file, it could have been written to update column view on the fly when things like that change. But that would not be done, because it would be very confusing for the user especially since the are in general multiple items in the final column so the Finder couldn't guess which *one* it was you still want to be looking at if anything changes, sortathing. > > Filename extensions are now the only way MacOS X 10.6 works out what to > > do with a file (boo, hiss). > > The file type is still supported, You get one file type per file extension, so we've really only get extensions (in effect), surely? > you can assign individual files to > specific applications, Which works only until you do some maintenance or upgrading, then it breaks. Waste of bloody time, like the old `Comment' field in Finder info boxes. > and there are mechanisms based on other metadata > attached to files (details of which elude me at present). The only > change in 10.6 in this area is is that the creator code is ignored. > > Even that one change is enough for me to agree with you on the "boo, > hiss" front. It's broken the MacOS in a lot of ways if you ask me - made my use of my Mac a *LOT* less convenient. I don't want *.log files to open in bloody Console just because they're *.log files. I want *those* *.log files to open in TeXShop, thanks - where they belong... Etc., etc. > > And I'd not be surprised if, by the same token, paths are now > > significant to this and that. Certainly they are when dealing with some > > `normal' Unix software ported to Macs that I've used on OS X. > > There is a difference in behaviour between Mac-specific aliases (which > are used in alias files and internally by many applications), and > text-based pathnames (used in symbolic links, which are common in Unix). Your reference to `aliases' is confusing - what sort of alias? The sort of alias we see in the Finder, the *different* sort of alias used by Applescript, or something else entirely? > Aliases to files on an HFS or HFS+ volume can track a file or folder as > it moves around within a volume or it or any parent is renamed, by > referencing the unique file ID, parent folder ID and other clues. It > only reverts to behaving like an absolute pathname if the file or a > parent is deleted. > > Symbolic links reference an absolute path and won't follow a file or > folder which is renamed or moved. Uhuh. Ta, Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
From: David Empson on 12 Aug 2010 05:35 Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > David Empson <dempson(a)actrix.gen.nz> wrote: > > > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > > > > > Tim Streater <timstreater(a)waitrose.com> wrote: > > > > > > [snip] > > > > > > > I didn't think we did paths in OS X. > > > [snip] > > > > > > I don't know the details of this sort of thing, but: > > > > > > Paths and filename extensions used to be more or less irrelevant from > > > the point of view of the MacOS *before* MacOS X. > > > > > > (and if you had an original Mac with the MFS filing system, you actually > > > had a completely flat filing system - folders weren't directories, > > > merely a convenience for the user and invisble to the actual filing > > > system as such. You can look up when HFS appeared as easily as I can, I > > > suspect...) > > > > The Mac OS X Finder has changed the user interface to be based around > > the concept of a browser, > > You wot? > > The `concept' is just what it always was, from what I can tell. No it isn't. Mac OS 9's Finder was entirely based around spatial principles, remembering the view for each folder, down to the window position, icon positions, scroll bars, etc. If you open a particular folder, the window will open in the same place it was most recently located with the same view you last used. Mac OS X's Finder has completely broken that concept. Each Finder window is a file system browser. You can put it back into something vaguely like Mac OS 9 Finder mode by clicking on the tool in the top right corner, which hides the toolbar and sidebar. More recent versions of Mac OS X have progressively broken more aspects of this, so it is effectively useless if you want Mac OS 9 Finder behaviour. > I recall quotes from Apple bods say that they couldn't understand why MS > was moving towards a `browser' type interface for its `Finder-stand-in'. That must be a pre-Mac OS X quote. > I don't think you're at all right on this. > > > and it supports features like column view > > (which are explicitly based on absolute paths), > > Eh? NThey are based on files, surely? - they show you the path to the > file. The columns show the path within the file system, from the starting point on the left side up to the currently selected folder in the rightmost column. It is explicitly showing you the path, with one element of the path per column. > It's based on the filing system, and the column view is simply a > convenience for the user which could just have well have been > implemented with System 7. > > Or so it seems to me. > > > so it doesn't surprise > > me if open windows exhibit this behaviour. > > Which behaviour do you mean? The problem described in the original post, where moving a folder causes another Finder window which was displaying a subfolder to suddenly revert to showing the generic "computer" view (or a different folder higher up on the path). > > The window is effectively > > showing a file:/// URL, and part of the URL no longer exists. > > Given that the Finder has a pointer to the file itself, and can look up > the path to that file, it could have been written to update column view > on the fly when things like that change. But it isn't. Each window is independently showing a particular folder by pathname, and if the path suddenly stops existing (because you've moved a parent folder) the window jumps to show a different folder. > But that would not be done, because it would be very confusing for the > user especially since the are in general multiple items in the final > column so the Finder couldn't guess which *one* it was you still want to > be looking at if anything changes, sortathing. > > > > Filename extensions are now the only way MacOS X 10.6 works out what to > > > do with a file (boo, hiss). > > > > The file type is still supported, > > You get one file type per file extension, so we've really only get > extensions (in effect), surely? No, if you have a file without an extension, but it does have a traditional Mac OS file type assigned to it, that file type will be used to select a suitable application to launch. The extension is higher priority, so the file type is only meaningful if the filename has no extension. > > you can assign individual files to specific applications, > > Which works only until you do some maintenance or upgrading, then it > breaks. Waste of bloody time, like the old `Comment' field in Finder > info boxes. > > > and there are mechanisms based on other metadata > > attached to files (details of which elude me at present). The only > > change in 10.6 in this area is is that the creator code is ignored. > > > > Even that one change is enough for me to agree with you on the "boo, > > hiss" front. > > It's broken the MacOS in a lot of ways if you ask me - made my use of my > Mac a *LOT* less convenient. I don't want *.log files to open in bloody > Console just because they're *.log files. > > I want *those* *.log files to open in TeXShop, thanks - where they > belong... > > Etc., etc. > > > > And I'd not be surprised if, by the same token, paths are now > > > significant to this and that. Certainly they are when dealing with some > > > `normal' Unix software ported to Macs that I've used on OS X. > > > > There is a difference in behaviour between Mac-specific aliases (which > > are used in alias files and internally by many applications), and > > text-based pathnames (used in symbolic links, which are common in Unix). > > Your reference to `aliases' is confusing - what sort of alias? The sort > of alias we see in the Finder, the *different* sort of alias used by > Applescript, or something else entirely? They are all more or less the same thing. An alias file as shown by Finder contains an alias resource, which is what AppleScript is using (as are most Mac-native applications which keep track of files via aliases internally). > > Aliases to files on an HFS or HFS+ volume can track a file or folder as > > it moves around within a volume or it or any parent is renamed, by > > referencing the unique file ID, parent folder ID and other clues. It > > only reverts to behaving like an absolute pathname if the file or a > > parent is deleted. > > > > Symbolic links reference an absolute path and won't follow a file or > > folder which is renamed or moved. > > Uhuh. > > Ta, > Rowland. -- David Empson dempson(a)actrix.gen.nz
From: Rowland McDonnell on 12 Aug 2010 08:47 David Empson <dempson(a)actrix.gen.nz> wrote: > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > > > David Empson <dempson(a)actrix.gen.nz> wrote: > > > > > Rowland McDonnell <real-address-in-sig(a)flur.bltigibbet.invalid> wrote: > > > > > > > Tim Streater <timstreater(a)waitrose.com> wrote: > > > > > > > > [snip] > > > > > > > > > I didn't think we did paths in OS X. > > > > [snip] > > > > > > > > I don't know the details of this sort of thing, but: > > > > > > > > Paths and filename extensions used to be more or less irrelevant from > > > > the point of view of the MacOS *before* MacOS X. > > > > > > > > (and if you had an original Mac with the MFS filing system, you actually > > > > had a completely flat filing system - folders weren't directories, > > > > merely a convenience for the user and invisble to the actual filing > > > > system as such. You can look up when HFS appeared as easily as I can, I > > > > suspect...) > > > > > > The Mac OS X Finder has changed the user interface to be based around > > > the concept of a browser, > > > > You wot? > > > > The `concept' is just what it always was, from what I can tell. > > No it isn't. Mac OS 9's Finder was entirely based around spatial > principles, remembering the view for each folder, down to the window > position, icon positions, scroll bars, etc. If you open a particular > folder, the window will open in the same place it was most recently > located with the same view you last used. And does MacOS X not do that? Okay, I've noticed that views in windows seem to change when I don't want them to - not quite figured out what's what yet. > Mac OS X's Finder has completely broken that concept. Each Finder window > is a file system browser. What does that mean? > You can put it back into something vaguely like Mac OS 9 Finder mode by > clicking on the tool in the top right corner, which hides the toolbar > and sidebar. More recent versions of Mac OS X have progressively broken > more aspects of this, so it is effectively useless if you want Mac OS 9 > Finder behaviour. <shrug> I dunno. > > I recall quotes from Apple bods say that they couldn't understand why MS > > was moving towards a `browser' type interface for its `Finder-stand-in'. > > That must be a pre-Mac OS X quote. Could well have been. > > I don't think you're at all right on this. > > > > > and it supports features like column view > > > (which are explicitly based on absolute paths), > > > > Eh? NThey are based on files, surely? - they show you the path to the > > file. > > The columns show the path within the file system, from the starting > point on the left side up to the currently selected folder in the > rightmost column. It is explicitly showing you the path, with one > element of the path per column. Erm, yeah - showing you that information, for sure. So? > > It's based on the filing system, and the column view is simply a > > convenience for the user which could just have well have been > > implemented with System 7. > > > > Or so it seems to me. > > > > > so it doesn't surprise > > > me if open windows exhibit this behaviour. > > > > Which behaviour do you mean? > > The problem described in the original post, where moving a folder causes > another Finder window which was displaying a subfolder to suddenly > revert to showing the generic "computer" view (or a different folder > higher up on the path). Righto. > > > The window is effectively > > > showing a file:/// URL, and part of the URL no longer exists. > > > > Given that the Finder has a pointer to the file itself, and can look up > > the path to that file, it could have been written to update column view > > on the fly when things like that change. > > But it isn't. Seemingly so - but I don't see why it has to be this way, except for programming convenience. > Each window is independently showing a particular folder > by pathname, Right - now, how do you know that that's what is being done under the bonnet, so to speak? > and if the path suddenly stops existing (because you've > moved a parent folder) the window jumps to show a different folder. More like `no folder at all, just the top level `computer' place: / in Unix terms, yes? > > But that would not be done, because it would be very confusing for the > > user especially since the are in general multiple items in the final > > column so the Finder couldn't guess which *one* it was you still want to > > be looking at if anything changes, sortathing. > > > > > > Filename extensions are now the only way MacOS X 10.6 works out what to > > > > do with a file (boo, hiss). > > > > > > The file type is still supported, > > > > You get one file type per file extension, so we've really only get > > extensions (in effect), surely? > > No, if you have a file without an extension, but it does have a > traditional Mac OS file type assigned to it, that file type will be used > to select a suitable application to launch. Oh! I didn't know that. > The extension is higher priority, so the file type is only meaningful if > the filename has no extension. Damn. But not totally useless, I suppose. So it's not as bad as I'd thought. [snip] > > > > And I'd not be surprised if, by the same token, paths are now > > > > significant to this and that. Certainly they are when dealing with some > > > > `normal' Unix software ported to Macs that I've used on OS X. > > > > > > There is a difference in behaviour between Mac-specific aliases (which > > > are used in alias files and internally by many applications), and > > > text-based pathnames (used in symbolic links, which are common in Unix). > > > > Your reference to `aliases' is confusing - what sort of alias? The sort > > of alias we see in the Finder, the *different* sort of alias used by > > Applescript, or something else entirely? > > They are all more or less the same thing. An alias file as shown by > Finder contains an alias resource, which is what AppleScript is using > (as are most Mac-native applications which keep track of files via > aliases internally). Argh. Every explanation I've read of aliases with respect to Applescript has confused me further, because they've all said something slightly different. Most have claimed that the aliases inside Applescript are totally unrelated to Finder aliases. Now I find that's bollocks, and you've just displayed some information that suddenly makes things start to make sense. At bloody last - thank you. I should have been Jewish, because I need to say `Oi vey' and that's just wrong if you're not Jewish, innit? [snip] Rowland. -- Remove the animal for email address: rowland.mcdonnell(a)dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking
|
Pages: 1 Prev: Do Vodafone speak English? Next: Label printing |