[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