[sldev] [META] Packages and bundles and XML, oh my
Argent Stonecutter
secret.argent at gmail.com
Wed Oct 10 07:31:14 PDT 2007
(was Re: [sldev] Packaging the viewer for Linux distributions)
On 10-Oct-2007, at 07:39, Robin Cornelius wrote:
> Still would need an
> installer for windows (and mac?) for first time install but nothing
> that complex is needed for an updater.
Mac doesn't need an installer, it uses the NeXTSTeP "bundle" scheme.
GNUStep apps on other UNIX (Linux,BSD,Solaris,...) are set up the
same way. It's really convenient... the top level directory is shown
as a file rather than a directory in the Finder (or the old NeXTSTeP
file manager and I assume in whatever file manager the GNUStep folks
use), until you select "Show Contents" from the contextual menu.
Here's the layout of the latest version:
Second Life.app
Contents
PkgInfo -- 8 bytes "APPL????" - equivalent to the old Apple
'Finder Info' - type and creator
Info.plist -- XML file describing the application's
requirements, what URL and file types it handles, etc...
MacOS
Second Life -- executable (MachO UNIX executable)
*.dylib -- bundled shared libraries, seem to be the ones for
gecko
chrome, plugins, etc... -- gecko support files, same as any
other SL install
Resources -- equivalent of old Apple 'Resource Fork'
secondlife.icns -- desktop icon
SecondLife.nib -- Window and menu layouts for the top level
window (non-XUI), standard Cocoa/Carbon file.
*.lproj -- localized strings, windows, etc for English
InfoPlist.strings
language.txt
arguments.txt -- default command line
app_settings -- xml, shaders, like in any other SL install
AutoUpdater.app -- app bundle for AutoUpdater, same layout inside
*.app -- ditto for other bundled apps
*.dylib -- rest of the bundled shared libraries
skins, releasenotes.txt, lsl_guide.html, etc...
Normally you'd expect something like Gecko and its support files to
be under Contents/Frameworks rather than under Contents/MacOS, but I
assume LL had some reason for doing things that way. (any comment
from the LL folks?)
By the way, the XML property list format is almost the same as the
llsd format that someone else brought up:
Info.plist
<plist version="1.0">
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
[...]
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>Second Life URL</string>
[...]
</dict>
</array>
</dict>
</plist>
plywoodcube.xml
<llsd>
<map>
<key>401346943</key>
<map>
<key>phantom</key>
<integer>0</integer>
[...]
</map>
</map>
</llsd>
The biggest difference is <map> vs <dict>. If this isn't set in
stone, it would be really nice if the Apple (and I assume GNUstep)
tools for handling property lists could be used on these files.
What's the scoop here?
More information about the SLDev
mailing list