XULRunner: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(obsolete)
 
(59 intermediate revisions by 34 users not shown)
Line 1: Line 1:
<table style="float: right; border: 1px solid #999;">
{{RELEASE_MANAGEMENT_OBSOLETE}}
<tr><td>
* [[XUL:Home Page]]
{{XUL:XUL_Runner_TOC}}
</table>


XULRunner is a single
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.
installable package that can be used to bootstrap multiple XUL+XPCOM
applications that are as rich as Firefox and Thunderbird.


= The XULRunner Runtime =
* [[XULRunner:Roadmap|XULRunner Roadmap]]


XULRunner should contain most of the common functionality expected by developers of rich internet applications. XULRunner will include:
== TODOs ==


* [[XPCOM]]
A core requirement of XULRunner is the elimination of any app-specific
* Networking
<code>#ifdef</code>s.  It does us no good if portions of the toolkit are
* Gecko rendering engine
<code>#ifdef MOZ_PHOENIX</code> or <code>#ifdef MOZ_THUNDERBIRD</code>. See the [http://developer.mozilla.org/docs/When_To_Use_ifdefs ifdef Manifesto].
* core DOM editing and transaction support (no UI)
* Cryptography
* XUL language support, with its related XBL/RDF technologies and widgets useful for application development
* [[SVG]] (when ready)
* [[XSLT]]
* XML Extras
* Web Services
* Extension Manager
* Auto-update support
* typeahead-find toolbar
* history implementation
* accessibility support
* APIs and user interface for installing, uninstalling, and upgrading XUL applications. See the [[XUL:Installation Story]].
* IPC services for communication between gecko-based apps
* RDF APIs
* docshell/window-targeting implementation (needs specification by bz!)


XULRunner will supply the following user interface elements, which may be overridden by embedders:
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]].


* File picker (will use native OS filepicker as appropriate)
== The XUL Development Kit ==
* Find toolbar
* Helper app dialog/UI
* Security UI (maintenance of SSL keychains, etc)
 
XULRunner will not supply:
* Bookmarks
* More here!...
 
XULRunner might include:
* LDAP support
* Spellchecking support (with or without dictionaries provided) see [https://bugzilla.mozilla.org/show_bug.cgi?id=285977 bug 285977]
* Core support for profile roaming (with application-specific extensibility)
* [[XForms]] (if not shipped by default, would be available as a core extension)
 
Also, a core requirement of XULRunner is the elimination of any app-specific
<code>#ifdef</code>'s.  It does us no good if portions of the toolkit are
<code>#ifdef MOZ_PHOENIX</code>. (See [https://bugzilla.mozilla.org/show_bug.cgi?id=285789 bug 285789]).
 
= 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:
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:
Line 63: Line 22:


* 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.
* 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.
= Technical Details =
== How do I build it? ==
Building XULRunner is a lot like [http://www.mozilla.org/build/ building any other Mozilla application].
Start by pulling <code>client.mk</code> from CVS:
<pre>
$ cvs co mozilla/client.mk
</pre>
Setup a <code>mozconfig</code> file.  Here's what mine looks like:
<pre>
$ cat $MOZCONFIG
export MOZILLA_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
. $topsrcdir/xulrunner/config/mozconfig
</pre>
If you want to build debug, then include these options:
<pre>
ac_add_options --enable-debug
ac_add_options --disable-optimize
</pre>
If you are building on Linux, then you'll probably want to add these
options as well:
<pre>
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --enable-xft
ac_add_options --disable-freetype2
</pre>


After you have built XULRunner, try running the sample XULRunner application:
After you have built XULRunner, try running the sample XULRunner application:
Line 106: Line 30:
</pre>
</pre>


Not much to see, I know.  But, take a look at the contents of the <code>apps/simple</code>
Not much to see, I know.  But, take a look at the contents of the <code>xpi-stage/simple</code>
directory.  Pretty simple (for a Mozilla-based app), wouldn't you say?  Check out [http://lxr.mozilla.org/mozilla/source/xulrunner/examples/simple/application.ini application.ini]
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.


== User Profiles ==
== User Profiles ==
Line 138: Line 62:
participate in profile sharing.  The goal here is to allow applications
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,
to share data that is common to the web platform such as SSL certificate,
cookies, and the web cache.  (See also: [[Mozilla2:Profile_Sharing]].)
cookies, and the web cache.  (See also: [[Mozilla2:Profile Sharing]].)


== Versioning ==
== Versioning ==
Line 158: Line 82:
application that does not pass the version test.
application that does not pass the version test.


Some relatively old notes: [[XUL:Xul_Runner_Versioning]]
Some relatively old notes: [[XUL:Xul Runner Versioning]]
 
= Automating Builds =
[http://tinderbox.mozilla.org/showbuilds.cgi?tree=XULRunner Current XULRunner build status]
 
'''TODO'''
* Allocate and configure build system resources
** win32: testing configuration on sweetlou
** linux: ?
* Run automated builds
* Package results
* Publish to FTP site
 
= What needs to be done? =
 
[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]
 
TODO: turn this into a bug list
 
<ul>
 
<li>
<b>TODO -- Verify UA string</b>.
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 ==
<b>TODO</b>
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> DONE (except for xremote)
See also: [[XULRunner:Faq]]
[[XUL:Command_Line_Handling]] : better (generic) command-line handling APIs


<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]
<b>TODO -- Verify</b>.
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. See [https://bugzilla.mozilla.org/show_bug.cgi?id=280725 bug 280725].


<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.
<b>TODO</b>
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.
<ul>
<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] </li>
</ul>


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


</ul>
[[category:XULRunner|*]]

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"