XUL:XUL Application Packaging: Difference between revisions

XUL:XUL Application Packaging (view source)

Revision as of 02:26, 28 April 2005

16 bytes removed , 28 April 2005

m

no edit summary

Skylar

16

edits

@@ Line 1: / Line 1: @@
 The following is a ''proposal'' for how to package XUL applications targeted at XUL Runner.
-(Currently, there is no code in the tree that supports this, nor are there examples in the tree that demonstrate proposal completely.)
+(Currently, there is no code in the tree that supports this, nor are there examples in the tree that demonstrates the proposal completely.)
 == Package Structure ==
@@ Line 11: / Line 11: @@
 defaults - directory - contains default preferences for the application
-== application.ini ==
+=== application.ini ===
 More info coming...
@@ Line 22: / Line 22: @@
 === From the command line ===
-==== Windows ====
+'''Windows'''
 <tt>xulrunner.exe path_to_package/myapplication.xulapp</tt>
-==== Unix ====
+'''Unix'''
 <tt>xulrunner path_to_package/myapplication.xulapp</tt>
-==== Mac OS X ====
+'''Mac OS X'''
 <tt>open -a Xulrunner.app path_to_package/myapplication.xulapp</tt>
@@ Line 36: / Line 36: @@
 === From the desktop UI ===
-==== Windows ====
+'''Windows'''
 A shortcut is created by the application installation process that points to XULRunner with the application package as the command line parameter.
-==== Unix ====
+'''Unix'''
 TBD
-==== Mac OS X ====
+''' Mac OS X'''
 The structure of a XUL application package is complient with Apple's requirements for document bundles:
@@ Line 58: / Line 58: @@
 == Proposal implcations for Xul Runner ==
-* take folders, not ini files as the xulrunner file
+* take folders, not ini files as the xulrunner file argument on startup
-argument on startup
-* Macs would tend to reuse the same
+* Macs would tend to reuse the same process to load multiple applications - not the behavior desired for Xul Runnner.  Rather than try to repackage chromes/extensions as executable bundles using a common lib (the GRE approach), we should have xulrunner act more as a launcher to effectively fork off a new process.  (similar to how firefox behaves when loading new extensions on startup?)
-process to load multiple applications - not the
-behavior desired for Xul Runnner.  Rather than try to
-repackage chromes/extensions as executable bundles
-using a common lib (the GRE approach), we should have
-xulrunner act more as a launcher to effectively fork
-off a new process.  (similar to how firefox behaves when loading new extensions on startup?)
@@ Line 74: / Line 67: @@
 Mac OS X factors that affect our strategy for application packaging and loading:
-* Mac users expect drag-and-drop install of
+* Mac users expect drag-and-drop install of applications.   The shipping "app" package must be ready to run after download and decompression.  Also,
-applications.   The shipping "app" package must be
+embedding installers in the download process (active-x/xul helpers) is rather difficult to infeasible in the mac world, and requiring installers only hinders the ease of packaging and installation of software for an already small target audience.
-ready to run after download and decompression.  Also,
-embedding installers in the download process
-(active-x/xul helpers) is rather difficult to
-infeasible in the mac world, and requiring installers
-only hinders the ease of packaging and installation of
-software for an already small target audience.
-* Mac applications must be loaded by Launch Services.
+* Mac applications must be loaded by Launch Services.  This happens by actions that evoke app loading such as double-clicking on the app in the finder,
-This happens by actions that evoke app loading such as
+double-clicking a document related to an app, or executing "open [app]" at the command line.  If we want to pass a paramater to a properly launched app, we need to use a compatible way to do that (ODOC event posted to launched app).
-double-clicking on the app in the finder,
-double-clicking a document related to an app, or
-executing "open [app]" at the command line.  If we
-want to pass a paramater to a properly launched app,
-we need to use a compatible way to do that (ODOC event
-posted to launched app).