I've been building AppleScripts to get and set the positions of file icons, either on the desktop or in a Finder window, and to get and set the default application that opens any specific file.
It was only after I had been working on this off and on for over a month, that I found out about the Get/Set File Attributes actions. I had also been getting and setting the comments attribute/property of files using AppleScript, and it was a pleasure to discover that KBM can do that one itself. So why not the other two?
Here is the list of the File Attributes that the Get File Attribute action can read, and most of them, except the ones marked "(r/o)" can be set by KBM too. Does it seem odd that position and default application are missing from this list? It does to me.
File attributes available
file type (r/o) (Directory, Package, File, Symlink, Socket, Character Special, Block Special, or Unknown).
It's a property that is only available when its containing window is open and focused. As such, it wouldn't be accessible in the background like all other attributes in the KM actions, so I think AS is always going to be the way.
What that says to me is that the icon view of that folder has to be open somewhere for the position property to be retrievable. Or does it simply have to generate an Icon View to populate the parameter and then the value can be retrieved?
Tests come to mind:
Open the Finder window, make sure it's in Icon View, move to a different Desktop, run the script to list positions of the window. It should list all positions.
Change the view to List View, move to a different Desktop, run the script. Does it still list positions?
Run the test again with Icon View, then close the Finder window and run it again. AppleScript should still be able to list the files in the folder, even with the Finder window closed, but do the position values disappear?
(Unfortunately, I won't be testing this myself until maybe late tonight.)
Is this what produced your "(-1,-1)" erroneous result that you originally thought was too many files?
No. It seems to be ok for most folders, but the Applications folder is one example where it doesn't work, and I don't know why.
I don't see many practical applications of this, outside of your very esoteric requirements, not least because it doesn't return any usable coordinates. These coordinates are relative to the top-left corner of the icon space, not the front window or screen.
It's a shame, because if they were more usable, it would give us a nice neat way to automate clicking and dragging files from Finder windows into app windows that doesn't rely on found images.
BUT I had my Icon View of my folder set to "Hide Tab Bar" and "Hide Toolbar" (which also hides the Sidebar), so the two points in your diagram above are the same. With that display change, I am easily able to draw a rectangle around the chosen icon.
So is there some way to find out how much space the Toolbar takes in Y, how much the Sidebar takes in X, and the Tab Bar takes in Y, and adjust accordingly?
The "Window Related Tokens" page in the WIki makes it look like the token %WindowFrame% has four values in it, the first two are %WindowPosition% and the second two are %WindowSize%. The implication in the WIki is that those are the same values.
I'm sure that I've seem parameters somewhere that separate the center active area of a window from the toolbar, sidebar, status bar, etc. at the top, bottom, and sides. Is that possibly accessible via AppleScript? I'm not finding that distinction in KBM anywhere. Is it in the OS UI controls or am I thinking of HTML?
OK, I think I have a rationale for this behavior. It is entirely possible to have the same folder open in multiple Finder windows, in this desktop, in other desktops, in tabs of Finder windows, in List View, in Icon View, etc., all at the same time. Each window can be sorted in its own way, or manually arranged. So it would be meaningless or impossible (I'm not sure which) to attempt to provide the position property for any Finder window other than the active window in the immediate desktop in Icon View. To attempt anything else opens up too many possibilites for ambiguity.
The problem with coordinates relative to the icon space is:
Say you have a folder containing a large number of files, and the one whose position you want is so far down the file list that you need to scroll down in the Finder window to see its icon.
Coordinates relative to the screen/window corner will be able to click it. However, coordinates relative to the corner of the icon space won't, because that corner is quite a distance away from the icon. It might return something like 400,12000 if it's a really long list with large icons, and the click would end up off the bottom of the screen.
For the specific purpose that I'm currently working on, I am simply making sure that the Finder window is large enough that all icons are visible. But to address the general case, as Peter would have to if he was making this property accessible from KBM, could get complicated and confusing real fast.
