Revision 169628 of Estructura XUL

  • Enlace amigable (slug) de la revisión: Tutorial_de_XUL/Estructura_XUL
  • Título de la revisión: Estructura XUL
  • Id de la revisión: 169628
  • Creada:
  • Creador: Aztkgeek
  • ¿Es la revisión actual? No
  • Comentario

Contenido de la revisión

{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}


{{wiki.template('Traducción', [ "inglés", "XUL_Tutorial:XUL Structure", "en" ])}}


Comenzaremos viendo cómo se procesa XUL por parte de Mozilla

Cómo se procesa XUL

En mozilla, XUL se procesa en forma similar al procesamiento de HTML y otros tipos de contenido. Cuando el usuario digita la URL de una página HTML en el campo dirección del navegador, éste busca el sitio web y descarga su contenido. El motor de renderizado de Mozilla toma el contenido en el formato HTML y lo transforma en un árbol de documento. Este árbol se convierte en un conjunto de objetos que pueden mostrarse en la pantalla. CSS, imágenes y otras tecnologías son usadas para controlar la presentación. El procesamiento de XUL es muy similar.

De hecho, en Mozilla, todos los tipos de documento, sin importar si son HTML, XUL o aún SVG son procesados por el mismo código. Esto significa que las mismas propiedades CSS pueden usarse para definir el estilo tanto del HTML como de XUL, y muchas de las características pueden compartirse entre ambos. Sin embargo, hay características que son específicas del HTML como son las formas, y otras que son específicas de XUL como son los overlays (revestimientos). Ya que XUL y HTML se procesan de la misma forma, se pueden cargar desde el sistema de archivos local del usuario, desde una página web, desde una extensión del navegador o desde una aplicación XULRunner.

El contenido de fuentes remotas, sin importar si es HTML, XUL o cualquier otro tipo de documento, está limitado en la clase de operaciones que pueden realizar, por razones de seguridad. Por este motivo, Mozilla proporciona un método para instalar contenido en forma local y registrar los archivos instalados para que formen parte del sistema chrome. Esto permite usar una URL especial llamada la URL chrome. Al acceder a un archivo usando la URL chrome, éstos reciben privilegios para acceder archivos locales, preferencias, marcadores de página y ejecutar otras operaciones privilegiadas. Obviamente, las páginas web no obtienen estos privilegios, a menos que estén firmadas con un certificado digital y el usuario de el permiso para ejecutar estas operaciones.

Este registro en el paquete chrome es la forma cómo las extensiones de Firefox pueden añadir características al navegador. Las extensiones son pequeños paquetes con archivos XUL, Javascript, hojas de estilo e imágenes empaquetados en un sólo archivo. Este archivo puede crearse usando una utilidad ZIP. Cuando el usuario descarga la extensión, ésta es instalada en su máquina. La extensión se ensambla en el navegador usando una característica especial de XUL llamada overlay (revestimiento), la cual permite que se combinen el XUL de la extensión y el XUL del navegador. Para el usuario, puede parecer que la extensión ha modificado al navegador, pero en realidad el código está separado y la extensión puede desinstalarse fácilmente. Por supuesto, no es necesario que los paquetes registrados usen revestimientos. Si no los usan, no pueden accederse desde la interfaz del navegador, pero el usuario aún puede accederlos por medio de la URL chrome, si sabe cuál es.

Las aplicaciones XUL (que no necesiten del navegador) pueden incluir código XUL de la misma forma, pero este código se incluirá como parte de la instalación, en lugar de tener que instalarse en forma separada como una extensión. Sin embargo, este código XUL debe ser registrado en el sistema chrome de tal forma que las aplicaciones puedan mostrar la interfaz.

Vale la pena anotar que el navegador Mozilla realmente es un conjunto de paquetes que contienen archivos XUL, JavaScript y hojas de estilo. Estos paquetes son accedidos usando una URL chrome y tienen privilegios ampliados y trabajan como cualquier otro paquete. Por supuesto, el navegador es más grande y más sofisticado que la mayoría de las extensiones. Firefox, Thunderbird y muchos otros componentes también estan escritos en XUL y se pueden acceder usando la URL chrome. Ud. puede examinar estos paquetes mirando el directorio chrome dónde Firefox o cualquier otra aplicación XUL está instalada.

La URL chrome siempre comienza por 'chrome://'. De la misma forma que la URL 'http://' hace referencia a sitios web remotos accedidos por medio de HTTP y la URL 'file://' hace referencia a archivos locales, la URL chrome hace referencia a los paquetes y extensiones instaladas. En la próxima sección veremos en detalle la sintaxis de la URL chrome. Es importante anotar que si se accede a un contenido a través de una URL chrome, éste gana los privilegios ampliados que se han mencionado anteriormente y que otras clases de URL no tienen. Por ejemplo, una URL HTTP no tiene ningún privilegio especial, y ocurrirá un error si la página web intenta leer un archivo local. Sin embargo, un archivo cargado por medio de una URL chrome podrá leer archivos sin restricciones.

Esta diferenciación es importante. Significa que hay ciertas cosas que el contenido de las páginas web no pueden hacer, tales como leer los marcadores de página del usuario. Esta diferenciación no está basada en la clase de contenido a ser mostrado, sólo en el tipo de URL empleada. Tanto el HTML como el XUL colocados en un sitio web no tienen permisos adicionales, sin embargo si el HTML o el XUL son cargados por medio de una URL chrome tendrán permisos ampliados.

Si Ud. va a usar XUL en un sitio web, debe colocar el archivo XUL en el sitio web tal como lo haría con un archivo HTML, y luego cargar su URL en el navegador. Debe asegurarse que el servidor web esté configurado para enviar los archivos XUL con el tipo de contenido 'application/vnd.mozilla.xul+xml'. Este tipo de contenido es la forma que tiene Mozilla para diferenciar entre HTML y XUL. Mozilla no usa la extensión del archivo, a menos que esté leyendo archivos del disco, o al hacer doble-click en el archivo en su administrador de archivos. Recuerde que el XUL remoto tendrá restricciones significativas sobre lo que podrá hacer.

Mozilla emplea una clase totalmente diferente de objeto documento para el HTML y el XUL, aunque compartan mucha funcionalidad. En Mozilla existen tres clases principales de documentos: HTML, XML y XUL. Naturalmente, el documento HTML se usa para los documentos HTML, el documento XUL se utiliza en los documentos XUL y el documento XML se emplea para otros tipos de documentos XML. Ya que el formato XUL también es XML, el documento XUL es una subclase del documento XML que es más genérico. Existen diferencias sutiles de funcionalidad. Por ejemplo, mientras los controles de una forma en una página HTML se pueden acceder por medio de la propiedad 'document.forms', esta propiedad no está disponible en los documentos XUL ya que XUL no tiene formas en el sentido en que HTML las tiene. De otra parte, características específicas de XUL como los revestimientos y las plantillas sólo están disponibles en los documentos XUL.

Esta diferenciación entre documentos es importante. Es posible usar muchas características de XUL en documentos HTML o XML ya que no son específicas al tipo de documento, sin embargo, otras características requieren el tipo adecuado de documento. Por ejemplo, se pueden usar los tipos de disposición de XUL en otros documentos ya que no dependen del tipo de documento XUL para funcionar.

Para resumir los puntos expuestos anteriormente:

  • Mozilla muestra tanto el HTML como el XUL usando la misma máquina de renderizado y emplea CSS para especificar su presentación.
  • XUL puede cargarse desde un sitio remoto, desde el sistema de archivos local, o ser instalado con un paquete y ser accedido usando una URL chrome. Esto es lo que hacen las extensiones del navegador.
  • Las URL chrome pueden usarse para acceder paquetes instalados y abrirlos con privilegios ampliados.
  • HTML, XML y XUL tienen diferentes tipos de documentos. Algunas características pueden usarse en cualquier clase de documento, mientras que otras son específicas para una clase de documento.

En las próximas secciones describiremos la estructura básica de un paquete chrome que será instalado dentro de Mozilla. Sin embargo, si desea comenzar a construir una aplicación simple, puede saltar a Creando una ventana y dejarlas para después.

Package Organization

Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It will also have one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component will have descriptions of the mail messages list window, the composition window and the address book dialogs.

The packages that are provided with Mozilla are located within the chrome directory, which you will find in the directory where you installed Mozilla. The chrome directory is where you will find all the files that describe the user interface used by the Mozilla browser, mail client and other applications. You will typically put all of the XUL files for an application in this directory, except for extensions which will be installed in the extensions directory for a particular user. Just copying a XUL file into the 'chrome' directory doesn't give the file any extra permissions nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in the next section.

The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.

To further the confusion, there are two other places where the word chrome might appear. The first is the '-chrome' command line argument, and the chrome modifier to the 'window.open' function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.

The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's chrome directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.

There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin and the locale, described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need, and allow other parts, such as the text for different languages, to be downloaded separately.

The three types of chrome packages are:

  • Content - Windows and scripts
    The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a xul extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called editor.xul. Scripts are placed in separate files alongside the XUL files.
  • Skin - Style sheets, images and other theme specific files
    Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.
  • Locale - Locale specific files
    All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.

Content Packages

The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in browser.jar, you will find that it contains a directory structure much like the following:

content
   browser
      browser.xul
      browser.js
      -- other mail XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.

This is easily recognizable as a content package, as the top-level directory is called 'content'. For skins, this directory will usually be called 'skin' and for locales, it will usually be called 'locale'. This naming scheme isn't necessary but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.

The content/browser directory contains a number of files with xul and js extensions. The XUL files are the ones with the xul extension. The files with js extensions are JavaScript files which contain scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.

In the listing above, two files have been shown. There are others of course, but for simplicity they aren't shown. The file browser.xul is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a xul extension. In this case, the package name is 'browser', so we expect to find 'browser.xul'. Some of the other XUL files describe separate windows. For example, the file pageInfo.xul describes the page info dialog.

Many packages will include a contents.rdf, which describes the package, its author and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the .manifest extension in the chrome directory. For instance, browser.manifest describes the browser package.

Several subdirectories, such as bookmarks and preferences, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.

Skins or Themes

The underlying code of Mozilla calls them skins, although the user interface calls them themes, but they both refer to the same thing. The classic.jar file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining classic.jar:

skin
   classic
      browser
         -- browser skin files go here --
      global
         contents.rdf
         -- global skin files go here --.
.
.

Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.

A skin is made up of CSS files and a number of images used to define the look of an interface. The file browser.css is used by browser.xul and contains styles which define the appearance of various parts of the browser interface. Again, note how the file browser.css has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.

Locales

The file en-US.jar describes the language information for each component, in this case for US English. Like the skins, each language will contain files that specify text used by the package but for a specific language. The locale structure is similar to the others, so it won't be listed it here.

The localized text is stored in two types of files, DTD files, and properties files. The DTD files have a dtd extension and contain entity declarations, one for each text string that is used in a window. For example, the file browser.dtd contains entity declarations for each menu command. In addition, keyboard shortcuts for each command are also defined, because they may be different for each language. DTD files are used by XUL files so, in general, you will have one per XUL file. The locale part also contains properties files, which are similar, but are used by script files. The file browser.properties contains a few such localized strings.

This structure allows you to translate Mozilla or a component into a different language by just adding a new locale for that language. You don't have to change the XUL part. In addition, another person could supply a separate package that applies a skin or locale to your content part, thus providing support for a new theme or language without having to change the original package.

Other Packages

There is a one special package called toolkit (or global). We saw the global directory earlier for skins. The file toolkit.jar contains the corresponding content part for it. It contains some global dialogs and definitions. It also defines the default appearance and functionality of the various common XUL widgets such as textboxes and buttons. The files located in the global part of a skin package contain the default look for all of the XUL interface elements. The toolkit package is used by all XUL applications.

Adding a Package

Mozilla places the packages that are included with the installation in the chrome directory. However, they do not need to be placed there. If you have another package installed, it can be placed anywhere on the disk, as long as a manifest file points to it. It is common to place packages into the chrome directory simply because it is convenient, however they will work just as well from another directory or somewhere on your local network. You cannot store them on a remote site, unless the remote site is mounted through the local file system.

There are two chrome directories used for XUL applications, one is installed in the same place where the application is installed, while the other is part of user's profile. The former allows packages that are shared by all users while the latter allows packages to be created only for a specific user or users. Extensions, while installed in a separate extensions directory, are also usually user specific. Any manifest files located in either chrome directory will be examined to see which packages are installed.

In the next section, we'll look at how to refer to chrome packages using the chrome URL.

{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}} Interwiki Language Links

{{ wiki.languages( { "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Pomocnik_XUL/Struktura_XUL" } ) }}

Fuente de la revisión

<p>
{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}
</p><p><br>
</p><p>{{wiki.template('Traducción', [ "inglés", "XUL_Tutorial:XUL Structure", "en" ])}}
</p><p><br>
Comenzaremos viendo cómo se procesa XUL por parte de Mozilla
</p>
<h3 name="C.C3.B3mo_se_procesa_XUL"> Cómo se procesa XUL </h3>
<p>En mozilla, XUL se procesa en forma similar al procesamiento de HTML y otros tipos de contenido. Cuando el usuario digita la URL de una página HTML en el campo dirección del navegador, éste busca el sitio web y descarga su contenido. El motor de renderizado de Mozilla toma el contenido en el formato HTML y lo transforma en un árbol de documento. Este árbol se convierte en un conjunto de objetos que pueden mostrarse en la pantalla. CSS, imágenes y otras tecnologías son usadas para controlar la presentación. El procesamiento de XUL es muy similar.
</p><p>De hecho, en Mozilla, todos los tipos de documento, sin importar si son HTML, XUL o aún SVG son procesados por el mismo código. Esto significa que las mismas propiedades CSS pueden usarse para definir el estilo tanto del HTML como de XUL, y muchas de las características pueden compartirse entre ambos. Sin embargo, hay características que son específicas del HTML como son las formas, y otras que son específicas de XUL como son los overlays (revestimientos). Ya que XUL y HTML se procesan de la misma forma, se pueden cargar desde el sistema de archivos local del usuario, desde una página web, desde una extensión del navegador o desde una aplicación XULRunner.
</p><p>El contenido de fuentes remotas, sin importar si es HTML, XUL o cualquier otro tipo de documento, está limitado en la clase de operaciones que pueden realizar, por razones de seguridad. Por este motivo, Mozilla proporciona un método para instalar contenido en forma local y registrar los archivos instalados para que formen parte del sistema chrome. Esto permite usar una URL especial llamada la URL chrome. Al acceder a un archivo usando la URL chrome, éstos reciben privilegios para acceder archivos locales, preferencias, marcadores de página y ejecutar otras operaciones privilegiadas. Obviamente, las páginas web no obtienen estos privilegios, a menos que estén firmadas con un certificado digital y el usuario de el permiso para ejecutar estas operaciones.
</p><p>Este registro en el paquete chrome es la forma cómo las extensiones de Firefox pueden añadir características al navegador. Las extensiones son pequeños paquetes con archivos XUL, Javascript, hojas de estilo e imágenes empaquetados en un sólo archivo. Este archivo puede crearse usando una utilidad ZIP. Cuando el usuario descarga la extensión, ésta es instalada en su máquina. La extensión se ensambla en el navegador usando una característica especial de XUL llamada overlay (revestimiento), la cual permite que se combinen el XUL de la extensión y el XUL del navegador. Para el usuario, puede parecer que la extensión ha modificado al navegador, pero en realidad el código está separado y la extensión puede desinstalarse fácilmente. Por supuesto, no es necesario que los paquetes registrados usen revestimientos. Si no los usan, no pueden accederse desde la interfaz del navegador, pero el usuario aún puede accederlos por medio de la URL chrome, si sabe cuál es.
</p><p>Las aplicaciones XUL (que no necesiten del navegador) pueden incluir código XUL de la misma forma, pero este código se incluirá como parte de la instalación, en lugar de tener que instalarse en forma separada como una extensión. Sin embargo, este código XUL debe ser registrado en el sistema chrome de tal forma que las aplicaciones puedan mostrar la interfaz.
</p><p>Vale la pena anotar que el navegador Mozilla realmente es un conjunto de paquetes que contienen archivos XUL, JavaScript y hojas de estilo. Estos paquetes son accedidos usando una URL chrome y tienen privilegios ampliados y trabajan como cualquier otro paquete. Por supuesto, el navegador es más grande y más sofisticado que la mayoría de las extensiones. Firefox, Thunderbird y muchos otros componentes también estan escritos en XUL y se pueden acceder usando la URL chrome. Ud. puede examinar estos paquetes mirando el directorio chrome dónde Firefox o cualquier otra aplicación XUL está instalada.
</p><p>La URL chrome siempre comienza por 'chrome://'. De la misma forma que la URL 'http://' hace referencia a sitios web remotos accedidos por medio de HTTP y la URL 'file://' hace referencia a archivos locales, la URL chrome hace referencia a los paquetes y extensiones instaladas. En la próxima sección veremos en detalle la sintaxis de la URL chrome. Es importante anotar que si se accede a un contenido a través de una URL chrome, éste gana los privilegios ampliados que se han mencionado anteriormente y que otras clases de URL no tienen. Por ejemplo, una URL HTTP no tiene ningún privilegio especial, y ocurrirá un error si la página web intenta leer un archivo local. Sin embargo, un archivo cargado por medio de una URL chrome podrá leer archivos sin restricciones.
</p><p>Esta diferenciación es importante. Significa que hay ciertas cosas que el contenido de las páginas web no pueden hacer, tales como leer los marcadores de página del usuario. Esta diferenciación no está basada en la clase de contenido a ser mostrado, sólo en el tipo de URL empleada. Tanto el HTML como el XUL colocados en un sitio web no tienen permisos adicionales, sin embargo si el HTML o el XUL son cargados por medio de una URL chrome tendrán permisos ampliados.
</p><p>Si Ud. va a usar XUL en un sitio web, debe colocar el archivo XUL en el sitio web tal como lo haría con un archivo HTML, y luego cargar su URL en el navegador. Debe asegurarse que el servidor web esté configurado para enviar los archivos XUL con el tipo de contenido 'application/vnd.mozilla.xul+xml'. Este tipo de contenido es la forma que tiene Mozilla para diferenciar entre HTML y XUL. Mozilla no usa la extensión del archivo, a menos que esté leyendo archivos del disco, o al hacer doble-click en el archivo en su administrador de archivos. Recuerde que el XUL remoto tendrá restricciones significativas sobre lo que podrá hacer.
</p><p>Mozilla emplea una clase totalmente diferente de objeto documento para el HTML y el XUL, aunque compartan mucha funcionalidad. En Mozilla existen tres clases principales de documentos: HTML, XML y XUL. Naturalmente, el documento HTML se usa para los documentos HTML, el documento XUL se utiliza en los documentos XUL y el documento XML se emplea para otros tipos de documentos XML. Ya que el formato XUL también es XML, el documento XUL es una subclase del documento XML que es más genérico. Existen diferencias sutiles de funcionalidad. Por ejemplo, mientras los controles de una forma en una página HTML se pueden acceder por medio de la propiedad 'document.forms', esta propiedad no está disponible en los documentos XUL ya que XUL no tiene formas en el sentido en que HTML las tiene. De otra parte, características específicas de XUL como los revestimientos y las plantillas sólo están disponibles en los documentos XUL.
</p><p>Esta diferenciación entre documentos es importante. Es posible usar muchas características de XUL en documentos HTML o XML ya que no son específicas al tipo de documento, sin embargo, otras características requieren el tipo adecuado de documento. Por ejemplo, se pueden usar los tipos de disposición de XUL en otros documentos ya que no dependen del tipo de documento XUL para funcionar.
</p><p>Para resumir los puntos expuestos anteriormente:
</p>
<ul><li> Mozilla muestra tanto el HTML como el XUL usando la misma máquina de renderizado y emplea CSS para especificar su presentación.
</li><li> XUL puede cargarse desde un sitio remoto, desde el sistema de archivos local, o ser instalado con un paquete y ser accedido usando una URL chrome. Esto es lo que hacen las extensiones del navegador.
</li><li> Las URL chrome pueden usarse para acceder paquetes instalados y abrirlos con privilegios ampliados.
</li><li> HTML, XML y XUL tienen diferentes tipos de documentos. Algunas características pueden usarse en cualquier clase de documento, mientras que otras son específicas para una clase de documento.
</li></ul>
<p>En las próximas secciones describiremos la estructura básica de un paquete chrome que será instalado dentro de Mozilla. Sin embargo, si desea comenzar a construir una aplicación simple, puede saltar a <a href="es/Tutorial_de_XUL/Creando_una_ventana">Creando una ventana</a> y dejarlas para después.
</p>
<h3 name="Package_Organization"> Package Organization </h3>
<p>Mozilla is organized in such a way that you can have as many components as you want pre-installed. Each extension is also a component with a separate chrome URL. It will also have one component for each installed theme and locale. Each of these components, or packages, is made up of a set of files that describe the user interface for it. For example, the messenger component will have descriptions of the mail messages list window, the composition window and the address book dialogs.
</p><p>The packages that are provided with Mozilla are located within the chrome directory, which you will find in the directory where you installed Mozilla. The chrome directory is where you will find all the files that describe the user interface used by the Mozilla browser, mail client and other applications. You will typically put all of the XUL files for an application in this directory, except for extensions which will be installed in the extensions directory for a particular user. Just copying a XUL file into the 'chrome' directory doesn't give the file any extra permissions nor can it be accessed via a chrome URL. To gain the extra privileges, you will need to create a manifest file and put that in the chrome directory. This file is easy to create, as it is typically only a couple of lines long. It is used to map a chrome URL to a file or directory path on the disk where the XUL files are located. Details of how to create this file will be discussed in the next section.
</p><p>The only way to create content that can be accessed through a chrome URL is by creating a package as described in the next few sections. This directory is called 'chrome' likely because it seemed like a convenient name to use for the directory where the chrome packages that are included with Mozilla are kept.
</p><p>To further the confusion, there are two other places where the word chrome might appear. The first is the '-chrome' command line argument, and the chrome modifier to the 'window.open' function. Neither of these features grant extra privileges; instead they are used to open a new top-level window without the browser UI such as the menu and toolbar. You will commonly use this feature in more complex XUL applications since you wouldn't want the browser UI to exist around your dialog boxes.
</p><p>The files for a package are usually combined into a single JAR file. A JAR file may created and examined using a ZIP utility. For instance, you can open the JAR files in Mozilla's chrome directory to see the basic structure of a package. Although it's normal to combine the files into a JAR file, packages may also be accessed in expanded form into a directory. Although you don't normally distribute a package this way, it is handy during development since you can edit the file directly and then reload the XUL file without having to repackage or reinstall the files.
</p><p>There are usually three different parts to a chrome package, although they are all optional. Each part is stored in a different directory. These three sets are the content, the skin and the locale, described below. A particular package might provide one or more skins and locales, but a user can replace them with their own. In addition, the package might include several different applications each accessible via different chrome URLs. The packaging system is flexible enough so that you can include whatever parts you need, and allow other parts, such as the text for different languages, to be downloaded separately.
</p><p>The three types of chrome packages are:
</p>
<ul>
<li><b>Content</b> - Windows and scripts<br>
The declarations of the windows and the user interface elements contained within them. These are stored in XUL files, which have a xul extension. A content package can have multiple XUL files, but the main window should have a filename that is the same as the package name. For example, the editor package will have a file within it called editor.xul. Scripts are placed in separate files alongside the XUL files.
</li>
<li><b>Skin</b> - Style sheets, images and other theme specific files<br>
Style sheets describe details of the appearance of a window. They are stored separately from XUL files to facilitate modifying the skin (theme) of an application. Any images used are stored here also.
</li>
<li><b>Locale</b> - Locale specific files<br>
All the text that is displayed within a window is stored separately. This way, a user can have a set for their own language.
</li>
</ul>
<h3 name="Content_Packages"> Content Packages </h3>
<p>The name of the JAR file might describe what it contains, but you can't be sure unless you view its contents. Let's use the browser package included with Firefox as an example. If you extract the files in browser.jar, you will find that it contains a directory structure much like the following:
</p>
<pre>content
   browser
      browser.xul
      browser.js
      -- other mail XUL and JS files goes here --
      bookmarks
         -- bookmarks files go here --
      preferences
         -- preferences files go here --
.
.
.
</pre>
<p>This is easily recognizable as a content package, as the top-level directory is called 'content'. For skins, this directory will usually be called 'skin' and for locales, it will usually be called 'locale'. This naming scheme isn't necessary but this is a common convention to make the parts of a package clearer. Some packages may include a content section, a skin and a locale. In this case, you will find a subdirectory for each type. For example, Chatzilla is distributed in this way.
</p><p>The content/browser directory contains a number of files with xul and js extensions. The XUL files are the ones with the xul extension. The files with js extensions are JavaScript files which contain scripts that handle the functionality of a window. Many XUL files have a script file associated with them, and some may have more than one.
</p><p>In the listing above, two files have been shown. There are others of course, but for simplicity they aren't shown. The file browser.xul is the XUL file that describes the main browser window. The main window for a content package should have the same name as the package with a xul extension. In this case, the package name is 'browser', so we expect to find 'browser.xul'. Some of the other XUL files describe separate windows. For example, the file pageInfo.xul describes the page info dialog.
</p><p>Many packages will include a contents.rdf, which describes the package, its author and the overlays it uses. However, this file is obsolete and has been replaced with a simpler mechanism. This newer method is the manifest file mentioned earlier, and you will find these as files with the .manifest extension in the chrome directory. For instance, browser.manifest describes the browser package.
</p><p>Several subdirectories, such as bookmarks and preferences, describe additional sections of the browser component. They are placed in different directories only to keep the files more organized.
</p>
<h3 name="Skins_or_Themes"> Skins or Themes </h3>
<p>The underlying code of Mozilla calls them skins, although the user interface calls them themes, but they both refer to the same thing. The classic.jar file describes the default theme provided with Firefox. The structure is similar to the content packages. For example, examining classic.jar:
</p>
<pre>skin
   classic
      browser
         -- browser skin files go here --
      global
         contents.rdf
         -- global skin files go here --.
.
.
</pre>
<p>Again, this directory structure isn't necessary and is used for convenience. You can actually put all the files in one directory at the top level and not use subdirectories. However, for larger applications, subdirectories are used to separate the different components. In the example above, a directory exists for theme related files for the browser and another for global theme related files. The global directory contains skin files that are general to all packages. These files will apply to all components and will be included with your own standalone applications. The global part defines the appearance of all of the common XUL widgets, whereas the other directories have files that are specific to those applications. Firefox includes both the global and browser theme files in one archive, but they can be included separately.
</p><p>A skin is made up of CSS files and a number of images used to define the look of an interface. The file browser.css is used by browser.xul and contains styles which define the appearance of various parts of the browser interface. Again, note how the file browser.css has the same name as the package. By changing the CSS files, you can adjust the appearance of a window without changing its function. This is how you can create a new theme. The XUL part remains the same but the skin part changes independently.
</p>
<h3 name="Locales"> Locales </h3>
<p>The file en-US.jar describes the language information for each component, in this case for US English. Like the skins, each language will contain files that specify text used by the package but for a specific language. The locale structure is similar to the others, so it won't be listed it here.
</p><p>The localized text is stored in two types of files, DTD files, and properties files. The DTD files have a dtd extension and contain entity declarations, one for each text string that is used in a window. For example, the file browser.dtd contains entity declarations for each menu command. In addition, keyboard shortcuts for each command are also defined, because they may be different for each language. DTD files are used by XUL files so, in general, you will have one per XUL file. The locale part also contains properties files, which are similar, but are used by script files. The file browser.properties contains a few such localized strings.
</p><p>This structure allows you to translate Mozilla or a component into a different language by just adding a new locale for that language. You don't have to change the XUL part. In addition, another person could supply a separate package that applies a skin or locale to your content part, thus providing support for a new theme or language without having to change the original package.
</p>
<h3 name="Other_Packages"> Other Packages </h3>
<p>There is a one special package called toolkit (or global). We saw the global directory earlier for skins. The file toolkit.jar contains the corresponding content part for it. It contains some global dialogs and definitions. It also defines the default appearance and functionality of the various common XUL widgets such as textboxes and buttons. The files located in the global part of a skin package contain the default look for all of the XUL interface elements. The toolkit package is used by all XUL applications.
</p>
<h3 name="Adding_a_Package"> Adding a Package </h3>
<p>Mozilla places the packages that are included with the installation in the chrome directory. However, they do not need to be placed there. If you have another package installed, it can be placed anywhere on the disk, as long as a manifest file points to it. It is common to place packages into the chrome directory simply because it is convenient, however they will work just as well from another directory or somewhere on your local network. You cannot store them on a remote site, unless the remote site is mounted through the local file system.
</p><p>There are two chrome directories used for XUL applications, one is installed in the same place where the application is installed, while the other is part of user's profile. The former allows packages that are shared by all users while the latter allows packages to be created only for a specific user or users. Extensions, while installed in a separate extensions directory, are also usually user specific. Any manifest files located in either chrome directory will be examined to see which packages are installed.
</p><p>In the next section, we'll look at how to refer to chrome packages using the chrome URL.
</p><p>{{template.AnteriorSiguiente("Tutorial de XUL:Introducción", "Tutorial de XUL:La URL chrome")}}
<span class="comment">Interwiki Language Links</span>
</p>{{ wiki.languages( { "ja": "ja/XUL_Tutorial/XUL_Structure", "pl": "pl/Pomocnik_XUL/Struktura_XUL" } ) }}
Revertir a esta revisión