54356 - Allow XPToolkit applications to be real OS applications

Status: RESOLVED WORKSFORME

(Core :: XUL, enhancement, P3)

Description

[Matthew T (active 1999-2002)]

This should go in the `Architecture' component, but there isn't one.

To reproduce:
* Put an icon for a Mozilla application (e.g. Navigator) in a folder containing
  applications and documents.
* Show the folder in List/Details view, and sort the contents of the folder by
  file type.
What should happen:
* The application appears in the midst of all the applications.
What actually happens:
* The application appears in the midst of all the documents.

This is a request for XPToolkit applications to *be* proper applications on any
OS on which Mozilla runs, rather than just documents opened by Mozilla. This
would have the following benefits (among others):
* files of particular types could be associated with the appropriate XPToolkit
  application, rather than just being associated with Mozilla in general;
* individual XPToolkit applications would appear as individual items in `Choose
  Application' dialogs on Windows and Mac OS (e.g. when a file of unknown type is
  opened);
* individual XPToolkit applications would be able to have their own (permanent)
  icons;
* individual XPToolkit applications would have at least *some* chance of crashing
  without taking everything else Mozilla-related with them.

So, how to do this while preserving XPToolkit's write-once run-anywhere promise?
I suggest the following approach. I don't know *that* much about Mozilla's
architecture, so a fair bit of this sketch is probably wrong-headed, but
here goes anyway.

* A general file type .moz (application/x-moztoolkit) is used to represent an
  application which will be run by Mozilla. On Windows and Unix, instead of the
  current plethora of application-specific command lines for the mozilla
  executable, the command line `mozilla -app appPath.moz' is used. On Mac OS,
  the application/x-mozilla documents would supplant the current `decode
  documents' (those which contain ARGS:-* lines).

* A software author should include one (1) application/x-moztoolkit document for
  every MozToolkit application se writes. It should contain:
  - the name of the application
  - the XUL document that should be loaded when the application starts up
  - the URL(s) (usually relative file URLs) of the icon(s) for the application
  - the creator code for files created by the application (used on Mac OS only).

* When an application/x-moztoolkit document is dragged onto Mozilla's icon or
  opened by Mozilla in another way (via platform-level file mapping of .moz to
  Mozilla, or via the platform's `Choose Application' dialog for a file of
  unknown type), Mozilla creates a bare-bones native application out of the
  MozToolkit document, and places it in the same directory as the document.
  
  This application in itself does little more than direct the Mozilla subsystem
  to open the XUL etc associated with that application. However, it means that
  the current application (as far as the OS is concerned) is `Composer' or
  `Theme Builder' or `Aphrodite', rather than `Mozilla', while the application is
  running. It also means that the application can have an appropriate icon,
  instead of a generic Mozilla icon.

Comment 1

[Doron Rosenberg (IBM)]

mpt - should we cc: XPT? setting nobody as owner till this is picked up

Comment 2

[Matthew T (active 1999-2002)]

Duh! Thanks for the clue-stick, Doron. Kicking over to XPToolkit/Widgets.

Comment 3

[Peter Trudelle]

As written, this sounds more like a request to hide from the user the fact that
they are not separate applications in the usual sense, which may be more XPApps
territory.  I think being up-front about the true situtation is better than
trying to use fakery, but I agree that they should be real, separate apps, in
their own processes and address spaces, sharing DLLs and cooperating closely,
but not susceptible to causing a common crash.  That would be an architectural
change.

->future

Comment 4

[Ben Bucksch (:BenB)]

Creating the filetype and make it work (assuming MacOS works as I understood
from your description) would be relatively easy. The larger problems is to "make
the seperate Mozilla instances play nicely with one another" right now, Mozilla
assumes it is the only Mozilla instance running. As a result, it just overwrites
the user's prefs.js. There are other examples I don't remember, there was some
discussion I and dmose and shaver were involded in on the newsgroups about it
some time (0.75 years?) ago.

> individual XPToolkit applications would have at least *some* chance of
> crashing without taking everything else Mozilla-related with them.

This would indeed be the largest advantage IMO. Note that under Unix it would
almost *garantee* that two Mozilla apps don't crash each other.

YOu can try this right now. Just start Mozilla 2 times (luckily for me, we don't
prevent that). It mostly works.

Comment 5

[Thomas]

Hey Peter,
How relevant is this bug today?
Is there anything I can do to help?

Comment 6

[Nickolay_Ponomarev]

Not relevant with standalone apps, and xulrunner solves this using "xulrunner-stub" executable.