RBZ as allowed extension
-
@jim said:
You should probably remove the _MACOSX folder and any .DS_Store files. They must be hidden files on a Mac by default?
I'm not seeing the _MACOSX folder and the .Ds_Store can't be easily avoided, unless you remove them from all, system wide.
are you seeing _MACOSX folder if you change it to zip and open.
Google generated a _MACOSX folder in Plugins on a test I did last night...
john
-
it has the .ds store but not the other, I believe thats SU...
I changed .rbz to .zip to look inside the download from here. -
@driven said:
I'm not seeing the _MACOSX folder and the .Ds_Store can't be easily avoided, unless you remove them from all, system wide.
here's a little freebie that will keep them out of your zips..
http://www.sopht.jp/cleanarchiver/there are some more robust ones as well but i just use archiveutility.app that ships with osx.. i rarely send zips to windows users anyway..
-
cheers Jeff,
I've actually got YemuZip which does the PC friendly bit, but right clicking is easier.
Jim, can you check if that _Mac folder is still generated?
-
proper test complements of Jim... thanks in advance Jim
re-name or disable 'homer' if already in your Plugins, and try the loader.
REMOVED ATTACHMENT... there's another below
the Extension Button works here and so does Jim's first script.
the difference is SU opens the toolbar button and Jim's you need to enable it...
-
I checked - no extraneous files/folders.
-
Until .rbz is associated with SketchUp I see no point in using the .rbz format over .zip. The Install Extension button and the API methods accepts either format, so why not keep distributing in .zip?
-
@thomthom said:
Until .rbz is associated with SketchUp I see no point in using the .rbz format over .zip. The Install Extension button and the API methods accepts either format, so why not keep distributing in .zip?
The API does allow ZIP or RBZ files... but the Preferences > Install Extension button filters the list of available files to choose from in the dialog that opens to RBZ files only [can't be changed!] - so if you want to use the installer button then your stuff must be packaged as RBZ rather than ZIP, but annoyingly you'll still need a ZIP version for all of the other users with versions that don't include the installer button!
-
What? They didn't add .zip to the list?
One can just type * in the file name text field, but then you've already defeated the purpose of making things easy and non-technical. x_X
-
And if it's Zipped on a Mac, Google creates a new folder to hold the .DS_Store
If it's only the one I guess it means we don't need to 'PC' Zip files from mac's...
john -
I understand the Mac command-line zip utility does not create the extraneous files or folders.
$ zip -r homer.zip homer.rb homer/
You can also create the .rbz directly:
zip -r homer.rbz homer.rb homer/
And view/extract the contents of .rbz without renaming.
$ unzip -l homer.rbz $ unzip homer.rbz
-
@thomthom said:
What? They didn't add .zip to the list?
One can just type * in the file name text field, but then you've already defeated the purpose of making things easy and non-technical. x_XYou are right of course, BUT if users are so naΓ―ve that they can't currently extract some files/subfolders from a ZIP file and move them into their Plugins folder, then they are unlikely to have the sense necessary to think to type
*+<enter>
to get to see ZIP files listed in the dialog [and everything else too***] AND of course whilst a RBZ is likely to contain only kosher plugin stuff that should be installed into the Plugins folder, a ZIP file could be total tosh, like someone's holiday-snaps, which will then be splattered all over the Plugins folder by the installer [which does have even less sense than the average user]; so this is hardly an improvement on the manual install method, where at least the user might manage to extract the ZIPped files into a temporary folder [named after the ZIP]... and then see the various files/subfolders before moving them into the Plugins folder - and if they looked like holiday-snaps etc, then even the dullest user might reconsider their actions...
***Selecting another file type will produce an error if it can't be unZIpped... BUT ANY ZIP file can be installed using your work around - which is potentially very messy to clean up ! In a way ONLY the RBZ files should be listed no matter what the user does when using the button-installer -
I guess it makes sense...
So, do we phase out .zip and start releasing .rbz?
-
I think there will be an 'overlap' of ZIP and RBZ... as there will be many users who can't use RBZ as their SUp version won't have the button-installer for some time, if ever - unless they rename any RBZ as ZIP, and then we have gone full circle in expecting them to have a brain-cell or two...
So looks like we are going to have to continue with ZIPped sets and their instructions... AND as time goes by, more frequently RBZ sets and their own instructions - i.e. twice the work for no more pay [as 2x0=0!].In my opinion it would have been better not to have had the RBZ format at all [it offers few advantages after all], and simply to have used ZIP archives for the button-installer, BUT to have had some pre-installtion checking built into it - so it'd unZIP stuff into a temp-folder, check for .RB/.RBS files at the base-level [ALL plugins should have at least one such file there, otherwise they won't auto-install anyway!] and only then install it. That way the ZIPped sets would work for all users = while the users with the button-installer are mollycoddled, because they can't then mis-install a ZIpped set that way...
However, Google chose this obtuse RBZ route - which offers no obvious advantages to we scripters - just more [unpaid] effort... -
For the time being, it is obvious that the majority of the users still do not have the latest M2 installed so if you guys think just forget about the "possibility" here. If a user wants, can always rename the zip extension to rbz (although by default, Windows at least is set to hide known extensions so for many, it would be easier the other way round and rbz is not a known extension while zip is and many users won't be able to change it).
-
@ Jim,
was the __MACOSX folder on your mac or PC?I just got this in Terminal... the shell is creating the folder.
%(#BF0080)[UpStairs-2:~ johns_iMac$ cd Downloads
UpStairs-2:Downloads johns_iMac$ unzip homer.rbz
Archive: homer.rbz
inflating: homer/.DS_Store
creating: __MACOSX/
creating: __MACOSX/homer/
inflating: __MACOSX/homer/._.DS_Store
inflating: homer/doh.wav
inflating: homer/homer.png
inflating: homer.rb] -
@driven said:
was the __MACOSX folder on your mac or PC?
It was on PC, but the most recent homer.rbz does not have it. I don't have a Mac that can run version 8.
> unzip -l homer.rbz Archive; homer.rbz Length Date Time Name -------- ---- ---- ---- 0 12-03-11 19;39 homer/ 5004 07-14-07 12;14 homer/doh.wav 1491 07-14-07 12;26 homer/homer.png 353 01-04-08 15;08 homer.rb -------- ------- 6848 4 files >
-
@jim said:
There is no difference between a .rbz and a .zip. The .rbz is simply a renamed .zip. The .rbz just adds to the confusion, IMO.
TOTALLY AGREE w/ Jim !
I argued against using a new rb_ extension as presumptuous. The Ruby Core community could come out with some feature that uses a rbz file in the future... for some other purpose.
I advocate NOT using the "rbz" extension, at all !!
-
BUT if you are going to use the 'Install Extensions...' button in Preferences at all you need to provide a RBZ file: it is possible to trick it into letting you install a ZIP by typing *+<enter>, but there are no checks that the ZIP archive contains .rb/.rbs files so any old tat can now be more easily installed.
At least with a RBZ format the user might have some confidence that the author has made a toolset archive that will work and not a ZIP of their holiday-photos...
I agree that a ZIP based installer that checked for at least one .rb/.rbs file in the base level of the ZIP was all that was needed... a RBZ is just a renamed ZIP with an illusion of quality-assurance. -
Advertisement