Introduction
Mozilla possède des "chromes" configurables et téléchargeables, ce qui veut dire que la position et même la présence ou l'absence d'un contrôle dans la fenêtre principale n'est pas figé dans l'application, mais chargé à partir de fichier d'interface IU (IU = Interface utilisateur). En effet, la plupart des fenêtres (principale et/ou dialogue) de Mozilla sont décrites en utilisant ce mécanisme. XUL, pour "XML User Interface Language" (Langage d'Interface Utilisateur format XML), est le nom pour le langage dans lequel ces descriptions d'interface sont faites.
Les fichiers de "chrome" sont affichés et gérés par le même moteur que celui qui affiche les pages HTML dans le navigateur. Les description d'IU font très bon ménage avec le HTML 4. Le XUL est une application de XML. En effet, c'est juste du XML avec des éléments spécifiques qui peuvent être implémentés dans du HTML.
Termes
"XPFE" est le terme qu'utilise l'organisation Mozilla pour décrire la Cross Platform Front End du Navigateur de Mozilla, car X et C semblent être semblables si on les tape longtemps et fortement avec un marteau (humour américain...). Le but est de construire des applications cross-platform comme des navigateurs et des clients de courrier électronique à partir d'un kit d'outils créés cour cet usage. L'intention n'est pas d'implanter un framework générique pour application toutes plateformes confondues. Cela a déjà été fait, et au prix d'un grand travail. Nous voulons fournir un sous-ensemble de fonctionnalités inter-plateformes approprié pour construire des applications réseau comme les navigateurs, améliorant les fonctionnalités inter-plateformes déjà inclues dans Gecko, le moteur de rendu HTML de Mozilla.
Le terme de "cross-platform UI" est quelque peu trompeur. Les créateurs d'interface devront être capable de créer des IU qui marcheront sur des multiples plate-formes. Mais des descriptions claires d'UI, qui prennent en considération de nombreuses plateformes, diffèrent sur l'idée de la place correcte des divers contrôles comme les boutons de dialogue qui nécessitent des spécifications par rapport à chaque système. Un spécification XUL est seulement compatible à hauteur d'un "degree". Les designers d'UI ainsi que les ingénieurs doivent maintenir séparément les versions spécifiques à chaque plateforme.
"XPToolkit" est plutôt synonyme de XPFE. Même si l'ancien terme parait plus expressif que l'autre, et pourtant ce n'est pas son remplaçant ; personne ne sais pourquoi il existe les deux.
"XUL" déjà présenté, est une application du XML utilisé pour décrire la présentation de la plupart des fenêtres dans le navigateur Mozilla, incluant aussi la fenêtre principale, la fenêtre du navigateur.
Portée
Cet article n'est pas une tentative d'expliquer les exigences systèmes. Nous n'avons pas de document actuel sur les "exigences" . XPToolkit Architecture est un meilleur moyen pour comprendre de telles choses. Cet article contient une courte introduction à l'architecture Mozilla front-end , en se concentrant sur la tache de construire des UIs. Il est, comme toujours, incomplet.
Les applications Mozilla seront construites de "petits" composants comme des boutons "dialogue" et des dossiers de boite de réception mail, que l'on appelle couramment "widgets." Avec un widget, le dessin et les interactions utilisateur sont complètement sous le contrôle d'un widget indépendant, et faites quand le widget est construit. Le placement relatif des widgets, leurs interactions entre les uns les autres, et en option une partie de leur configuration, sera contrôlé par un UI layout spécifié dans un script dont la structure est définie dans les documents connexes et présents.
Les widgets sont des morceaux of the application largely self-contained, generally corresponding to a rectangle of window real estate. Widgets will generally live grouped in separate, dynamically loaded libraries. A widget may expect to own a piece of a window (a toolbar or toolbar set), or it may be expected to work within or without a window (menubars, depending on the platform). It may not be a part of the application UI at all.
Widgets will have predefined behaviour, set at compilation. Buttons will respond to the mouse; toolbars will act as containers for buttons. The effect a widget will have on its application will be defined as a combination of predefined application behaviour and linkage between the widgets. This linkage can be accomplished by including JavaScript in the XUL, or by application code which walks the content model after it has been built from XUL, and hooks up event listeners. Generally a real application will use some combination of the two.
Applications, for instance, will have preconceived notions of what to do when they receive an "open file" command. An "open" button is simply a button. It will send its command to the application for processing, generally using some simple JavaScript for linkage.
We are at first primarily concerned with the obvious UI components: toolbars, menus and dialogs. Conceptually, the XUL language will allow someone with a text editor, given a package of components which can work together, the ability to put together an application by specifying something like this (for an application on an OS using menubars across the top of its applications' windows):
main window containing
menubar area at top across width of window containing
menubar (and its contents)
toolbar area below menubar across width of window containing
main toolbar (and its contents)
application-specific content area below toolbar area