Thread: [Camelbones-devel] ANN: ShuX 3.0-beta1
Brought to you by:
shermpendley
From: Sherm P. <sh...@do...> - 2005-03-18 19:53:19
|
This is the first beta of ShuX 3.0. It's all-new, rewritten from the ground up to use the new features in the upcoming release of CamelBones 1.0. It uses Cocoa Bindings, which require Mac OS X 10.3, aka "Panther". One of the features of CamelBones 1.0 will be the ability to package stand alone apps that require no external framework, and can be "installed" with a simple drag-and-drop. This release takes advantage of that - just mount the disk image and drop ShuX wherever you want. There are a handful of missing features in this release, most notably hyperlinks and a document toolbar. These will be added to the final release. This release does not work on Mac OS X 10.4, aka "Tiger". A version of ShuX that works on both Panther and Tiger will be released on or very near Tiger's release date. <https://sourceforge.net/project/showfiles.php? group_id=48040&package_id=147466> sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org |
From: Thilo P. <thi...@us...> - 2005-03-20 04:29:04
|
> One of the features of CamelBones 1.0 will be the ability to package > stand alone apps that require no external framework, and can be > "installed" with a simple drag-and-drop. This release takes advantage > of that - just mount the disk image and drop ShuX wherever you want. Sweet. And the application is still under 1MB, which in these days is definitely considered "light", so this could become the preferred way to distribute CB apps. > This is the first beta of ShuX 3.0. It's all-new, rewritten from the > ground up to use the new features in the upcoming release of > CamelBones 1.0. It uses Cocoa Bindings, which require Mac OS X 10.3, > aka "Panther". If it did not use Bindings, would it still run under 10.2 ? Or does CB 1.0 itself (and the new embedded framework thing) require 10.3 now? If I understand the embedded framework correctly, it has several binaries for the different Perl versions that Apple shipped. So if you did not replace the default Perl (bad idea anyway), it should work, right ? If you do want to use a non-standard Perl that you built yourself, and you built your own CB framework for it, too, will the embedded framework detect a pre-installed CB framework and use this one instead? Or alternatively, can the app bundle with the embedded framework be easily told to do that ? If any of this is difficult, just ignore me, I am just curious as to how things work, these are definitely very marginal problems (people who wipe out their vendor-installed Perl deserve all the troubles that they caused). Thanks for this great new feature, Thilo |
From: Sherm P. <sh...@do...> - 2005-03-20 05:35:31
|
On Mar 19, 2005, at 11:28 PM, Thilo Planz wrote: > And the application is still under 1MB, which in these days is > definitely considered "light", so this could become the preferred way > to distribute CB apps. It probably will - I got a *lot* of negative feedback about the shared framework. As far as size goes, keep in mind that each one of the "support bundles" - the arch- and version-specific .bundles in the framework's Libraries/ subdirectory - weighs in at just under 600Kb. So the total size will depend on how many of those the app includes. Thus, an app that needed bundles for Jaguar, Panther, and Tiger would need to include a bit under 2MB of overhead. Even so, that's not too bad, considering that the rest of the code is all text, which is small to begin with and compresses well besides. > If it did not use Bindings, would it still run under 10.2 ? Yes. > Or does CB 1.0 itself (and the new embedded framework thing) require > 10.3 now? The plan is to fully support Jaguar. I haven't booted into Jaguar or built CB on it in quite some time though, so there may be some Jaguar-specific bugs that need to be addressed. > If I understand the embedded framework correctly, it has several > binaries for the different Perl versions that Apple shipped. Yes. The actual framework is just a stub. It examines the machine it's running on, and decides which of the available support bundles to load. > So if you did not replace the default Perl (bad idea anyway), it > should work, right ? Yep - it should work fine. When the stub is deciding what support bundle to use, it runs a Perl one-liner to get the version and architecture. To figure out which Perl to run the one-liner with, first it looks for a defaults key "perl" in the domain "org.dot-app.CamelBones". If it finds one, it will use the Perl that points to. Otherwise it will use "/usr/bin/perl". So, if you've installed a custom Perl, you have two options. First, you could tell CamelBones to ignore your custom Perl and use the Apple-supplied Perl with something like this: defaults write org.dot-app.CamelBones perl /usr/bin/perl5.8.1 I've gotten several reports already, from folks who have successfully used this procedure to run ShuX, when /usr/bin/perl points to a Perl for which ShuX doesn't have a support bundle. Naturally, if the framework is being used from a standalone .pl script, rather than a GUI .app (another new packaging option) the version & architecture name is retrieved directly from the Perl that's running the script. The other option is to tell it to use your custom Perl - that's part of the next answer. > If you do want to use a non-standard Perl that you built yourself, and > you built your own CB framework for it, too, will the embedded > framework detect a pre-installed CB framework and use this one > instead? This part isn't implemented yet, but support for that scenario is planned. The plan is, if the framework stub doesn't find a matching support bundle in its own Libraries/ subdirectory, it will look for one inside a shared framework - i.e. in /Library/Frameworks/CamelBones.framework/Libraries. So the answer to your question is "yes, mostly"; the embedded framework stub would still be used in that case, but that stub will be able to find and use a pre-installed support bundle if it needs to. > If any of this is difficult, just ignore me, I am just curious as to > how things work *Writing* it was difficult. Explaining it is easy. :-) Besides which, aside from a few trivial details, it appears you've got it all figured out already. sherm-- Cocoa programming in Perl: http://camelbones.sourceforge.net Hire me! My resume: http://www.dot-app.org |