mir scheints fast, dass du da nur mit objc an die scripting bridge dran kommst.allerdings fragt man in objc auch nur "mal eben" ab, ob itunes rennt und macht dann die aktionen. eigentlich müsste dann da dasselbe passieren, wenn der man die scripting bridge zur falschen zeit abfragt.
Testing for Launched Applications
If an application isn’t executing when Scripting Bridge tries to send it an Apple event, Scripting Bridge may automatically launch it. The launch of the other application may come as a surprise to your users, along with the fact that you application’s execution is blocked while the other application is launching.
Because of these potential surprises, it’s often a good idea to check whether the target application is running before you try to communicate with a Scripting Bridge message. Suppose you want to get the name of the current track, but only if iTunes is running. You could accomplish by first testing for application execution with the isRunning of SBApplication, as shown in Listing 3-4.
Listing 3-4 Testing for application execution
- (NSString *) nameOfCurrentTrack
{
// "iTunes" is an instance variable
if ([iTunes isRunning]) {
return [[iTunes currentTrack] name];
}
return nil;
}
mit applescript, ruby und perl hab ich es jetzt nicht geschafft 100% immer dafür zu sorgen, dass itunes nicht nochmal startet. wenn du, egal in welcher sprache, die scripting bridge zur falschen zeit ansprichst, startet itunes neu. wenn da jemand ne 100% lösung dafür hat: her damit.
mit ist beim testen aufgefallen, dass itunes länger für den shutdown braucht, wenn man es im status "playing" schließt. wenn ich status "stopped" habe, habe ich keinen relaunch bekommen - wahrscheinlich habe ich aber nicht den richtigen moment getroffen, um den relaunch triggern.
mit applescript (ruby & python) lässt sich das, uhm, "risiko des relaunches" also höchstend minimieren, nicht ausschließen. scheinbar.
ha! witzig. mit ist grad beim exzessiven testen aufgefallen, dass apps, die eigentlich die oben genannte objc methode nutzen müssten (apps sind ebenfalls oben genannt), um die infos von itunes zu bekommen, durchaus ebenfalls in der lage sind, die scripting bridge genau im falschen moment anzusprechen, so dass itunes neu startet.
ich hab trotzdem ne methode gefunden, wie man es evtl funktionieren _könnte_. ist aber ein ganz schönes gewurschtel.
1. du schreibst dir n applescript und speicherst es als app mit der "stay open" option. mit folgendem inhalt (natürlich angepasst, ist jetzt nur ein beispiel - you'll get the point):
Code:
on run
-wenn's startet
showittrackname()
end run
on idle
--wenn's nix zu tun hat
delay 10
showittrackname()
end idle
on quit
--wenn's beendet wird
tell application "iTunes" to quit
continue quit
end quit
on reopen
--wenn focus weg war und es den focus zurückbekommt
tell application "iTunes" to activate
end reopen
on showittrackname()
repeat
try
tell application "iTunes" to set cs to name of current track
exit repeat
on error
tell application "iTunes" to play
end try
end repeat
try
display dialog cs giving up after 5
on error
tell me to quit
end try
end showittrackname
2. jetzt launchst du itunes nicht über itunes.app, sondern über die so erstellte app. das app launcht dann itunes.
3. das app passt du natürlich so an, dass es dir nicht ständig einen dialog mit dem namen vom current track anzeigt, das nervt eh nur
, sondern dass es die die infos die du für das nerdtool brauchst irgendwohin legt, so dass du dann mit dem nerdtool bequem auf diese zugreifen kannst.
4. du remapst dir die keys für itunes so, dass quit nicht mehr cmd+q ist. statdessen legste dir ein service oder so an den du bei itunes mit cmd+q triggerst. dieser service tut dann nix anderes, als das script zu beenden. ich weiß aber jetzt nicht, ob dich die preferences sowas anstellen lassen. mit so nem tool wie keyboard maestro oder quickeys würde es funktionieren (der remap von cmd+q). wobei mit solchen tools bräuchtest du das gar nicht, weil diese auch das quit event einer app abfangen können und dann eine aktion ausführen. wenn man das so machen würde, müsste man aber das "tell app itunes to quit" aus dem on quit handler rausschmeißen, sonst findet das wahrscheinlich doppelt statt. allgemein könnte man sich das leben mit so nem tool ziemlich vereinfachen, da die auch den open event erkennen. dann lässt man das script einfach mitstarten und alles andere bleibt einfach so, wie es ist.
5. das script selbst, wie du dem code entnehmen kannst, beendet erst itunes und dann sich selbst.
6. wenn du das script dann im dock nicht sehen willst, müsstest du in seiner info.plist noch "lsuielement" hinzufügen und auf true setzen.
natürlich müsste man das script noch um einige dinge erweitern, wie z.b. checken, ob itunes läuft und sich selbst beenden, wenn nicht (und zwar ohne itunes zu quitten, sonst startet itunes ja wieder...) usw. müsste man schon noch was reinstecken.
sollte aber eigentlich funktionieren. ohne garantie natürlich, dass es auf lange dauer funzt, hab's nur kurz ausprobiert. aber das restart-problem wäre damit eigentlich erledigt - solange nix anderes auf die scripting bridge zugreift, natürlich.
ist aber doch komplizierter, als ich dachte
