Zacha Pedro, on Jan 21 2006, 01:34 PM, said:

But RealBasic might not allow you this.

That's exactly what the problem is.

I'm working on it.

I'm stealing the thunder back! Check out the new Plugin Archiver. This version requires neither StuffIt Deluxe nor any dodgy 3rd party apps but has built-in MacBinary encoding at speeds up to 25% faster than the old "Deluxe" version! Other improvements to the code as well and the app is now partially universal.

Can anyone tell me all the characters aren't allowed in windows file names? Is it true they can't start with a space?

Macbin program courtesy of Michael Austin

This post has been edited by Guy : 02 December 2010 - 04:27 AM

Looks fairly good, especially now that you've added the bin encoder into the applicaton bundle. I've done a few test compressions, and I only have a couple suggestions:

1. If possible, allow single files to be chosen while browsing. Perhaps have a dialog box on launch with the options "Archive File", "Archive Folder", and possibly "Quit"? Basically, it doesn't seem overly user-friendly to have program capable of archiving both files and folders, but that requires that files be drag-n-dropped.

2. Consider having the folder in which the new archive is created open when the program is done. It can be annoying to have to browse through a large folder tree twice to archive a folder, and then find the newly-created archive.

Edwards

@guy, on May 8 2006, 10:38 PM, said in Plugin Archiver:

Can anyone tell me all the characters aren't allowed in windows file names?

\ / : * ? " < > |

Quote

Is it true they can't start with a space?

No - they can start with a space (if the file is named by some program, for example) but if you try adding the space manually, then Windows will automatically remove it.

Well I've just upped a new version with a couple of new features:
- Automatic folder icon removal (man that was a pain)
- Detection of music files and appropriate warnings

@edwards, on May 12 2006, 06:19 AM, said in Plugin Archiver:

Looks fairly good, especially now that you've added the bin encoder into the applicaton bundle. I've done a few test compressions, and I only have a couple suggestions:

1. If possible, allow single files to be chosen while browsing. Perhaps have a dialog box on launch with the options "Archive File", "Archive Folder", and possibly "Quit"? Basically, it doesn't seem overly user-friendly to have program capable of archiving both files and folders, but that requires that files be drag-n-dropped.

2. Consider having the folder in which the new archive is created open when the program is done. It can be annoying to have to browse through a large folder tree twice to archive a folder, and then find the newly-created archive.

Edwards

Ooh, feedback
Hm, both of these are sort of answered with one assumption: The user will likely be working near the file/folder (ie, the parent folder will already be open) when they decide to archive it. Drag'n'drop will be easy and the archive will be created right there. I may implement no. 1 - it was just much simpler without it. But as for no. 2 I honestly find this really annoying. Most programs don't do this. If the file is on the desktop then it's going to open a new window to show me my desktop which is just stupid.
The one feature I'd really like is a console type output to indicate the progress (or any form of indication really) but it doesn't seem to be possible (short of telling TextEdit to open a new window and write stuff in it).

@belthazar, on May 12 2006, 10:48 AM, said in Plugin Archiver:

\ / : * ? " < > |
No - they can start with a space (if the file is named by some program, for example) but if you try adding the space manually, then Windows will automatically remove it.

Wow, that's a lot. The only character not allowed on a mac is a colon. The Finder won't let you add certain characters like a carriage return but some people seem to think it's funny to make file names with carriage returns by other means <_<.
So if a file does start with a space it can still be used okay?

Is it just me or does the Quick Edit not do anything?

This post has been edited by Guy : 11 May 2006 - 07:02 PM

@guy, on May 12 2006, 09:58 AM, said in Plugin Archiver:

Wow, that's a lot. The only character not allowed on a mac is a colon.

There are special reasons for disallowing those characters. / and \ are used in paths - the first in URLs and the second in Windows. : is also used in paths, to designate a drive letter, but it probably has some other use too. * and ? are wildcards for use in searching, while " indicates a phrase in most programming languages. Not sure why < > or | are forbidden, but there's probably some good reason. Mind you, simple apostrophes are allowed.

Quote

The Finder won't let you add certain characters like a carriage return

Oh yeah, there are a few characters which simply cannot be typed into file names, like the carriage return or the tab.

Quote

So if a file does start with a space it can still be used okay?

Yep. Not sure why you want a space at the start of a filename, though.

Quote

Is it just me or does the Quick Edit not do anything?

Doesn't seem to do anything for me either. But hey, nor do several of the other new menus which turned up around the place when the board software was upgraded.

@belthazar, on May 12 2006, 03:18 PM, said in Plugin Archiver:

There are special reasons for disallowing those characters. / and \ are used in paths - the first in URLs and the second in Windows. : is also used in paths, to designate a drive letter, but it probably has some other use too. * and ? are wildcards for use in searching, while " indicates a phrase in most programming languages. Not sure why < > or | are forbidden, but there's probably some good reason. Mind you, simple apostrophes are allowed.

Hm, on a mac they just need to be escaped.

@belthazar, on May 12 2006, 03:18 PM, said in Plugin Archiver:

Oh yeah, there are a few characters which simply cannot be typed into file names, like the carriage return or the tab.

Yeah, it's kinda obvious why you shouldn't put a carriage return in a file name. I mentioned that one specifically because the folder Icon files end in carriage return which was really annoying when writing the script.

@belthazar, on May 12 2006, 03:18 PM, said in Plugin Archiver:

Yep. Not sure why you want a space at the start of a filename, though.

That's easy - to force a plug to load first.

I usually use hyphens when I want to force things to come at the start - specifically, a hyphen followed by a space. (Windows is "clever" enough to ignore the hyphen as an attempt to change the order if it's not followed by a space.) It also has the added advantage that it's a visible reason for files to be coming first - I have several files on my HD which accidentally got a space added to the front of the name, and I'm constantly getting confused as to why they're not behaving themselves and getting in alphabetical order like the rest of the files.

On the Mac, the pre-OSX Finder does not allow (used not to allow) spaces to be added at the start of a filename, though that can (could) easily be circumvented by adding it to the middle of the name and remove the chars before it.

Nowadays in OSX it's the slash that's no longer allowed in filenames, because it's the UNIX path separator, but apparently whenever a colon is in a filename, the Finder and pretty much everything else (bar the Terminal, of course) display the colon as a slash, so it's still as if the colon was forbidden.

Yeah, the matter of the carriage return in Icon is downright ridiculous (see Brad Oliver's struggles due to it), but that's how it is, sadly.

Guy, you might also wish to stay clear of other potentially troublesome characters; for instance in my time of checking regularly the Allume support forum there are problems when PC people try to expand .sit archives with a file inside having a ™ in the filename. zip archives may have limitations of their own, as well (but at least it will fail or the problem will be seen when doing the archive and/or trying to reexpand it on the archiving Mac). Personally I would filter out every single character of the high-ASCII range (or since we're in an Unicode world, all chars not part of base ASCII), but I am paranoid.

As for features and feedback, RealLife™ is keeping me incredibly busy right now, but I promise I'll torture your program and get back to you with the results as soon as I can.

Minor update: fixed I bug I introduced in the last version. I will definitely be implementing the first suggestion of Edwards sometime.

@zacha-pedro, on May 13 2006, 05:07 AM, said in Plugin Archiver:

Guy, you might also wish to stay clear of other potentially troublesome characters; for instance in my time of checking regularly the Allume support forum there are problems when PC people try to expand .sit archives with a file inside having a ™ in the filename. zip archives may have limitations of their own, as well (but at least it will fail or the problem will be seen when doing the archive and/or trying to reexpand it on the archiving Mac). Personally I would filter out every single character of the high-ASCII range (or since we're in an Unicode world, all chars not part of base ASCII), but I am paranoid.

Hm, that does sound a bit paranoid and restrictive.
(EDIT) Actually I did check this. On mac some characters like ™ will get converted into other characters when decoding, which doesn't really matter, and PC users won't need StuffIt to extract so it should all be okay.

@zacha-pedro, on May 13 2006, 05:07 AM, said in Plugin Archiver:

As for features and feedback, RealLife™ is keeping me incredibly busy right now, but I promise I'll torture your program and get back to you with the results as soon as I can.

Ooh boy, I can't wait

This post has been edited by Guy : 13 May 2006 - 09:19 PM

Update: Now allows archiving of either file or folder when double-clicked. Implemented Edwards second suggestion as well but only when the app is double-clicked (ie, not when drag'n'drop).

This post has been edited by Guy : 13 May 2006 - 09:07 PM

Well, the negotiations- excuse me, the torturing session didn't last long. When I tried launching it, it told me "Could not run the script "droplet" because of a program error", with number -1328 (I have not been able to find any info on that error, and I have no idea whatsoever of what it means).

But if anyone here believes that can stop me, he doesn't know me well enough yet. So I opened the app bundle and found the script, and opened it. I tried to run it and it told me it couldn't find MacBin, of course, so I removed the check and replaced every instance of "(path to me) as string" by a var "him" containing the path to Plugin Archiver. Then it told me "Finder got an error: File folder AAC Paint Station Prime wasn't found.", this was due to bad parenthesing from the script editor, I fixed it by replacing "((info for TheProject) as alias)" by "(info for (TheProject as alias))". Then it did work. Asking to encode a single file worked that way too. Of course, it didn't allow me to test drag and drop.

Hm, so the app simply isn't going to work on older OSes. Aside from path to me not working, are you able to save it again as an app bundle? Or does older Script Editor not allow that?
Maybe I'll just have to do an OS check and say "Hey, you can't run this program. Maybe it's time to upgrade."

Sure thing. Do this. And I kill you.

No seriously, I'll try to investigate a bit more. Unfortunately the stuff my Script editor produces is not a bundle, though it is not a Carbon CFM app either (it looks like a standalone Mach-O file with a resource fork :blink: :unsure: :wacko:). Strictly speaking, as this app aims to replace the lost functionality of DropZip starting from Stuffit 9, it is not necessary for it to run on 10.2, that cannot run Stuffit 9 anyway, but it would be nice for me to be able to rate the stuff to know if it is suitable.

At any rate, given all the issues we've had with AppleScripts (such as the problem of pre-computing by the Script Editor and storing paths to referenced apps, but also the "folder" thing), I've come to this conclusion: AppleScripts, even compiled, are not actually meant to be distributed. Of course it works most of the time, but it is not thoroughly supported that they do, even with cooperation from the author.

@zacha-pedro, on May 16 2006, 05:14 AM, said in Plugin Archiver:

No seriously, I'll try to investigate a bit more. Unfortunately the stuff my Script editor produces is not a bundle, though it is not a Carbon CFM app either (it looks like a standalone Mach-O file with a resource fork :blink: :unsure: :wacko:).

When I save I get a choice of Script, Application, Script Bundle, Application Bundle, or Text.

@zacha-pedro, on May 16 2006, 05:14 AM, said in Plugin Archiver:

Strictly speaking, as this app aims to replace the lost functionality of DropZip starting from Stuffit 9, it is not necessary for it to run on 10.2, that cannot run Stuffit 9 anyway, but it would be nice for me to be able to rate the stuff to know if it is suitable.

Hm, well maybe you can just analyse the code and work out what will happen in any given situation

@zacha-pedro, on May 16 2006, 05:14 AM, said in Plugin Archiver:

At any rate, given all the issues we've had with AppleScripts (such as the problem of pre-computing by the Script Editor and storing paths to referenced apps, but also the "folder" thing), I've come to this conclusion: AppleScripts, even compiled, are not actually meant to be distributed. Of course it works most of the time, but it is not thoroughly supported that they do, even with cooperation from the author.

An odd conclusion. While AppleScript distributions are rare this is because people would rather write a real program to do the job instead. But they do exist. The issue of the referenced app only happened with the Nutcase MacBinary version, where the path to the app was not known and could not be fetched and it simply relied on the system to know where it was.

@guy, on May 15 2006, 07:08 PM, said in Plugin Archiver:

people would rather write a real program to do the job instead

Does this mean I win?

Get back to work on it and you may... (as for me, no, I have no intent on using an actual language, that is C, to reimplement this again. I have other stuff to spent my programming energy on).

Guy, I don't mean Apple tells people not to distribute AS apps or that you are wrong to try and use it for this, but for me it is clear that it's not a main focus of the guys working on AS. Otherwise it would work better.

@orcaloverbri9, on May 17 2006, 03:44 AM, said in Plugin Archiver:

Does this mean I win?

Well if you can get faster encoding (or just use the Macbin program) then yup

@zacha-pedro, on May 17 2006, 07:02 AM, said in Plugin Archiver:

Guy, I don't mean Apple tells people not to distribute AS apps or that you are wrong to try and use it for this, but for me it is clear that it's not a main focus of the guys working on AS. Otherwise it would work better.

True, but I think it works well enough.

@guy, on May 16 2006, 08:00 PM, said in Plugin Archiver:

Well if you can get faster encoding (or just use the Macbin program) then yup

I'm workin' on it, 'kay?

EDIT: Resource fork streaming works! Unfortunately, it also breaks the status notifier. Oh well.

This post has been edited by orcaloverbri9 : 16 May 2006 - 09:39 PM

@orcaloverbri9, on May 17 2006, 01:36 PM, said in Plugin Archiver:

Resource fork streaming works! Unfortunately, it also breaks the status notifier. Oh well.

Cool :). At least it has some status indication.

But in the mean time I've uploaded a new version.
New features:
- Alerts if file name with characters incompatible with windows are found
- Converts spaces to underscores in the archive name
- Extra goody for Tiger users
Bugs fixed:
- Archiving a single file which is actually a package won't cause a crash (contents of packages still can't get checked though)
- Archiving a single file with a resource fork and a really long name won't fail