April 23, 2009
A new understanding: XUL and .app
After talking to some guys in the #xulrunner channel on IRC, I foundout that my Mac applications were setup all wrong. At first I was like, why would they do that? But after getting it to work, I figured that it was pure genius! First of all, I was simply copying over my XUL app directly from my Linux box to a Mac, and then running it from Terminal:
//Library/Frameworks/XUL.framework/xulrunner-bin /path/to/app/application.ini
It worked, so I went with it. To install an app, you just add ‘–install-app’ to the end of ‘xulrunner-bin’, and it will stick it into the Applications folder. For some reason or another, Once it was installed, I could run it. But when I tried that same procedure on other machine, it didn’t work. Hmm. After some conversations, and reading, notice and article on MDC on Deploying XULRunner 1.8, and there was my answer.
Basically XULRunner on Mac has a different file structure, which is as follows:
MyApp.app/
- Contents/
- Info.plist
- Frameworks/
- XUL.framework/
- …all the XULRunner files
- Resources/
- application.ini
- icon.icns
- components/
- everything in your normal component directory
- chrome/
- everything in your normal chrome directory
- all your additional files and folders
- MacOS/
- xulrunner (the file copied from the ‘xulrunner’ stub, not the xulrunner-bin)
MyApp.app is actually a directory, with a ‘.app’ extension on it. All it did was create a directory, put all my files in the correct structure, add the ‘Info.plist’ file, and rename the directory with the ‘.app’ extension. The Info.plist file was probably the most complicated to recreate. The example from MDC is not very helpful, especially if you don’t know what your doing, and have to write it by hand. However there is a “Property List Editor” application on Mac, which will help you create the file.
Property List Editor
These are the properties which must be in your Info.plist file, for your XULRunner application to work. Key fields which are important are:
| Executable File | This is the name of the xulrunner stub file in the MacOS directory |
| Icon File | The name of your Icon in the Resources directory |
| Bundle name | Name of the .app directory |
The actually XML file looks like this:
<?xml version=“1.0″ encoding=“UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=“1.0″>
<dict>
<key>CFBundleDevelopmentRegion</key>
<string>English</string>
<key>CFBundleExecutable</key>
<string>XRap</string>
<key>CFBundleGetInfoString</key>
<string>XRap 0.9</string>
<key>CFBundleIconFile</key>
<string>xulwizard-window</string>
<key>CFBundleIdentifier</key>
<string>net.sourceforge.xrap</string>
<key>CFBundleInfoDictionaryVersion</key>
<string>6.0</string>
<key>CFBundleName</key>
<string>XRap</string>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleShortVersionString</key>
<string>0.9</string>
<key>CFBundleSignature</key>
<string>Mac</string>
<key>CFBundleVersion</key>
<string>0.9</string>
<key>NSAppleScriptEnabled</key>
<true/>
</dict>
</plist>
Its best to do all your work in your application directory, before adding the .app extension, because then it is treated like a file, and you will be unable to enter the directory, unless you remove the extension.
In refactoring XRap, I was still able to access the directory even though it was a .app. Using nsIFile to add files (the License), and read the application.ini, with no problem. In packaging, using pkg-dmg script, I had to create a staging area (temporary directory) and copy the .app into it, because the script only accepts directories to be imaged. If I tried to image the .app, it would image it as a directory and add .dmg to the end, defeating the purpose.
Well now I am proud to say that Mac packaging is complete. You can now package an application as an dmg image. When a user downloads the image, all they need to do is mount it, and run your app.
I want to eat an apple now.
March 11, 2009
Using Mozilla to create a dmg…Part II
I finally got access to a Mac which I can develop on, and after about 30 minutes of learning how to use it (I haven’t used one since grade school), it was amazing! Yes I want a Macbook now, but that’s another post. The first job for creating a dmg on a Mac using the Mozilla code, is actually getting it to run XUL apps. To do this you must first download and install XULRunner, which conviently for Mac is just a standard installer. Once installed, the XULRunner runtime is placed in:
/Library/Frameworks/XUL.framework/
This will make available ‘xulrunner-bin’, which will be needed to run the XUL app. I noticed (and liked) that the XULRunner runtime is installed in a default location similar to Linux and unlike Windows, where it is just where you put it, and you have to set a bunch of environment variable to point to it. To run a XUL app, is almost just as easy, there are two ways:
Install the application:
/Library/Frameworks/XUL.framework/xulrunner-bin –install-app /absolute/path/to/app.zipRun the application (without install):
/Library/Frameworks/XUL.framework/xulrunner-bin /absolute/path/to/application.ini
If you choose to install the application, it can be a XUL app packaged in a zip file or a folder of a XUL app, but it will conviniently put your installation into the:
/Applications/<vendor>/<appName>/
You can then run the app. If your developing, it may be a better idea to simply run the application, however there is a warning on MDC that the menu bar and dock icon may be missing. From experience, on my first run, the command executed, and I got nothing, and the bash prompt appeared, so I ran it again and I received a message that the app was already running. No window opened or anything, so I just closed the Terminal, refactored my code (I think there were some errors in it), and ran it again, with success.
Once I got my app working, running the ‘pkg-dmg‘ was simple, and it worked brilliantly! From mozilla-central, I stored only the folders leading to the ‘pkg-dmg’ file, then all the files in the folder. So basically, ‘mozilla-central/build/package/mac_osx/‘ , then all the files in /mac_osx. I made some modifications for my XRap release, by putting ‘pkg-dmg’ command in a script and calling it, but this is basically how it should work:
var getWorkingDir= Components.classes["@mozilla.org/file/directory_service;1"] .getService(Components.interfaces.nsIProperties) .get(“CurProcD”, Components.interfaces.nsIFile);
var dmgLoc = getWorkingDir.clone();
dmgLoc.append(“mozilla-central”);
dmgLoc.append(“build”);
dmgLoc.append(“package”);
dmgLoc.append(“mac_osx”);
dmgLoc.append(“pkg-dmg”);
process.init(file);
var args = ["--source ",applicationPath ," --target ",applicationPath + ".dmg"];
process.run(true,args,args.length);
And work it did! Here is an example, when I called it from bash
Mount and go!
March 8, 2009
Using Mozilla to create a dmg…Part I
After some confusing conversations over IRC on how I should go about creating a distribution package for Mac, it was suggested that I create a dmg. A dmg is essentially an image which can be mounted as a drive, and found by the Finder. I was then directed to a file in mozilla-central called pkg-dmg, which is a perl script that packages and creates the dmg! After reading through the code, and trying to figure out how it works, it seemed pretty simple.
>pkg-dmg –source <source-folder> –target <target-folder>
After pulling the latest code from mozilla-central, I located the script in ‘mozilla-central/build/package/mac_osx/pkg-dmg‘, unfortunately I don’t have access to a Mac, and will have to wait until next week to test out the script and my code. But, just for fun I ran the script on my Linux box, and got repeated error messages that ‘hdiutil’ was not present. Hdiutil is a Mac utility used for manipulating disk images, therefore an essential component for the pkg-dmg script.
Next step…Find a Mac! (not that hard, should be done next week)
February 25, 2009
Packaging…Mac…???
Yes. I need to figure out how to package up a XULRunner app, so that it can be distributed and installed on to a Mac.
From what I have been reading, there are two methods for installing on a Mac:
-
- The software publisher has provided an installer, which will automatically install the application
- The software is packaged in the form of an application (.app), framework (.framework), plug-in (.plugin), Safari downloads (.download), and installer packages (.pkg)
I have found a manual install method, which simply taking the .app file and putting it into /Applications, any documentation in the /Library/Documentation, and framework into the /Library/Frameworks. The only problem is that XULRunner apps have a strict directory structure to maintain, which is actually one of the problems I am having for my Linux distribution. I found the Apple Software Delivery Guide, which is awesome! but I’ll still have to hop on IRC and findout more about XULRunner apps. I may find myself having to overhaul my Linux distribution of XRap, depending on what I learn about Mac packages.
