Closed
Bug 286147
Opened 20 years ago
Closed 20 years ago
switch from .xulapp to application.ini
Categories
(Toolkit Graveyard :: XULRunner, defect, P1)
Toolkit Graveyard
XULRunner
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: darin.moz, Assigned: darin.moz)
References
Details
Attachments
(2 files, 3 obsolete files)
737 bytes,
patch
|
Details | Diff | Splinter Review | |
25.59 KB,
patch
|
benjamin
:
first-review+
|
Details | Diff | Splinter Review |
switch from .xulapp to application.ini
bsmedberg and i discussed moving from name.xulapp to a generic application.ini.
it seems like a good idea for a number of reasons:
(1) no need to do file association with this file (installers should create
symlinks, shell scripts, etc.)
(2) nice to be able to have a known filename in each XUL app instead of having
to guess the name based on application name or based on looking for files ending
with the extension .xulapp.
We also want to tweak our build system so that application.ini will be passed
through preprocessor.pl before being copied into the application staging
directory (dist/xpi-stage/$appname).
Assignee | ||
Updated•20 years ago
|
Severity: normal → major
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta2
Comment 1•20 years ago
|
||
>(1) no need to do file association with this file (installers should create
>symlinks, shell scripts, etc.)
but you'd also lose the ability to double-click the file, right?
Assignee | ||
Comment 2•20 years ago
|
||
> but you'd also lose the ability to double-click the file, right?
right, we figured that that just isn't very useful.
Comment 3•20 years ago
|
||
To be more precise, it isn't nearly as useful as associated the XULRunner with
packed (zipped) myapplication.xulapp files, which will then be unpacked/installed.
Assignee | ||
Comment 4•20 years ago
|
||
> To be more precise, it isn't nearly as useful as associated the XULRunner with
> packed (zipped) myapplication.xulapp files, which will then be unpacked/installed.
But, that's a poor argument since we could have two distinct file extensions:
one for the packaged extension and one for the INI file that is passed on the
command line to xulrunner.
Comment 5•20 years ago
|
||
it seems to me that we should not only support launching applications via the
start menu. being able to just copy the application directory to another
computer seems useful (of course this will still only work if xulrunner is
installed...)
Comment 6•20 years ago
|
||
I am not wedded to the "ini" extension... a more unique extension like .xini or
.xinfo or .xapp would be fine with me. The important parts of my proposal are:
1) every application ought to have the same filename
simple/application.xini
hexminesweeper/application.xini
jar:hexminesweeper.xpi!/application.xini
2) .xulapp should be the extension for a packaged application that should be
installed
Assignee | ||
Comment 7•20 years ago
|
||
Let's stick with application.ini for now as there are some benefits to giving
the file an extension that corresponds to its actual type ;-)
There are tools out there such as MSI that know how to modify INI files, so it
might be useful to have it named accordingly. I can't really think of any such
cases off the top of my head, but without anything compelling me in another
direction, I'm happy to just stick with application.ini.
Assignee | ||
Comment 8•20 years ago
|
||
This patch includes changes to rules.mk to simplify building XUL apps within
the tree. If it sees the variable XULAPP defined, then it proceeds to attempt
to preprocess application.ini and copy over chrome.manifest. I also fixed up
the handling of PREF_JS_EXPORTS to properly install prefs into
defaults/preferences instead of defaults/pref when XPI_NAME is defined. That
makes sense for extensions as well as for XULRunner-based apps.
To prove that this is a nice solution, I went ahead and converted layout
debugger as well as the XULRunner simple example to use the new build fu. I
think the result is pretty decent.
Attachment #177683 -
Flags: first-review?(benjamin)
Comment 9•20 years ago
|
||
Comment on attachment 177683 [details] [diff] [review]
v1 patch
>+# Special handling for XULRunner-based applications
>+ifeq ($(XULAPP),1)
ifdef XULAPP
but I don't like hardcoding these two files anyway. Why can't we add a generic
makefile var:
DIST_FILES = application.ini chrome.manifest extension.rdf install.js ...
And preprocess these generically. Then add the -DBUILD_ID and whatever else to
the individual makefile DEFINES. The gecko_version_major/minor stuff looks like
good fodder for config.mk.
Attachment #177683 -
Flags: first-review?(benjamin) → first-review-
Assignee | ||
Comment 10•20 years ago
|
||
> DIST_FILES = application.ini chrome.manifest extension.rdf install.js ...
Ok, interesting idea. How would rules.mk know that application.ini belongs in
FINAL_TARGET and chrome.manifest belongs in FINAL_TARGET/chrome? Should
rules.mk check the name of each file to determine this?
BTW, in these examples we're really only talking about chrome.manifest, which
was going to go away anyways, right? I'm using XULAPP=1 to specify that
application.ini should be installed into FINAL_TARGET... are you objecting to
that as well?
> And preprocess these generically. Then add the -DBUILD_ID and whatever else to
> the individual makefile DEFINES. The gecko_version_major/minor stuff looks
> like good fodder for config.mk.
BUILD_ID seems like a fairly standard thing to add to config.mk as well, don't
you think?
Comment 11•20 years ago
|
||
(In reply to comment #10)
> Ok, interesting idea. How would rules.mk know that application.ini belongs in
> FINAL_TARGET and chrome.manifest belongs in FINAL_TARGET/chrome? Should
> rules.mk check the name of each file to determine this?
Hrm, does chrome.manifest belong in {app}/chrome/ ? In extensions it goes in the
root directory {extension}/chrome.manifest. Sounds like a mismatch we ought to
fix. What do you think of just having {app}/chrome.manifest instead of
{app}/chrome/*.manifest ?
> was going to go away anyways, right? I'm using XULAPP=1 to specify that
> application.ini should be installed into FINAL_TARGET... are you objecting to
> that as well?
Well, I want to give the build system flexibility such that you can ship an
application.ini, install.rdf, and install.js using the same basic rule.
> BUILD_ID seems like a fairly standard thing to add to config.mk as well, don't
> you think?
Sure.
Assignee | ||
Updated•20 years ago
|
Priority: -- → P1
Comment 12•20 years ago
|
||
I have something like this in my tree right now, which I use to package a
chrome.manifest from calendar/lightning. I'm very motivated to get _some_ such
mechanism in the tree, so that I can check my changes in.
Assignee | ||
Comment 13•20 years ago
|
||
yikes.. i already have something in my tree too.. i'll take a look at your
approach asap.
Assignee | ||
Comment 14•20 years ago
|
||
shaver: so for XUL apps, I was not defining XPI_PKGNAME. as a result, your
patch wouldn't really address this problem. but, your problem could be solved
by the DIST_FILES makefile variable that bsmedberg proposed and which I have
implemented in my tree.
Comment 15•20 years ago
|
||
Yeah, I'm not religiously attached to that approach, or indeed to the
XPI_PKGNAME stuff at all -- being able to share infrastructure with XULRunner
apps would be a major win. I checked in a tiny interim patch so that I could
make Lightning use chrome.manifest, but I stand ready to convert to a more
righteous system, such as the DIST_FILES stuff.
Assignee | ||
Comment 16•20 years ago
|
||
Attachment #177683 -
Attachment is obsolete: true
Attachment #178636 -
Flags: first-review?(benjamin)
Assignee | ||
Comment 17•20 years ago
|
||
shaver: it'd be great if you could take a look at this patch too.
Comment 18•20 years ago
|
||
Comment on attachment 178636 [details] [diff] [review]
v2 patch
Can we have the milestone.pl thing spit out separate major and minor versions,
such that we can concatenate them to the MOZILLA_VERSION, rather than splitting
them?
Is XPI_NAME the right name? I'm not emotionally attached to it, and it seems
like we almost want a broader name that covers both "extension" and "standalone
XULRunner app" -- maybe XPI is good, just want to make sure my snap naming
before doesn't constrain us overly.
Patch looks pretty good; I'll try to convert Lightning to use such a patch to
make sure it all works for that case, when I get a chance.
Assignee | ||
Comment 19•20 years ago
|
||
> Can we have the milestone.pl thing spit out separate major and minor versions,
> such that we can concatenate them to the MOZILLA_VERSION, rather than
> splitting them?
Yeah, that's an option. But, this is done, and I'm not sure there is that much
benefit to changing the way these things are generated.
> Is XPI_NAME the right name?
Yeah, I'm not sure I like XPI_NAME and dist/xpi-stage, but bsmedberg did try to
convince me once that XUL apps probably should just be thought of as XPIs. They
are XPIs without install.rdf or install.js :-)
The idea here is that XUL apps will be delivered as zipped up packages that are
installed by XULRunner onto the system. We may end up choosing a different file
extension for distribution over the web, or we might even stick with XPI. I'm
not sure yet.
So, for now... XPI_NAME is fine.
Assignee | ||
Comment 20•20 years ago
|
||
The v2 patch was missing changes to toolkit/xre.
Attachment #178636 -
Attachment is obsolete: true
Attachment #178644 -
Flags: first-review?(benjamin)
Assignee | ||
Updated•20 years ago
|
Attachment #178636 -
Flags: first-review?(benjamin)
Assignee | ||
Comment 21•20 years ago
|
||
dang it.. and the v2.1 patch was missing newly added files. (sorry for the
spam)
Attachment #178644 -
Attachment is obsolete: true
Attachment #178672 -
Flags: first-review?(benjamin)
Assignee | ||
Updated•20 years ago
|
Attachment #178644 -
Flags: first-review?(benjamin)
Comment 22•20 years ago
|
||
Comment on attachment 178672 [details] [diff] [review]
v2.2 patch
Please explain why the "changequote" directives are required.
Attachment #178672 -
Flags: first-review?(benjamin) → first-review+
Assignee | ||
Comment 23•20 years ago
|
||
changequote is needed because my regular expressions contain '[' and ']'
characters, which are the default quoting characters for configure.in when m4 is
run.
Assignee | ||
Comment 24•20 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 25•20 years ago
|
||
so... why the -DBUILD_ID, can't code just #include "nsBuildID.h" and use that?
Assignee | ||
Comment 26•20 years ago
|
||
(In reply to comment #25)
> so... why the -DBUILD_ID, can't code just #include "nsBuildID.h" and use that?
because we wanted it to apply to application.ini and various other preprocessed
files. is there a reason why -DBUILD_ID is bad?
Comment 27•20 years ago
|
||
(In reply to comment #26)
> is there a reason why -DBUILD_ID is bad?
Nah, it just felt redundant to me...
Comment 28•19 years ago
|
||
W.r.t. these last few comments, also see bug 293455.
Updated•18 years ago
|
Flags: in-testsuite-
Updated•9 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•