Well, I needed a way to find out what the .bin file should be named. I suppose it would be okay to just name it (name of source file).bin...but I'm not so sure about removing the "save processed file as" dialog. This will seem like deja vu, but what if it's on a locked volume or in an inaccessible directory?
-
orcaloverbri9, on Dec 19 2005, 06:00 PM, said:
Shortcomings:
- No folder support (eventually will zip a folder, .bining all files with resource forks)
- No drag-and-drop support
View PostI'm quite fond of those two features.... I'll probably be sticking with Guy's script until orca adds them to his promising new app.
This post has been edited by Dr. Trowel : 19 December 2005 - 11:35 PM
-
Well...hmm. It's not easy to check if it's locked. I think what I'll do is try to create the temp folder next to the source; if that fails, it'll try the desktop; and if that fails it'll ask and put the temp folder next to it.
Dr. Trowel, I'll work on that. You can expect to see drag-and-drop and menu opening soon.
-
Update: now uses the method I described above for the destination and temp folder. Also added menu item opening support and drag-and-drop for both the application and the main window. Currently working on folder support.
Update #2: now supports folders. Only supports files with resource forks in the root of the folder (I wanted to make it traverse them all, but kept running into stack overflow exceptions).
This post has been edited by orcaloverbri9 : 20 December 2005 - 11:57 AM
-
orcaloverbri9, on Dec 20 2005, 03:56 PM, said:
Update: now uses the method I described above for the destination and temp folder. Also added menu item opening support and drag-and-drop for both the application and the main window. Currently working on folder support.
Update #2: now supports folders. Only supports files with resource forks in the root of the folder (I wanted to make it traverse them all, but kept running into stack overflow exceptions).
View PostThis seems very interesting, a few remarks about what has already been posted before I try it (it's currently downloading):
- OS9 support is something neat, but unnecessary. Remember, we aim at replacing a dropped feature of DropZip, and the latest version for OS9 (in fact, the latest version for 10.2.8 too) still has it. However, it should be easy to use and all, but this is promising.
- If you get stack overflow issues, then you're probably recursing over and over without limit. Check how you traverse folders and that you don't continue the recursion with the parent folder (usually referred by "..") nor the folder itself (usually referred by "."), or some other such thing.Downloading is over now... RealBasic, isn't it?
-
And now I've tried it...
- Getting data fork support is essential, for the simple reason that some files (such as SimpleText's ReadMes) have both data (for the raw text) and resource (for the styling), which means that the text gets nuked (but the styling is kept, which is completely useless...). Of course I prohibit such way of doing text, but still there can be stuff with both resource and data forks, with the data fork being essential (but not the resource fork, incidentally, allowing PC users to get the essential, i.e. the raw text), such as a mp3 file (data fork) that has a custom icon (in the resource fork). It would be acceptable if your util only kept the data fork by not MacBinarying in this case (though keeping both would be better), but not if it trashes the data fork.
- On the other hand, creation/modification date support is secondary. Heck, when I encode a file with NutCase MacBinary, then decode it with Stuffit Expander, the files is said to have been created and modified one hour later than the original, probably because one sets the date in the MacBinary format as local and the other interprets it as GMT (I'm at GMT+1). It makes more sense to be GMT as Stuffit does, so if you eventually support that, make sure to do it that way.
- You might wish to tell the Finder to refresh the window where the .bin file is, because it doesn't disappear unless I click on the window (which is very disturbing); I think a well-chosen AppleEvent to the Finder, if you can send them, should be enough, but I don't know which one. Or, you can use a temp folder far away, which is IMHO better practice.
I don't know if I'll be able to test this regularly - another test will probably be taking my time...
-
Zacha Pedro, on Dec 20 2005, 11:23 AM, said:
- If you get stack overflow issues, then you're probably recursing over and over without limit. Check how you traverse folders and that you don't continue the recursion with the parent folder (usually referred by "..") nor the folder itself (usually referred by "."), or some other such thing.
Downloading is over now... RealBasic, isn't it?
Yeah, apparently the item list is 1-based rather than 0-based as I thought and item 0 is the folder itself. The next version probably won't have recursion, but expect it in the one after that. And yes, it is in REALbasic, because I don't know Objective-C well enough to do anything involving files...or resource forks...or Apple events...you get the point. If I did, I totally would've used Cocoa.
Zacha Pedro, on Dec 20 2005, 11:46 AM, said:
- Getting data fork support is essential, for the simple reason that some files (such as SimpleText's ReadMes) have both data (for the raw text) and resource (for the styling), which means that the text gets nuked (but the styling is kept, which is completely useless...). Of course I prohibit such way of doing text, but still there can be stuff with both resource and data forks, with the data fork being essential (but not the resource fork, incidentally, allowing PC users to get the essential, i.e. the raw text), such as a mp3 file (data fork) that has a custom icon (in the resource fork). It would be acceptable if your util only kept the data fork by not MacBinarying in this case (though keeping both would be better), but not if it trashes the data fork.
Data fork support, as I said, is actually quite easy, but I was too lazy. You'll probably see it in the folder-traversing one.
Zacha Pedro, on Dec 20 2005, 11:46 AM, said:
- On the other hand, creation/modification date support is secondary. Heck, when I encode a file with NutCase MacBinary, then decode it with Stuffit Expander, the files is said to have been created and modified one hour later than the original, probably because one sets the date in the MacBinary format as local and the other interprets it as GMT (I'm at GMT+1). It makes more sense to be GMT as Stuffit does, so if you eventually support that, make sure to do it that way.
Well, the problem is that while the TotalSeconds property of the Date object claims to be a Double, it is in fact a Single, meaning it maxes out at 7FFFFFFF, or sometime in 1972.
Zacha Pedro, on Dec 20 2005, 11:46 AM, said:
- You might wish to tell the Finder to refresh the window where the .bin file is, because it doesn't disappear unless I click on the window (which is very disturbing); I think a well-chosen AppleEvent to the Finder, if you can send them, should be enough, but I don't know which one. Or, you can use a temp folder far away, which is IMHO better practice.
Oh, I an definitely send AppleEvents to the Finder - that's how it shows the item when it's done (an event with ID "misc" and code "slct", specifically). I don't know if there's a refresh event, but then I didn't have this problem (I guess Tiger is better at refreshing that Jaguar), so it never crossed my mind.
Anyhow, back to getting folder support to actually work.
EDIT: Yay! It works now! Silly me, I didn't know you needed the -r switch to zip a folder. Anyhow, the new version is up here (yes, I switched to sitx for a reason...let's see if you can figure it out).
This post has been edited by orcaloverbri9 : 20 December 2005 - 04:13 PM
-
orcaloverbri9, on Dec 19 2005, 06:01 PM, said:
Well...hmm. It's not easy to check if it's locked. I think what I'll do is try to create the temp folder next to the source; if that fails, it'll try the desktop; and if that fails it'll ask and put the temp folder next to it.
View PostYeah, see many programs create temp items but I've never had one ask me where it should put them. A third option would be the same place as the destination since this definately won't be read-only else it wouldn't work at all. Keeping the temp folder hidden (".tempxxx") is a good idea too.
Are you not able to have a dialog that lets you choose any type of item, be it file or folder? AppleScript wouldn't either, so I just stuck with folder. It also can't do a save dialog so if the source is in a locked folder then Plugin Archiver won't work :mellow: I didn't think about that before but since you're making a program I won't bother fixing it
This post has been edited by Guy : 21 December 2005 - 12:16 AM
-
Guy, on Dec 20 2005, 11:14 PM, said:
Yeah, see many programs create temp items but I've never had one ask me where it should put them. A third option would be the same place as the destination since this definately won't be read-only else it wouldn't work at all. Keeping the temp folder hidden (".tempxxx") is a good idea too.
Are you not able to have a dialog that lets you choose any type of item, be it file or folder? AppleScript wouldn't either, so I just stuck with folder. It also can't do a save dialog so if the source is in a locked folder then Plugin Archiver won't work :mellow: I didn't think about that before but since you're making a program I won't bother fixing it
Nonono, you misunderstand. If it fails with both the source dir and the desktop, it will ask where to save the file and put the temp dir next to it. The temp dir is called ".tempbinzip", by the way, so don't worry about that.
No, I can't make an "open-all" dialog unfortunately, but I definitely want you to be able to process a single file. In any case, this version should work. I've planned on folder support from the beginning, so think of the first as a sort of preliminary 1.0.0, and this as the official. 1.0.1 will have support for data forks and will hopefully have folder recursion and refresh the Finder when it reveals the file.
-
Update! 1.0.1a1 is up! Same link as previous build. Changes in this version:
- Should now recurse through subdirs
- Preserves the data fork when .bining
- Hopefully won't have any Finder-revealing glitches anymoreAnd I just realized that I forgot to add handlers for the menu items. Ah well.
-
orcaloverbri9, on Dec 20 2005, 06:26 PM, said:
Nonono, you misunderstand. If it fails with both the source dir and the desktop, it will ask where to save the file and put the temp dir next to it. The temp dir is called ".tempbinzip", by the way, so don't worry about that.
View PostAh, I see, I like that
Finder unzipping is close to that - it will try the source, then the desktop but then it will complain it was unable to create a temporary folder.
How about making it exit after you've dropped a file on it? And revealing the result is rather annoying if it happens to be the desktop. -
Guy, could I ask your permission to rename it Plug-in Archiver and use your icon, since the script is now abandonware?
-
Okay, I'm almost done the latest version. Changes in Plug-in Archiver 1.0.2:
- Renamed it Plug-in Archiver (thanks, Guy)
- Added Guy's icon (thanks again, the zipper is brilliant :))
- Added a preferences dialog
- Added an about dialog
- Added a close menu item
- Made the open menu items be more than decorationsThings still left to do:
- Make everybody happyThings I did since I posted this update:
- Made it pay attention to the preferences
- Reinstated the Edit menu, complete with Cut, Copy, Past, Clear, and Select All, for the one text box in the entire app
- Compiled and packaged it
- Uploaded it hereThis post has been edited by orcaloverbri9 : 21 December 2005 - 10:10 PM
-
Lookin' nice. The zipper was just copy/pasted from the standard zip archive icon
Okay, the close menu item is greyed out. There's also no close button on the main window which might explain it. This would just quit it though, right? The always ".zip" preference still gives .bin.zip. Process folder worked for me before but now all I get is NilObjectExceptions.Holy crap the boards are behaving badly today!
This post has been edited by Guy : 22 December 2005 - 03:46 PM
-
It's supposed to be disabled. Yes, for the same reason there is no close button. It's the main window. It shouldn't close. Plus, the app depends on its being open for some fairly major functions, like loading and archiving files and folders.
The always ".bin" setting not working was me being hasty (as a matter of fact, it ignored the preference altogether). I also forgot to make some changes when I copied-and-pasted from the version for files to the version for folders. In any case, it's fixed.
The NilObjectExceptions are just RB being retarded. I got them too. They're gone now.
Okay, I'm getting ready to upload v1.0.3. Changes:
- Above bug fix
- Changed the design of the preference window a little
- Made the app more Cocoa-ish when inactive
- Added a nifty new feature if you choose to use a custom filenameLeft to do:
X Compile and package it
X Upload it here
- Make everyone happyThis post has been edited by orcaloverbri9 : 22 December 2005 - 08:30 PM
-
Ah, I can check this out at last.
Bug has been fixed but now both options have the same label in the preference window :huh:
Recursing doesn't work. What I did was copy the entire source folder into the temp folder, recurse through, binning and deleting originals, then zip the folder and move the zip file back to the destination (this also means you don't see the partial zip file sitting around).Now for some speed tests. Source: "Nova Files" (171.2 MB)
Plugin Archiver: 1:52
Plugin Archiver Deluxe: 1:27
Plug-in Archiver: 7:44
I think you need a progress bar -
What the...huh? Why do they have the same name? I must investigate...odd. Compile error, I guess. How odd, though...
I don't know why recursing doesn't work...annoying. Wait, did it just ignore subfoldes, or was everything in the root directory? I seems that it should have been the latter.
As for the speed...I'd imagine that's just RB4's slowness. The next version should be much faster.
