I’ve built a basic applescript studio app that uses command-line programs mplayer and Lame to perform a very specific set of tasks. This is my first applescript studio app, and I’ve run into a number of questions that Google hasn’t been able to answer, so I’m posting here. The app is functional (ie it does what I want it to do) – these questions all relate to improvements I’d like to make to the GUI so that it’s more user-friendly.
1.) Is there a way to include the mplayer and lame executables with the compiled app? If so, how do I reference these particular instances within the applescript?
2.) Is anyone aware of a method to determine available titles and audio streams on a mounted DVD via applescript? I’d like to populate dropdowns based on this info.
3.) Finally, the main function of this app is a command-line based mplayer → lame transcode, which takes about an hour.
I’m initiating this using doshellscript in the applescript code.
Is there a way to make this process interruptable from the GUI?
Any starting points, ideas, or suggestions are very welcome.
Thanks for your time!!
– Adam
Model: Powerbook G4
Browser: Safari
Operating System: Mac OS X (10.4)
Model: Powerbook G4
Browser: Safari
Operating System: Mac OS X (10.4)
Yes. Drag a copy of your binaries to the Desktop (I find it’s just easiest that way - Command -D takes you right there). In you project, click on the Resources folder (when you add a file, it generally will fall right where you are selected). Then choose “Add to project” from the Project menu, hit Cmd-D and select your desiered binary. Make sure in the next drop down sheet you select “Copy items into desitination group’s folder (if needed)” at top, and hit Add. It will get copied automatically into your Resources folder when you build (you may need to clean target first).
You call on your binary like so:
property parent_path : “”
on launch --or some other part of your script
set parent_path to the POSIX path of (path to me as Unicode text)
end launch
set mplayerBinary to the quoted form of parent_path & “Contents/Resources/mplayer”
do shell script mplayerBinary & space & “-v”
I don’t even know if that information is stored on the dvd in the .ifo/.bup files. A quick look through the smallest of the files revealed nothing.
There is a way to pause a process using… ah, it was something like Control-B to background a process and Control-F to foreground it (or Z or something)… not too sure. When you’re bored, you can read the riveting bash manpage. I wouldn’t even know how to send a process such a keystroke though. But keep in mind that if you are doing anything with realmedia, the codec paths are hard wired into the mplayer binary and won’t work.
There are other concerns you need to pay attention to as well if you are going to be packaging this up for others to use: hardwired paths in your binary. Take mplayer sitting on your desktop. Depending on how you compiled it and with what flags, you could wind up with something like this:
otool -L /opt/local/bin/mplayer
/opt/local/bin/mplayer:
/opt/local/lib/libmad.0.dylib (compatibility version 3.0.0, current version 3.1.0)
/opt/local/lib/libmp3lame.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.0.0)
/opt/local/lib/libpng.3.dylib (compatibility version 3.0.0, current version 3.0.0)
/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.2)
/opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0)
/opt/local/lib/libungif.4.dylib (compatibility version 6.0.0, current version 6.3.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 128.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 47.0.0)
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0)
/opt/local/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.2.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 92.0.0)
and if any of those are missing (mine may be a litle heaver than average), your mplayer won’t work for anyone else (even a pitiful mplayer -v will probably bomb out). There are ways around this: like compile flags of LDFLAGS=-headerpad_max_install_names or LDFLAGS=“-Wl,-headerpad,20” for G5 machines, and then you have to use install_name_tool to change the hardwired path to @executable_path@/something to change where it looks for a library. You can also compile statically… And if you depend on the reallibs, those would have to be included as well (a touchy issue considering their non-gpl license - that’s why it isn’t in ffmpeg).
It’s a chore.
But I can’t believe you want to pass on the freaky lame UI - I’m always dazzled (in a “I wonder what it’s trying to say to me” kind of way) at the bars moving all around.
I’ve done that by creating a separate AppleScript called the ‘runner’ doing the shell script.
The main application
saves the run-parameters in a file
tells the finder to start the ‘runner’
continues normal operation
The ‘runner’
reads the parameters from the file
starts the doshellscript possibly with ’ > /dev/null 2>/dev/null &’ so it runs in the background
Advantage is that your main application keeps responding to the user in a normal way. Now your main application (or the runner, or both) can obtain process numbers from the OSX system and kill the process when necessary.