Hi Chris,
I'm glad other Mac people are thinking about this. My concern was primarily with packaging binaries of *externals*, which, looking back, wasn't clear in my last email. That changes things, but you bring up a lot of points worth talking about anyway.
I hope people don't mind that I've cc'd this message to the general pd-list, since it's a bit more, uh, general.
On Friday, December 6, 2002, at 06:31 PM, chris clepper wrote:
I've been giving some thought to that on the OSX side, mostly with regards to the packaging system. I'm not sure what's the most convenient way to make installable packages on the MacOSX side of things. Apple's .pkg is attractive, but the current package format doesn't seem to be very manipulable by the command-line.
why even bother with a packaging system for the binary? how about this for an install on OSX:
step one: download binary step two: un-tar/zip/stuff downloaded file step three: open pd folder and double click on CLICK_ME_TO_RUN_PD smiley face icon
for step three to happen, write a pdstart.command that has ./pd -options and put it in the pd/bin dir. make an alias to it with that big smiley face icon at the root of the pd folder.
Can you believe I hadn't considered that? Yes, that would be a nice, friendly, easy way of approaching things.
i don't think you can assume that the typical Mac user uses the command line at all, so OSX apps should take that into account. the above approach seems to be in line with most free/shareware applications distributed for OSX, which will make Mac users feel right at home.
one thing to work out is explaining how the runtime options are used. this could be a point of confusion for people when they first try to setup their midi/audio and add various libs to pd.
But so my interpretation of the "Mac OSX way" is slightly different. I see it as a real UNIX, but with all the tricky bits hidden out of sight. Users interact with the nice smiley bits exposed for them, but don't worry about the stuff hidden out of sight. Power users can use the command line all they like.
So that's where I was coming from with a standard /usr/local/pd folder. You can put a smiley "Pd start.command" in /Applications, and no one will be the wiser.
So yes, the externals, and in particular managing paths, are the tricky bit, which is where I tried to start the discussion. If we can control help paths in a manner similar to the lib/extern path, then we are most of the way there. That way, people can look at something like a /Library/Pd hierarchy for externals, and come up with some automagic way of linking help files and binaries.
( I spent an afternoon this week looking at simple heuristics for figuring out libraries, how help files are linked, and which .pd files are help files and which are not. My conclusion: the last bit is really hard, across the external libraries that exist. So the grand plan of a magic drop Folder with an attached AppleScript and shell script is on hold. bailing wire and glue.... )
Also--where do they go? The /usr/local tree (where I personally prefer to put pd) is typically hidden from the user. It would be nice to be able to put files in a place like /Library/Pd, where an ordinary user has the capability to scre^H^H^H^Hmanipulate their installation in the finder.
i think you have answered your own question. the OSX version of pd should go where the user wants it to go. if you install to /usr/local that would make pd vanish to the majority of mac users!
Well, none of the stuff in the main distribution folder is of any use to a normal mac user... almost nothing to view, and nothing to run from the finder. But a friendly pd.command in a prominent position? That does everything.
I also advocate a semi-standard place for the main distribution binaries because Pd isn't necessarily to be run directly by the user. :)
Externals are a different matter. A user probably wants to at least see her "plug-ins" in a user-visible folder. I'd like to accommodate that while putting links to help and libraries in the "right" places automatically.
We could emulate your debian approach--how does that lay out files for externals (and their associated source, help, and other files)?
why emulate debian at all? it's not debian it's OSX. if anything it should more closely resemble the win32 version.
That's a point. But I was asking more about the debian packages in terms of how the externals are approached: is everything from an external kept in a single folder, with symbolic links spread everywhere? Are the actual binaries and helpfiles moved?
Best regards, adam