Visit Mozilla.org

Introduction à XUL

Un article de MDC.

Cette page est en cours de traduction, son contenu peut donc être incomplet ou contenir des parties en anglais. N'hésitez pas à participer à sa traduction à partir de Introduction to XUL

[modifier] Introduction

Mozilla possède des "chomes" 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 mechanisme. XUL, pour "XML User Interface Language" (Langage d'Interface Utilisateur format XML), est notre 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.

[modifier] Termes

"XPFE" is the term Mozilla-the-organization is using to describe Mozilla-the-browser's Cross Platform Front End, because X and C look similar if you beat them long and hard with a hammer. The intention is to build cross-platform applications like browsers and mail clients from a set of tools designed for that purpose. The intention is not to implement a generic cross-platform application framework. That's been done, and is a great deal of work. We intend to provide a subset of cross-platform functionality suitable for building network applications like browsers, leveraging the cross-platform functionality already built into Gecko, Mozilla's HTML layout engine.

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.

[modifier] Scope

This paper makes no attempt to explain requirements. We don't have a current "requirements" document. XPToolkit Architecture is a better place to gain an understanding of such things. This paper contains a short introduction to Mozilla front-end architecture, concentrating on the task of building UIs. It is, as always, incomplete.

Mozilla applications will be built of "small" components like dialog buttons and mail inbox folders, which we collectively term "widgets." Within a widget, drawing and user interactions are completely under control of the individual widget, and set when the widget was built. Relative placement of widgets, their interactions with each other, and optionally some of their configuration, will be controlled by a UI layout specified in a script whose structure is defined in this and related documents.

Widgets are pieces 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