Currently Mozilla is a browser (Navigator), with additional "applications"
like Communicator/Composer. However I am interested in generalising its
design so that it becomes a generic application platform in which plug-in
applications (lets call them PIAs, not to be confused with the current
browser plug-ins) run.

In this model, according to my initial thoughts:

1)  Until PIAs are run, Mozilla is just an empty application platform (the
"Mozilla shell") with no specific functionality (not even a browser) other
than to provide an outer UI framework and some standard services for PIAs to
run in.

2)  Each of the current "applications" (Navigator/Communicator/Composer/etc)
becomes a distinct PIA.

3) PIAs live in a single subdirectory (like current browser plug-ins),
probably as JAR files which can be remotely installed and updated.

4) On startup Mozilla looks for the installed PIAs and makes them accessible
via the lower panel (from which Communicator/etc are currently accessed).

5) Unlike the current Navigator/Composer/Communicator scheme, PIAs always
run in the Mozilla instance from which they are started - they do not start
off new Mozilla "instances" (though perhaps the user can optionally override
this). The user can switch between them using the same lower panel icons,
which "activates" the selected PIA and "suspends" (hides) the last one.

6) Each PIA has its own chrome within an overall convention and style (eg.
the sidebar only shows tabs for the currently active PIA, the toolbar shows
overall application commands as well as commands for the active PIA, etc).
Maybe each PIA can have its own skin (still closely related to other related
PIAs), for example to provide extra clarity to the user regarding which one
is currently active (eg. Navigator PIA could have a slightly different
chrome background color to the Communicator PIA, etc).

7) When the user switches between PIAs, the Mozilla shell works with the
activating PIA to restore its chrome/skin, and hides the last PIA.

8) PIAs can also activate themselves by request to the Mozilla shell
(possible with user confirmation), eg. if something happens which the user
needs to know about (eg. the Communicator PIA detects new mail).

9) Unlike the current design, the Mozilla shell can give multiple "main
client windows" to the active PIA, and provides a new UI to interface this
to the user (maybe the main client area is now tabbed, a new menu is
provided, an MDI-like scheme is used, or whatever). This does not mean they
have to be used - if a PIA advises that it is a one-window application, then
that's all it gets (so the Navigator PIA could continue to be a one-window
app, if that's what people want - but not me!).

10) The Mozilla shell can be started with a PIA name specified on the
command line, in which case only that one is loaded and (automatically) run.
Thus, the user can still treat Navigator/Communicator/etc as completely
separate applications if they want (eg. started with different desktop
icons).

Example:

To give an example of how this might be used, think ActiveState Komodo.
Although Mozilla-based, it is a multi-windowed scripting IDE, not a single
window browser-based thing. I imagine this resulted in a significant branch
to the original Mozilla code base, and it certainly installs its own Mozilla
base on your hard drive. With the above scheme it wouldn't be a branch to
Mozilla at all - just a new PIA within several others, all existing in the
same Mozilla trunk, and within the same Mozilla installation on your hard
drive.

As far as I can tell, the current Mozilla outer design already nods in the
direction of many of the above (5 and 9 excepted), so this *might* not be
such a major undertaking. However I'm very new to Mozilla so I'd welcome any
feedback from those who know it far better than I, and would welcome
participation from same should this go ahead.

Cheers,
Chris





Reply via email to