macOS Finder not behaving well under Scripting Bridge

[Daphtdazz]

This is a bit of a long shot, I guess, but I'm writing a utility (in Objective-C) that tidies up my desktop automatically for me. It's all going fine; I use the pretty neat Scripting Bridge framework to communicate with the Finder to get and set positions of icons on the desktop, and whilst the programme is running, all is well.

However, when I quit it I have noticed that Finder will all of a sudden no longer be idling on 0.x percent of CPU usage, but at a rate that seems to be proportional to the amount of use my app has had. I.e, if I've been testing it heavily, when I finish Finder can be idling as much as 80% of CPU (on a dual core iMac, so that's only 40% of what's available of course). Also I've had a couple of alarming crashes as well which seem to have been caused by the Finder, during which attempts to force quit applications fail, the force quit dialogue box is displayed empty until eventually nothing works (the Title Bar tells me Finder is continually active all the time, and is in fact responsive) and I have to do a hard reset.

So, if anyone has had any experience of anything similar and maybe if there's something I should be thinking about (I'm pretty sure by now I'm releasing all my references to the SBElementArrays I'm using properly, but you never know), then that would be very helpful.

Otherwise I may send some Finder traces to Apple and just leave it at that. Will be annoying if I can't actually use my app in the end.

Thanks,
David

EDIT: Should have mentioned I'm running 10.6.2 and it's a 2.4 GHz C2D 2008 20" Alu iMac. No dodgy external hardware attached, as well, and no kernel panics.

 

[hhas]

Try to replicate the problem using AppleScript. If you can, the problem's in Finder so file a bug on that. If not, see my sig.

If you need more advice on Finder scripting, post some code (preferably AppleScript code, as that's what most folks who are best able to help you understand).

 

[kainjow]

I'm pretty sure by now I'm releasing all my references to the SBElementArrays I'm using properly, but you never know

You can know, with Instruments.

EDIT: Should have mentioned I'm running 10.6.2 and it's a 2.4 GHz C2D 2008 20" Alu iMac. No dodgy external hardware attached, as well, and no kernel panics.

If you have access to a 10.5 machine you could test there, to see if it's a bug with SL's Cocoa Finder.

 

[Daphtdazz]

Thanks guys, that's very helpful. I unfortunately don't have access to a Leopard machine, but I've got the disks somewhere so maybe I'll put it on a partition on my iMac when I've got a bit of time and try that theory out. Also thanks for the tip about Instruments. Should have done that by now!

To be honest, part of the way I've implemented my programme uses sending Apple Events to an external script due to the fact that I couldn't for the life of me work out how to get Scripting Bridge to give me a reference to the actual desktop, rather than just (if one existed) a window whose target was the Desktop. So the whole project is pretty messy now. The interface is done with Cocoa, so I can't really try it in pure AppleScript without a huge amount of effort (if that's even possible), but I will see if I can sift out the calls that I make to Finder in a script and see if I can provoke it like that.

Thanks again,
David

 

[hhas]

To be honest, part of the way I've implemented my programme uses sending Apple Events to an external script due to the fact that I couldn't for the life of me work out how to get Scripting Bridge to give me a reference to the actual desktop, rather than just (if one existed) a window whose target was the Desktop.

Some things AS can do SB can't do due to limitations of its design. Some things SB maybe can do, but its syntactic sugar is like molasses in places, making it difficult to figure out how. I won't claim appscript's perfect either, but it's certainly more capable and reliable and less obfuscated than SB.

Another advantage appscript has is that you can use the ASTranslate tool from the appscript website to run commands in AppleScript, and it prints out the resulting Apple events in appscript syntax - very handy when you know how to do something in AS but aren't sure how to convert it to Python/Ruby/ObjC syntax.

 

[Daphtdazz]

+1 for the imperfections of Apple Script... and for the obfuscation of Scripting Bridge!

I just get the feeling, though, that SB is the one that Apple's pushing from now; something to do with the fact that there seem to be no easy links between the Apple Script documentation on the developer site and the Apple Script Studio Programming guide any more. I think Apple is telling us that it sees SB as the future, so my hope is that they will do some work on it to make it at least as capable as AS before too long. I guess AS must still have a lot of legacy stuff going on with Carbon calls etc under the hood, and I think that this is something that may not fit in with Apple's new ethos of slim, simple and efficient programming. As Adobe knows only too well, I think Apple and Steve want to be presiding over the funeral of Carbon before too long (as for Classic...), and I think AS may be collateral in that.

Still, that doesn't solve any of my problems right now! Pity, really...

I'll have a look at that ASTranslate tool, thanks; sounds very useful.

 

[Daphtdazz]

Heh heh, I was able to recreate it using AppleScript...

I ran the following script to simulate what I was doing in my app, i.e. sending lots of events to Finder, and now during a run of about a minute Finder's CPU increased gradually to about 20%, where it has stayed now for the past few minutes without declining, despite the fact that the script is no longer running.

Here's the script:

tell application "Finder"

set allDesktopItems to every item of desktop
set moveForward to false
repeat
if moveForward then
set posOffset to 10
set moveForward to false
else
set posOffset to -10
set moveForward to true
end if

repeat with currItem in allDesktopItems

set currPos to desktop position of currItem
set item 1 of currPos to (item 1 of currPos) + posOffset

set desktop position of currItem to currPos

end repeat

delay 0.5

end repeat

end tell

I think I'll write something to Apple, as this is quite clearly (in my opinion...) not supposed to happen.

David

 

[hhas]

I just get the feeling, though, that SB is the one that Apple's pushing from now;

Not really; SB seems to get about as much attention from Apple as most AppleScript-related APIs on OS X do, i.e. not much. Personally I'm not complaining in this particular case - SB's inferior to AppleScript and barely a credible alternative to it, never mind a viable replacement. (It's the reason I wrote objc-appscript.)

The ASS links have gone because ASS is deprecated in 10.6; the new goodness is AppleScriptObjC, which is a [nearly complete] bridge between AS and ObjC comparable to PyObjC and RubyCocoa. There aren't many links to ASOC yet simply because Apple have yet to write proper documentation for it, so you'll need to make do with Google.

ASOC has the usual quota of rough edges and undocumented quirks, and the learning curve is much fiercer than ASS's since you're dealing directly with Cocoa concepts and APIs, but it's a big step forward over ASS capability-wise.

And AS isn't going anywhere, as the last time Apple floated that suggestion (OS 9-X transition) their publishing-based customers threatened bloody revolt. For better or worse, it's what we're stuck with.