XULRunner: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(obsolete)
 
(106 intermediate revisions by 39 users not shown)
Line 1: Line 1:
= XULRunner =
{{RELEASE_MANAGEMENT_OBSOLETE}}


== Overview ==
These pages on wiki.mozilla.org are about XULRunner development and planning. If you want more information about developing or using XULRunner-based applications, visit the [[MDN:XULRunner|Mozilla Developer Network]], which includes documentation on building, running, and deploying XULRunner.


The goal of the XULRunner application is to provide a lightweight
* [[XULRunner:Roadmap|XULRunner Roadmap]]
container application that can be used to bootstrap XUL+XPCOM
applications that are as rich as Firefox and Thunderbird. See also
[[XUL:Lib_XUL|libxul]] .


== Profiles ==
== TODOs ==


An application running on top of the XULRunner should have a fully
A core requirement of XULRunner is the elimination of any app-specific
managed profile directory.  ("Managed" meaning that each app built
<code>#ifdef</code>s.  It does us no good if portions of the toolkit are
on top of XULRunner should have its own <em>vendor/appname</em> directory
<code>#ifdef MOZ_PHOENIX</code> or <code>#ifdef MOZ_THUNDERBIRD</code>. See the [http://developer.mozilla.org/docs/When_To_Use_ifdefs ifdef Manifesto].
for storing profile information.)


'''An application developer should not have to think too hard about profile details!'''
The build system must be extended so that it is possible to build XULRunner in one objdir and applications in separate objdirs, propagating compiler feature tests from configure tests and keeping makefile configurations separate. See [[XULRunner:Build System Rework]].
''What about sharing profile data (f.e., installed certs between xulrunnerized firefox/tbird)?  Not an uncommon request.''


== What's ''in'' XULRunner? ==
== The XUL Development Kit ==


XULRunner should basically be Firefox without everything under the
In addition to the XULRunner runtime, the XULRunner build process will produce a Development Kit which contains tools for building XUL applications and extensions. As a first goal, these tools will provide:
<code>browser/</code> directory.  That means that it includes all the
core "new" toolkit stuff that Firefox and Thunderbird currently share,
including the extension manager.  What is finally included in XULRunner
is of course entirely up for debate ;-)


== Where's development happening? ==
* A build environment without all of the complexity of the Mozilla system for applications which consist entirely of XUL+JS (no binary components). This environment will produce extension XPIs and various kinds of xulapp installers.


Development has now moved to the trunk.  See
* Web and XUL development tools that already have been developed, including DOM Inspector and Venkman JS Debugger
[https://bugzilla.mozilla.org/show_bug.cgi?id=257162 bug 257162] for details.
It is known to build under Linux (and Windows with some minor hacking
in toolkit/mozapps/installer).


== How do I build it? ==
* A reference tool which will contain quick reference information for web and XUL development with links to the full reference information from developer.mozilla.org.


Building XULRunner is a lot like building any other Mozilla application.
After you have built XULRunner, try running the sample XULRunner application:
Start by pulling <code>client.mk</code> from CVS:


<pre>
<pre>
$ cvs co mozilla/client.mk
$ cd dist/bin
$ ./xulrunner ../xpi-stage/simple/application.ini
</pre>
</pre>


Setup a <code>mozconfig</code> file.  Here's what mine looks like:
Not much to see, I know.  But, take a look at the contents of the <code>xpi-stage/simple</code>
<pre>
directory.  Pretty simple (for a Mozilla-based app), wouldn't you say?  (cough)  Check out [http://lxr.mozilla.org/mozilla/source/xulrunner/examples/simple/application.ini application.ini]. See [http://developer.mozilla.org/en/docs/XUL_Application_Packaging XUL Application Packaging] for documentation on application.ini.
$ cat $MOZCONFIG
 
export MOZILLA_OFFICIAL=1
== User Profiles ==
mk_add_options MOZILLA_OFFICIAL=1
 
An application running on top of the XULRunner has a fully
"managed" profile directory for storing user specific data.
XULRunner sets up the profile directory for applications
automatically, and it uses the same profile locking mechanism
used by existing applications like Firefox and Thunderbird.
 
The profile directory for an application is created under
<em>vendor/appname</em> in the appropriate place on the user's
system.  For example, under Windows this would be:
 
$USERPROFILE\Application Data\$vendor\$appname\Profiles\$random.default


mk_add_options MOZ_CO_PROJECT=xulrunner
And under Unix systems it would be:
ac_add_options --enable-application=xulrunner


ac_add_options --enable-debug
$HOME/.$vendor/$appname/Profiles/$random.default
ac_add_options --disable-optimize
</pre>


If you are building on Linux, then you'll probably want to add these
Where <code>$vendor</code> and <code>$appname</code> are chosen by the
options as well:
XUL application, and <code>$random</code> is generated by XULRunner to
<pre>
obscure the location of the user's profile data.
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2
</pre>


== Ok, I built it.  So, now what? ==
The goal of this approach is to eliminate the need for the application
developer to think about profile details.  The default configuration
should simply work without much fuss.


Try running the sample XULRunner application:
Down the road, we will want to allow XULRunner-based applications to
participate in profile sharing.  The goal here is to allow applications
to share data that is common to the web platform such as SSL certificate,
cookies, and the web cache.  (See also: [[Mozilla2:Profile Sharing]].)


<pre>
== Versioning ==
$ cd dist/bin
$ ./xulrunner apps/simple/simple.xulapp
</pre>


== What needs to be done? ==
XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API.
It is an API that has historically evolved over time, and it will likely
continue to evolve for some time to come.  While people agree that we need to
stablize that API, it will not happen overnight.


<ul>
For these reasons, it is important that XULRunner support applications that
<li>
require specific versions of the toolkit.  The current thinking is that
'''RESOLVED -- This problem has been completely eliminated
XULRunner will be versioned (with version number matching the corresponding
by bsmedberg's patch for bug 278534.  That patch
Gecko milestone), and applications will be able to specify the version(s) of
makes it so that XUL app authors never need to write
the toolkit that they require.
resource://app/.'''
Need to improve the way we specify resources in the  
application directory.  Currently, this is done with
<code>resource://<b>app</b>/path/to/some/file</code>,
but bsmedberg points out that it might be better to  
make <code>resource:///path/to/some/file</code> point
into the application directory.  This requires coming
up with a new resource key to specify resources located
in the XULRunner directory.  "xre" or even
"gre" come to mind.
''We settled on resource://app/ afterall.''


<li>
This is in fact already implemented as options in the <code>.xulapp</code> file.
Need to write out <code>chrome.rdf</code> for chrome
Applications can specify a <code>MinVersion</code> and <code>MaxVersion</code>
files located in the application directory. Currently,
for the toolkit versions they require. XULRunner will refuse to load an
XULRunner looks for <code>chrome/installed-chrome.txt</code> in the
application that does not pass the version test.
application directory as well as in XULRunner's directory.
bsmedberg suggests persisting the chrome registry in the
profile directory instead of trying to manage multiple
<code>chrome.rdf</code> files.
''We decided to use the chrome.rdf in the
profile for chrome files under resource://app/chrome/.''


<li>
Some relatively old notes: [[XUL:Xul Runner Versioning]]
Need to make sure that there is a clear distinction
between the application's <code>{name, buildID, version}</code> info
and the corresponding info for XULRunner itself.  For
example, the UA string still needs to be generated properly.


<li>
== Buglist ==
Static references to the application name may be an issue.
For example, <code>mozilla.in</code> needs to know the vendor name and
application name in order to locate the profile-relative
<code>init.d</code> directory.  These strings can't be
statically defined anymore. ''Do we really care that much about <code>init.d</code>
stuff?  The init.d stuff is currently not supported.''


<li>
See also: [[XULRunner:Faq]]
Need to allow applications to more easily override
command line options.  bsmedberg has some ideas on this
subject at [[XUL:Command Line Handling]].


<li>
*[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=Toolkit&component=XULRunner&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&resolution=---&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= XULRunner bugs]
Need to make sure Xremote and Win32 DDE works properly.
By default, <code>-remote</code> should confine itself to
talking to the same application type.


<li>
*'''TODO -- Verify UA string'''<br />Need to make sure that there is a clear distinction between the application's <code>{name, buildID, version}</code> info and the corresponding info for XULRunner itself.  For example, the UA string still needs to be generated properly.
Need to support application icons.  Ben Goodger has some
ideas on this one.  There are really two parts to this task:
(1) under platforms that support it, it should be easy to
associate an icon with the launcher for a XUL app, and (2)
we should support window icons located outside the
<code>chrome/icons/default/</code> directory.


<li>
*'''TODO'''<br />Need to support application icons. The best way to do this is have the app author provide a suite of PNGs in various sizes, and then convert these to the native OS format (.ico, .icns, .xbm) at app-install time. See [https://bugzilla.mozilla.org/show_bug.cgi?id=314651 bug 314651] and [https://bugzilla.mozilla.org/show_bug.cgi?id=314030 bug 314030]
Need a fully app-independent toolkit. At the moment there are still a lot of places with #ifdef MOZ_PHOENIX or #if MOZ_THUNDERBIRD, which really [https://bugzilla.mozilla.org/show_bug.cgi?id=270235 hinders] app development for other toolkit apps. There are also some files (see bug [https://bugzilla.mozilla.org/show_bug.cgi?id=250868 250868], bug [https://bugzilla.mozilla.org/show_bug.cgi?id=250793 250793] and bug [https://bugzilla.mozilla.org/show_bug.cgi?id=250867 250867]), which are essentially the same for all toolkit apps, but have to be carried in every app-package, making bug-fixing and maintenance a real nightmare.


<li>
*WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension.  [http://www.codeproject.com/shell/shellextguide9.asp An ATL example]
Make it so that zero setup is required for app developers that want to
play with XUL. (Suggestion from nrm).<li>


<li>Make it possible to run xulrunner + app from read only media (CD's). Would be great for demoing webapps with webservice support etc.</li>
*Make it possible to run xulrunner + app from read only media (CDs). Would be great for demoing webapps with webservice support etc. Needs investigation, probably something that needs extensive volunteer help.


Other stuff...
[[category:XULRunner|*]]
</ul>

Latest revision as of 11:44, 27 December 2019

⚡ Warning: The content of this page is obsolete and kept for archiving purposes of past processes.

These pages on wiki.mozilla.org are about XULRunner development and planning. If you want more information about developing or using XULRunner-based applications, visit the Mozilla Developer Network, which includes documentation on building, running, and deploying XULRunner.

TODOs

A core requirement of XULRunner is the elimination of any app-specific #ifdefs. It does us no good if portions of the toolkit are #ifdef MOZ_PHOENIX or #ifdef MOZ_THUNDERBIRD. See the ifdef Manifesto.

The build system must be extended so that it is possible to build XULRunner in one objdir and applications in separate objdirs, propagating compiler feature tests from configure tests and keeping makefile configurations separate. See XULRunner:Build System Rework.

The XUL Development Kit

In addition to the XULRunner runtime, the XULRunner build process will produce a Development Kit which contains tools for building XUL applications and extensions. As a first goal, these tools will provide:

  • A build environment without all of the complexity of the Mozilla system for applications which consist entirely of XUL+JS (no binary components). This environment will produce extension XPIs and various kinds of xulapp installers.
  • Web and XUL development tools that already have been developed, including DOM Inspector and Venkman JS Debugger
  • A reference tool which will contain quick reference information for web and XUL development with links to the full reference information from developer.mozilla.org.

After you have built XULRunner, try running the sample XULRunner application: 

$ cd dist/bin
$ ./xulrunner ../xpi-stage/simple/application.ini

Not much to see, I know. But, take a look at the contents of the xpi-stage/simple directory. Pretty simple (for a Mozilla-based app), wouldn't you say? (cough) Check out application.ini. See XUL Application Packaging for documentation on application.ini.

User Profiles

An application running on top of the XULRunner has a fully "managed" profile directory for storing user specific data. XULRunner sets up the profile directory for applications automatically, and it uses the same profile locking mechanism used by existing applications like Firefox and Thunderbird.

The profile directory for an application is created under vendor/appname in the appropriate place on the user's system. For example, under Windows this would be: 

$USERPROFILE\Application Data\$vendor\$appname\Profiles\$random.default

And under Unix systems it would be: 

$HOME/.$vendor/$appname/Profiles/$random.default

Where $vendor and $appname are chosen by the XUL application, and $random is generated by XULRunner to obscure the location of the user's profile data.

The goal of this approach is to eliminate the need for the application developer to think about profile details. The default configuration should simply work without much fuss.

Down the road, we will want to allow XULRunner-based applications to participate in profile sharing. The goal here is to allow applications to share data that is common to the web platform such as SSL certificate, cookies, and the web cache. (See also: Mozilla2:Profile Sharing.)

Versioning

XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API. It is an API that has historically evolved over time, and it will likely continue to evolve for some time to come. While people agree that we need to stablize that API, it will not happen overnight.

For these reasons, it is important that XULRunner support applications that require specific versions of the toolkit. The current thinking is that XULRunner will be versioned (with version number matching the corresponding Gecko milestone), and applications will be able to specify the version(s) of the toolkit that they require.

This is in fact already implemented as options in the .xulapp file. Applications can specify a MinVersion and MaxVersion for the toolkit versions they require. XULRunner will refuse to load an application that does not pass the version test.

Some relatively old notes: XUL:Xul Runner Versioning

Buglist

See also: XULRunner:Faq

  • TODO -- Verify UA string
    Need to make sure that there is a clear distinction between the application's {name, buildID, version} info and the corresponding info for XULRunner itself. For example, the UA string still needs to be generated properly.
  • TODO
    Need to support application icons. The best way to do this is have the app author provide a suite of PNGs in various sizes, and then convert these to the native OS format (.ico, .icns, .xbm) at app-install time. See bug 314651 and bug 314030
  • WorldMaker: In Windows icons for (say) .xulapp could be handled via a simple shell extension. An ATL example
  • Make it possible to run xulrunner + app from read only media (CDs). Would be great for demoing webapps with webservice support etc. Needs investigation, probably something that needs extensive volunteer help.
Retrieved from "https://wiki.mozilla.org/index.php?title=XULRunner&oldid=1221654"