16
edits
XUL:XUL Application Packaging: Difference between revisions
Jump to navigation
Jump to search
m
→Proposal implcations for Xul Runner
| Line 55: | Line 55: | ||
How does one package and ship apps? We will use a zip file as the distributable. See XUL:Installation_Story for how this works with the install strategy for Windows users. On Mac or Unix, the "install" would consist of simply expanding the zip file automatically. | How does one package and ship apps? We will use a zip file as the distributable. See XUL:Installation_Story for how this works with the install strategy for Windows users. On Mac or Unix, the "install" would consist of simply expanding the zip file automatically. | ||
== | == Implications of this proposal on XULRunner == | ||
* take folders, not ini files as the | * take folders, not ini files as the XULRunner file argument on startup | ||
* Macs would tend to reuse the same process to load multiple applications - not the behavior desired for XULRunner. 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?) | |||
== Background information == | == Background information == | ||