Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Make life a little easier
Okay, I've managed to write a nice little Applescript to bin and zip stuff all by itself, saving the trouble of binning all your plug-in files separately before zipping the whole project. It uses a freeware program "NutCase MacBinary" because MacBin Drop always quits on me and can only do drag and drop. Also requires the zip command line tool that is installed with the Developer Tools. Some of the subroutines I didn't write myself, they were copied from a free zip script I found. Comments? Bugs? I'm not really a great programmer so don't expect it to work properly for every unexpected situation you might throw at it.
(edit) New stand-alone version available from link in sig
This post has been edited by Guy : 08 October 2006 - 03:15 AM
Timely! This was just the thing to get me to finally make a binned & zipped version of Cold Fusion for Nova, which will hopefully resolve a recently aired complaint.
To anyone else who wants to use this: you'll need to download NutCase MacBinary from this site.
Now I just gotta find the time to make minor revisions to my website, so people can actually find the new archive....
This post has been edited by Dr. Trowel : 22 August 2005 - 10:38 PM
Dr. Trowel, on Aug 23 2005, 03:35 AM, said:
To anyone else who wants to use this: you'll need to download NutCase MacBinary from this site. View Post
Hm, it's supposed to tell you to go here if it can't find it. Oh well.
Anyway, I've put a new version up now with major changes. Among other improvements it will only bin Nova files - so you'll lose any custom icons on other files you might have but PC users won't try to convert them by mistake.
This post has been edited by Guy : 23 August 2005 - 07:49 PM
New version performs as advertised -- I lose my custom icons and can no longer open my old-style SimpleText readme file with a double-click. I guess that's simply the price of idiot-proof cross-platformness.
I shouldn't be using SimpleText anymore, anyway. My archive already contains an .rtf version, and that came through just fine. An HTML readme would be even better, since OS 9 people w/o Word would have less potential trouble with that.
Yup, sorry about that but the method that it used to check for resource forks was copied from another script and I found it could cause problems in this one. But yeah, you shouldn't really have other files with resource forks in a cross-platform plugin as they're only going to get lost on a PC anyway. Alternatively, there's a great MacBinary CM plugin on VersionTracker.
Another new version up now with minor changes including a nice message telling you it was successful and how many files were encoded. Plus an icon. Does anyone else think this is useful?
This post has been edited by Guy : 23 August 2005 - 08:06 PM
Okay, I worked out it was quite simple to fix the problem so here's another version which will encode all files with resource forks. I've kept this separate because sometimes there are files with resource forks where the resources don't really do anything and you wouldn't notice if they were missing, so there's no need to confuse PC users by encoding them.
Could I get some more feedback on this please? Am I really just wasting my time?
This post has been edited by Guy : 24 August 2005 - 07:18 PM
Guy, on Aug 24 2005, 07:00 PM, said:
Could I get some more feedback on this please? Am I really just wasting my time? View Post
As far as I'm concerned, you're not wasting your time -- this stuff helps me! However, I do seem to be responsible for a rather high percentage of the downloads of your scripts. If you haven't already, you might want to submit your creation to the "utilities" section of the add-ons collection and then just let it lie.
Yeah, I'm planning to do that, I was just hoping for more feedback in the way of bugs or things I should change before I do so. I mean, what is the preferred way of handling other files with resource forks? Bin them all? Ignore them? Ask the user if any are detected? Give the user a list of the files a let him choose which ones?
Just acquired some webspace so I'm able to present: (EDIT): Removed New in this version: - Now works on systems where English is not the main language - Improved Tiger support - Works faster and more smoothly if StuffIt Deluxe is installed
If people could please test this just to make sure it works (even if you don't really have a use for it) then that'd be great. (Zacha, this has changed since last)
This post has been edited by Guy : 08 May 2006 - 07:31 AM
Oops, what did you do? "NutCase Macbinary" seems to have been renamned "NutCase MacBinary f" in the script, which obviously it doesn't find. Corrected, and it does work. However, you might also wish to put "folder of (info for (TheProject as alias))" instead of "folder of (info for TheProject as alias)", because when I tell to check the script it transforms the latter into "folder of ((info for TheProject) as alias)" which obviously isn't a good thing.
(for those who might be wondering, I've been testing this stuff and reporting to Guy via PM in the last few days).
Stupid AppleScript. I'm afraid the "f" is your problem. Delete all copies of NutCase, Plugin Archiver and its prefs then download it again.
Yep, it's AppleScript doing weird things on me. And now an even weirder problem: it tells me it cannot find NutCase MacBinary (when it is of course here) and offers to show me where it is on VersionTracker, just the thing we couldn't get to appear when NutCase was not included with it! However, once I open it in the script editor, it runs just fine. And if I save in the script editor (oddly enough I can, even if I didn't touch the code), and quit the script editor, the app runs just fine!
I think the compiled app stores the paths to the apps it needs (I saw this when examining some resources in the compiled script: Macintosh HD:Users:Andrew:Desktop:Plugin Archiver:NutCase MacBinary:NutCase Macbinary, it's you Andrew, right?) and assumes it won't have to find them anew, that's up to the Script Editor to do it. So, if you could get somehow to compile without having the path coded and let the compiled app find itself, then it'd work.
(note: in fact the same behavior, that is the fact that I have to open, run, and save with the script editor, is necessary to get it to run, affects the version you sent me by email Guy, so it's also bugged for me) Okay, I renounce trying to understand. When NutCase MacBinary is present, Plugin Archiver presents me with your dialog, Guy (this script requires NutCase MacBinary, with buttons Show me and Quit). Even if I put it in places I would never have thought it could find it, even if I rename it, etc... However, as soon as I empty the trash, and relaunch your compiled script, then it shows me the "where is NutCase MacBinary" dialog.
This is the exact opposite of a rational behavior.
The lesson is: we cannot rely on AppleScript's behavior to find the apps it requires when moving the compiled script to another computer (probably an AppleScript bug that's fixed in later OSX versions). Therefore I recommand that you explicitely ask the Finder to find an app with name "NutCase MacBinary" in the script, and run that app. It might work better.
Zacha Pedro, on Dec 14 2005, 06:59 AM, said:
I think the compiled app stores the paths to the apps it needs (I saw this when examining some resources in the compiled script: Macintosh HD:Users:Andrew:Desktop:Plugin Archiver:NutCase MacBinary:NutCase Macbinary, it's you Andrew, right?) and assumes it won't have to find them anew, that's up to the Script Editor to do it. So, if you could get somehow to compile without having the path coded and let the compiled app find itself, then it'd work. View Post
Ah, so it does. I thought that would have been in the prefs file. Unfortunately there's no way to save the script without it asking where the app is (if it can't find it it won't let you save). Which is silly but I'm sure other people have had it working without problems. Anyone?
Guy, on Dec 14 2005, 03:35 PM, said:
...but I'm sure other people have had it working without problems. Anyone?View Post
Not I. I spent a few minutes attempting to convince it to work, but after a few tries I gave up and .bin.zip'd manually. I had what looks like the same problems ZP has had, only in less detail.
Edwards
If I have NutCase MacBinary running before I drop my files on the script's icon, the script gives me no complaints and runs just fine.
I know it shouldn't be necessary to manually start MacBinary, but it's so little bother that I don't mind it at all.
Guy, on Dec 15 2005, 12:35 AM, said:
Ah, so it does. I thought that would have been in the prefs file. Unfortunately there's no way to save the script without it asking where the app is (if it can't find it it won't let you save). Which is silly but I'm sure other people have had it working without problems. Anyone? View Post
In fact I checked the prefs of Plugin Archiver and there's only Navigation Services stuff (the last states of the open and save dialogs) in there.
Dr. Trowel, on Dec 15 2005, 01:31 PM, said:
I know it shouldn't be necessary to manually start MacBinary, but it's so little bother that I don't mind it at all. View Post
Yep, that's something I noticed too. It could be acceptable for us experienced users, but remember, this is aimed at replacing the ease of use of DropZip. This behavior obviously doesn't fit the book of specifications.
Guy, the name of the app needn't be an explicit, constant string as "NutCase MacBinary", it could be a string var that could even change at runtime, and obviously in that case the Script editor can't check for existence of the app when compiling since the name might vary at runtime. Try this, and post the compiled script so that I can check whether this works when we change the host. But it may still remain that the search for the app is erratic, buggy, or simply minimal (only in a few places like the script folder and the Applications folder). In that case, I would push further the "app name in a var" method by explicitely specifying the path (according to the AS docs, you can specify apps this way too), by at runtime taking the path where the script is, remove the script name, and add ":NutCase MacBinary:NutCase MacBinary". It would break if the user moves or renames NutCase MacBinary from your script, so this approach is reserved to the case the previous one doesn't work, but it's at least satisfying since it would work to boot.
This post has been edited by Zacha Pedro : 15 December 2005 - 12:12 PM
Argh. Is this problem just with the new one or with the original one too? In any case, I've reverted back to the last version I sent you, Zacha, as I realised that even if you have StuffIt Deluxe it will still want to know where NutCase is. Plus, you said this one worked okay for you
Sorry to steal your thunder, Guy, but I have a solution to all these silly problems:
Presenting Bin/Zip Maker 1.0.0! This convenient app invisibly creates the .bin.zip file. It creates the .bin automatically, meaning external programs are unnecessary, and uses the OS X zip utility to zip them. Simply click "Process File", select a plug-in or whatever, choose the destination file, and choose the location for the intermediate .bin file, and let it go! Automatically displays the file in the Finder and deletes the intermediate MacBinary file.
Requirements: - Mac OS X - The zip UNIX command-line utility
Shortcomings: - Doesn't preserve data forks (easy to do, I was just too lazy) - Doesn't preserve creation and modification dates - No folder support (eventually will zip a folder, .bining all files with resource forks) - No drag-and-drop support - No File > Open and therefore no apple-O (will add in next version) - Doesn't work on OS 9 (it will run, but crash when it tries to zip) - Doesn't work without the zip utility (it will give an error message)
Notes: - If you are on 9 or don't have the zip utility, meaning it will not zip the .bin, you may still be able to manually zip the .bin if it still exists - If you don't specify a path for the intermediate .bin file, it will automatically use the same folder as the .bin.zip file and use the name of the source file plus ".bin" as the name - If the app hangs while the status box says "Creating MacBinary file...", check that there is not a file of the same name as the MacBinary file already open - if there is, close it
The file is here, and is amusingly .bin.ziped.
This post has been edited by orcaloverbri9 : 19 December 2005 - 07:03 PM
Ah, now this is more like it. I was secretly hoping someone would make a nice program to do it all by itself. :rolleyes: How about removing the step where it asks where to put the .bin file and just put it next to the source by default? Or, like my script, you could create a temp folder, do all the processing in there and then move the final zip archive back next to the source and delete the temp folder.