mozilla

Versionen vergleichen

XUL Struktur

Versionsänderungen

Version 111888:

Version 111888 von Jochen Kiene am

Version 111889:

Version 111889 von Jochen Kiene am

Titel:
XUL Struktur
XUL Struktur
Adressname:
XUL_Tutorial/XUL_Struktur
XUL_Tutorial/XUL_Struktur
Schlagwörter:
XUL, "XUL Tutorial"
XUL, "XUL Tutorial"
Inhalt:

Version 111888
Version 111889
n8      {{template.PreviousNext("Tutorial XUL:Einfuehrung", "XUL Tun8      {{template.PreviousNext("XUL Tutorial:Einfuehrung", "XUL Tu
>torial:Die Chrome-URL")}}>torial:Die Chrome-URL")}}
t21      <br>t21      In der Tat werden alle Dokumenttypen, egal ob HTML, XUL ode
 >r sogar <a href="de/SVG">SVG</a>, durch den selben zugrundeliegen
 >den Code behandelt. Das bedeutet, dass die selben CSS-Eigenschaft
 >en benutzt werden können, um sowohl HTML und XUL zu manipulieren,
 > und so können viele Funktionen von beiden genutzt werden. Doch g
 >ibt es einige Funktionen, welche nur von HTML verwendet werden kö
 >nnen, wie z.B. Forms, und andere, welche nur von XUL verwendet we
 >rden können, so wie <a href="de/XUL_Tutorial/Overlays">Overlays</
 >a>. Da ja XUL und HTML auf die selbe Art und Weise behandelt werd
 >en, kann man beide sowohl vom lokalen Dateisystem, von einer Webs
 >eite oder von einer Erweiterung oder einer selbständigen <a href=
 >"de/XULRunner">XULRunner</a>-Anwendung laden.
22    </p>
23    <p>
22      <span class="comment">In factin Mozilla, all document typ24      <span class="comment">Content from remote sources &lt;code&
>es, whether they are HTML or XUL, or even {{mediawiki.internal('S>gt;&lt;nowiki&gt;eg http://localhost/~username/&lt;/nowiki&gt;&lt
>VG', "de")}}, are all handled by the same underlying code. This m>;/code&gt;regardless or whether they are HTML or XUL or another
>eans that the same CSS properties may be used to style both HTML > document typeare limited in the type of operations they can pe
>and XUL, and many of the features can be shared between both. How>rform, for security reasons. For this reason, Mozilla provides a 
>ever, there are some features that are specific to HTML such as f>method of installing content locally and registering the installe
>orms, and others which are specific to XUL such as {{mediawiki.in>d files as part of its '''{{mediawiki.internal('chrome', "de")}}'
>ternal('XUL_Tutorial:Overlays|overlays', "de")}}. Since XUL and H>'' system. This allows a special URL form to be used called a &lt
>TML are handled in the same way, you can load both from either yo>;code&gt;chrome://&lt;/code&gt; URL. By accessing a file using a 
>ur local file system, from a web page, or from an extension or st>chrome URL, the files receive elevated privileges to access local
>andalone {{mediawiki.internal('XULRunner', "de")}} application. C> files, access preferences and bookmarks and perform other privil
>ontent from remote sources &lt;code&gt;&lt;nowiki&gt;eg http://lo>eged operations. Obviously, web pages do not get these privileges
>calhost/~username/&lt;/nowiki&gt;&lt;/code&gt;, regardless or whe>, unless they are signed with a digital certificate and the user 
>ther they are HTML or XUL or another document type, are limited i>has granted permission to perform these operations. This '''chrom
>n the type of operations they can perform, for security reasons. >e''' package registration is the way Firefox extensions are able 
>For this reason, Mozilla provides a method of installing content >to add features to the browser. The extensions are small packages
>locally and registering the installed files as part of its '''{{m> of XUL files, JavaScript, style sheets and images packed togethe
>ediawiki.internal('chrome', "de")}}''' system. This allows a spec>r into a single file. This file can be created by using a ZIP uti
>ial URL form to be used called a &lt;code&gt;chrome://&lt;/code&g>lity. When the user downloads it, it will be installed onto the u
>t; URL. By accessing a file using a chrome URL, the files receive>ser's machine. It will hook into the browser using a XUL specific
> elevated privileges to access local files, access preferences an> feature called an {{mediawiki.internal('Overlay|overlay', "de")}
>d bookmarks and perform other privileged operations. Obviously, w>} which allows the XUL from the extension and the XUL in the brow
>eb pages do not get these privileges, unless they are signed with>ser to combine together. To the user, it may seem like the extens
> a digital certificate and the user has granted permission to per>ion has ''modified'' the browser, but in reality, the code is all
>form these operations. This '''chrome''' package registration is > separate, and the extension may be uninstalled easily. Registere
>the way Firefox extensions are able to add features to the browse>d packages are not required to use overlays, of course. If they d
>r. The extensions are small packages of XUL files, JavaScript, st>on't, you won't be able to access them via the main browser inter
>yle sheets and images packed together into a single file. This fi>face, but you can still access them via the chrome URL, if you kn
>le can be created by using a ZIP utility. When the user downloads>ow what it is. Standalone XUL applications may include XUL code i
> it, it will be installed onto the user's machine. It will hook i>n a similar way, but, of course, the XUL for the application will
>nto the browser using a XUL specific feature called an {{mediawik> be included as part of the installation, instead of having to be
>i.internal('Overlay|overlay', "de")}} which allows the XUL from t> installed separately as an extension. However, this XUL code wil
>he extension and the XUL in the browser to combine together. To t>l be registered in the chrome system such that the application ca
>he user, it may seem like the extension has ''modified'' the brow>n display the UI. It is worth noting that the Mozilla browser its
>ser, but in reality, the code is all separate, and the extension >elf is actually just a set of packages containing XUL files, Java
>may be uninstalled easily. Registered packages are not required t>Script and style sheets. These files are accessed via a chrome UR
>o use overlays, of course. If they don't, you won't be able to ac>L and have enhanced privileges and work just like any other packa
>cess them via the main browser interface, but you can still acces>ge. Of course, the browser is much larger and more sophisticated 
>s them via the chrome URL, if you know what it is. Standalone XUL>than most extensions. Firefox and Thunderbird as well as number o
> applications may include XUL code in a similar way, but, of cour>f other components are all written in XUL and are all accessible 
>se, the XUL for the application will be included as part of the i>via chrome URLs. You can examine these packages by looking in the
>nstallation, instead of having to be installed separately as an e> chrome directory where Firefox or another XUL application is ins
>xtension. However, this XUL code will be registered in the chrome>talled. The chrome URL always begins with 'chrome://'. Much like 
> system such that the application can display the UI. It is worth>how the &lt;nowiki&gt;'http://'&lt;/nowiki&gt; URL always refers 
> noting that the Mozilla browser itself is actually just a set of>to remote web sites accessed using HTTP and the 'file://' URL alw
> packages containing XUL files, JavaScript and style sheets. Thes>ays refers to local files, the 'chrome://' URL always refers to i
>e files are accessed via a chrome URL and have enhanced privilege>nstalled packages and extensions. We'll look more at the syntax o
>s and work just like any other package. Of course, the browser is>f a chrome URL in the next section. It is important to note that 
> much larger and more sophisticated than most extensions. Firefox>when accessing content through a chrome URL, it gains the enhance
> and Thunderbird as well as number of other components are all wr>d privileges described above that other kinds of URLs do not. For
>itten in XUL and are all accessible via chrome URLs. You can exam> instance, an HTTP URL does not have any special privileges, and 
>ine these packages by looking in the chrome directory where Firef>an error will occur if a web page tries, for example, to read a l
>ox or another XUL application is installed. The chrome URL always>ocal file. However, a file loaded via a chrome URL will be able t
> begins with 'chrome://'. Much like how the &lt;nowiki&gt;'http:/>o read files without restriction. This distinction is important. 
>/'&lt;/nowiki&gt; URL always refers to remote web sites accessed >This means that there are certain things that content of web page
>using HTTP and the 'file://' URL always refers to local files, th>s cannot do, such as read the user's bookmarks. This distinction 
>e 'chrome://' URL always refers to installed packages and extensi>is not based on the kind of content being displayed; only on the 
>ons. We'll look more at the syntax of a chrome URL in the next se>type of URL used. Both HTML and XUL placed on a web site have no 
>ction. It is important to note that when accessing content throug>extra permissions; however both HTML and XUL loaded through a chr
>h a chrome URL, it gains the enhanced privileges described above >ome URL have enhanced permissions. If you are going to use XUL on
>that other kinds of URLs do not. For instance, an HTTP URL does n> a web site, you can just put the XUL file on the web site as you
>ot have any special privileges, and an error will occur if a web > would an HTML file, and then load its URL in a browser &lt;small
>page tries, for example, to read a local file. However, a file lo>&gt;&lt;nowiki&gt;http://localhost/xul.php&lt;/nowiki&gt;&lt;/sma
>aded via a chrome URL will be able to read files without restrict>ll&gt;. Ensure that your web server is configured to send XUL fil
>ion. This distinction is important. This means that there are cer>es with the content type of '''&lt;code&gt;application/vnd.mozill
>tain things that content of web pages cannot do, such as read the>a.xul+xml&lt;/code&gt;''' (eg with PHP &lt;code&gt;header('conten
> user's bookmarks. This distinction is not based on the kind of c>t-type: application/vnd.mozilla.xul+xml');&lt;/code&gt;). This co
>ontent being displayed; only on the type of URL used. Both HTML a>ntent type is how Mozilla knows the difference between HTML and X
>nd XUL placed on a web site have no extra permissions; however bo>UL. Mozilla does not use the file extension, unless reading files
>th HTML and XUL loaded through a chrome URL have enhanced permiss> from the file system, but you should use the &lt;tt&gt;.xul&lt;/
>ions. If you are going to use XUL on a web site, you can just put>tt&gt; extension for all XUL files. You can load XUL files from y
> the XUL file on the web site as you would an HTML file, and then>our own machine by opening them in the browser, or by double-clic
> load its URL in a browser &lt;small&gt;&lt;nowiki&gt;http://loca>king the file in your file manager. &lt;div class="tip"&gt;Rememb
>lhost/xul.php&lt;/nowiki&gt;&lt;/small&gt;. Ensure that your web >er that remote XUL will have significant restrictions on what it 
>server is configured to send XUL files with the content type of '>can do.&lt;/div&gt; ===Document types: HTML XML XUL CSS=== Mozill
>''&lt;code&gt;application/vnd.mozilla.xul+xml&lt;/code&gt;''' (eg>a uses a distinctly different kind of document object ({{mediawik
> with PHP &lt;code&gt;header('content-type: application/vnd.mozil>i.internal('DOM', "de")}}) for HTML and XUL, although they share 
>la.xul+xml');&lt;/code&gt;). This content type is how Mozilla kno>most of their functionality. There are three main types of docume
>ws the difference between HTML and XUL. Mozilla does not use the >nt in Mozilla: HTML, XML, and XUL. Naturally, the HTML document i
>file extension, unless reading files from the file system, but yo>s used for HTML documents, the XUL document is used for XUL docum
>u should use the &lt;tt&gt;.xul&lt;/tt&gt; extension for all XUL >ents, and the XML document is used for other types of XML documen
>files. You can load XUL files from your own machine by opening th>ts. Since XUL is also XML, the XUL document is a subtype of the m
>em in the browser, or by double-clicking the file in your file ma>ore generic XML document. There are subtle differences in functio
>nager. &lt;div class="tip"&gt;Remember that remote XUL will have >nality. For example, while the form controls on an HTML page are 
>significant restrictions on what it can do.&lt;/div&gt; ===Docume>accessible via the &lt;code&gt;document.forms&lt;/code&gt; proper
>nt types: HTML XML XUL CSS=== Mozilla uses a distinctly different>ty, this property isn't available for XUL documents, since XUL do
> kind of document object ({{mediawiki.internal('DOM', "de")}}) fo>esn't have forms in the HTML sense. Likewise, XUL specific featur
>r HTML and XUL, although they share most of their functionality. >es such as overlays and templates are only available in XUL docum
>There are three main types of document in Mozilla: HTML, XML, and>ents. This distinction between documents is important. It is poss
> XUL. Naturally, the HTML document is used for HTML documents, th>ible to use many XUL features in HTML or XML documents since they
>e XUL document is used for XUL documents, and the XML document is> aren't document type specific; however other features require th
> used for other types of XML documents. Since XUL is also XML, th>e right kind of document. For instance, you can use the XUL layou
>e XUL document is a subtype of the more generic XML document. The>t types in other documents since they don't rely on the XUL docum
>re are subtle differences in functionality. For example, while th>ent type to function. To summarize the points made above: * Mozil
>e form controls on an HTML page are accessible via the &lt;code&g>la renders both {{mediawiki.internal('HTML', "de")}} and {{mediaw
>t;document.forms&lt;/code&gt; property, this property isn't avail>iki.internal('XUL', "de")}} using the same underlying engine and 
>able for XUL documents, since XUL doesn't have forms in the HTML >uses {{mediawiki.internal('CSS', "de")}} to specify their present
>sense. Likewise, XUL specific features such as overlays and templ>ation. * XUL may be loaded from a remote site, the local file sys
>ates are only available in XUL documents. This distinction betwee>tem, or installed as a package and accessed using a {{mediawiki.i
>n documents is important. It is possible to use many XUL features>nternal('chrome', "de")}} URL. This last option is what browser e
> in HTML or XML documents since they aren't document type specifi>xtensions do. * Chrome URLs may be used to access installed packa
>c; however other features require the right kind of document. For>ges and open them with enhanced privileges. * HTML, XML, and XUL 
> instance, you can use the XUL layout types in other documents si>each have a different document type. Some features may be used in
>nce they don't rely on the XUL document type to function. To summ> any document type whereas some features are specific to one kind
>arize the points made above: * Mozilla renders both {{mediawiki.i> of document. The next few sections describe the basic structure 
>nternal('HTML', "de")}} and {{mediawiki.internal('XUL', "de")}} u>of a chrome package which can be installed into Mozilla. However,
>sing the same underlying engine and uses {{mediawiki.internal('CS> if you just want to get started building a simple application, y
>S', "de")}} to specify their presentation. * XUL may be loaded fr>ou may skip ahead to {{mediawiki.internal('XUL Tutorial:Creating 
>om a remote site, the local file system, or installed as a packag>a Window|Creating a Window', "de")}} and save this section for la
>e and accessed using a {{mediawiki.internal('chrome', "de")}} URL>ter. == Package Organization == Mozilla is organized in such a wa
>. This last option is what browser extensions do. * Chrome URLs m>y that you can have as many components as you want pre-installed.
>ay be used to access installed packages and open them with enhanc> Each extension is also a component with a separate chrome URL. I
>ed privileges. * HTML, XML, and XUL each have a different documen>t also has one component for each installed theme and locale. Eac
>t type. Some features may be used in any document type whereas so>h of these components, or packages, is made up of a set of files 
>me features are specific to one kind of document. The next few se>that describe the user interface for it. For example, the messeng
>ctions describe the basic structure of a chrome package which can>er component has descriptions of the mail messages list window, t
> be installed into Mozilla. However, if you just want to get star>he composition window and the address book dialogs. The packages 
>ted building a simple application, you may skip ahead to {{mediaw>that are provided with Mozilla are located within the chrome dire
>iki.internal('XUL Tutorial:Creating a Window|Creating a Window', >ctory, which are in the directory where you installed Mozilla. Th
>"de")}} and save this section for later. == Package Organization >e chrome directory is where you find all the files that describe 
>== Mozilla is organized in such a way that you can have as many c>the user interface used by the Mozilla browser, mail client, and 
>omponents as you want pre-installed. Each extension is also a com>other applications. Typically, you put all the XUL files for an a
>ponent with a separate chrome URL. It also has one component for >pplication in this directory, although extensions are installed i
>each installed theme and locale. Each of these components, or pac>n the extensions directory for a particular user. Just copying a 
>kages, is made up of a set of files that describe the user interf>XUL file into the &lt;tt&gt;chrome&lt;/tt&gt; directory doesn't g
>ace for it. For example, the messenger component has descriptions>ive the file any extra permissions, nor can it be accessed via a 
> of the mail messages list window, the composition window and the>chrome URL. To gain the extra privileges, you will need to create
> address book dialogs. The packages that are provided with Mozill> a manifest file and put that in the chrome directory. This file 
>a are located within the chrome directory, which are in the direc>is easy to create, as it is typically only a couple of lines long
>tory where you installed Mozilla. The chrome directory is where y>. It is used to map a chrome URL to a file or directory path on t
>ou find all the files that describe the user interface used by th>he disk where the XUL files are located. Details of how to create
>e Mozilla browser, mail client, and other applications. Typically> this file will be discussed in a {{mediawiki.internal('XUL Tutor
>, you put all the XUL files for an application in this directory,>ial:Manifest Files|later section', "de")}}. The only way to creat
> although extensions are installed in the extensions directory fo>e content that can be accessed through a chrome URL is by creatin
>r a particular user. Just copying a XUL file into the &lt;tt&gt;c>g a package as described in the next few sections. This directory
>hrome&lt;/tt&gt; directory doesn't give the file any extra permis> is called 'chrome' likely because it seemed like a convenient na
>sions, nor can it be accessed via a chrome URL. To gain the extra>me to use for the directory where the chrome packages that are in
> privileges, you will need to create a manifest file and put that>cluded with Mozilla are kept. To further the confusion, there are
> in the chrome directory. This file is easy to create, as it is t> two other places where the word "chrome" might appear. These are
>ypically only a couple of lines long. It is used to map a chrome > the &lt;code&gt;-chrome&lt;/code&gt; command line argument and t
>URL to a file or directory path on the disk where the XUL files a>he &lt;code&gt;chrome&lt;/code&gt; modifier to the &lt;code&gt;{{
>re located. Details of how to create this file will be discussed >mediawiki.internal('DOM:window.open|window.open()', "de")}}&lt;/c
>in a {{mediawiki.internal('XUL Tutorial:Manifest Files|later sect>ode&gt; function. Neither of these features grant extra privilege
>ion', "de")}}. The only way to create content that can be accesse>s; instead they are used to open a new top-level window without t
>d through a chrome URL is by creating a package as described in t>he browser UI such as the menu and toolbar. You will commonly use
>he next few sections. This directory is called 'chrome' likely be> this feature in more complex XUL applications since you wouldn't
>cause it seemed like a convenient name to use for the directory w> want the browser UI to exist around your dialog boxes. The files
>here the chrome packages that are included with Mozilla are kept.> for a package are usually combined into a single JAR file. A JAR
> To further the confusion, there are two other places where the w> file may created and examined using a ZIP utility. For instance,
>ord "chrome" might appear. These are the &lt;code&gt;-chrome&lt;/> you can open the JAR files in Mozilla's &lt;tt&gt;chrome&lt;/tt&
>code&gt; command line argument and the &lt;code&gt;chrome&lt;/cod>gt; directory to see the basic structure of a package. Although i
>e&gt; modifier to the &lt;code&gt;{{mediawiki.internal('DOM:windo>t's normal to combine the files into a JAR file, packages may als
>w.open|window.open()', "de")}}&lt;/code&gt; function. Neither of >o be accessed in expanded form into a directory. Although you don
>these features grant extra privileges; instead they are used to o>'t normally distribute a package this way, it is handy during dev
>pen a new top-level window without the browser UI such as the men>elopment since you can edit the file directly and then reload the
>u and toolbar. You will commonly use this feature in more complex> XUL file without having to repackage or reinstall the files. By 
> XUL applications since you wouldn't want the browser UI to exist>default, Mozilla applications parse XUL files and scripts, and st
> around your dialog boxes. The files for a package are usually co>ore a pre-compiled version in memory for the remainder of the app
>mbined into a single JAR file. A JAR file may created and examine>lication session. This improves performance. However, because of 
>d using a ZIP utility. For instance, you can open the JAR files i>this, the XUL will be not be reloaded even when the source files 
>n Mozilla's &lt;tt&gt;chrome&lt;/tt&gt; directory to see the basi>are changed. To disable this mechanism, it is necessary to change
>c structure of a package. Although it's normal to combine the fil> the preference &lt;code&gt;nglayout.debug.disable_xul_cache&lt;/
>es into a JAR file, packages may also be accessed in expanded for>code&gt;. In Firefox, this preference may be added to the user pr
>m into a directory. Although you don't normally distribute a pack>eferences by typing "about:config" in the address field, and sett
>age this way, it is handy during development since you can edit t>ing this value to true. Or, just manually edit your &lt;tt&gt;use
>he file directly and then reload the XUL file without having to r>r.js&lt;/tt&gt; preferences file and add the following line: pref
>epackage or reinstall the files. By default, Mozilla applications>("nglayout.debug.disable_xul_cache", true); There are usually thr
> parse XUL files and scripts, and store a pre-compiled version in>ee different parts to a chrome package, although they are all opt
> memory for the remainder of the application session. This improv>ional. Each part is stored in a different directory. These three 
>es performance. However, because of this, the XUL will be not be >sets are the content, the skin, and the locale, which are all des
>reloaded even when the source files are changed. To disable this >cribed below. A particular package might provide one or more skin
>mechanism, it is necessary to change the preference &lt;code&gt;n>s and locales, but a user can replace them with their own. In add
>glayout.debug.disable_xul_cache&lt;/code&gt;. In Firefox, this pr>ition, the package might include several different applications, 
>eference may be added to the user preferences by typing "about:co>each accessible via different chrome URLs. The packaging system i
>nfig" in the address field, and setting this value to true. Or, j>s flexible enough so that you can include whatever parts you need
>ust manually edit your &lt;tt&gt;user.js&lt;/tt&gt; preferences f> and allow other parts, such as the text for different languages,
>ile and add the following line: pref("nglayout.debug.disable_xul_> to be downloaded separately. The three types of chrome packages 
>cache", true); There are usually three different parts to a chrom>are: &lt;ul&gt; &lt;li&gt;'''Content''' - Windows and scripts&lt;
>e package, although they are all optional. Each part is stored in>br /&gt; The declarations of the windows and the user interface e
> a different directory. These three sets are the content, the ski>lements contained within them. These are stored in XUL files, whi
>n, and the locale, which are all described below. A particular pa>ch have a &lt;tt&gt;.xul&lt;/tt&gt; extension. A content package 
>ckage might provide one or more skins and locales, but a user can>can have multiple XUL files, but the main window should have a fi
> replace them with their own. In addition, the package might incl>lename that is the same as the package name. For example, the edi
>ude several different applications, each accessible via different>tor package will have a file within it called &lt;tt&gt;editor.xu
> chrome URLs. The packaging system is flexible enough so that you>l&lt;/tt&gt;. Scripts are placed in separate files alongside the 
> can include whatever parts you need and allow other parts, such >XUL files. &lt;/li&gt; &lt;li&gt;'''Skin''' - Style sheets, image
>as the text for different languages, to be downloaded separately.>s and other theme specific files&lt;br /&gt; Style sheets describ
> The three types of chrome packages are: &lt;ul&gt; &lt;li&gt;'''>e details of the appearance of a window. They are stored separate
>Content''' - Windows and scripts&lt;br /&gt; The declarations of >ly from XUL files to facilitate modifying the skin (theme) of an 
>the windows and the user interface elements contained within them>application. Any images used are stored here also. &lt;/li&gt; &l
>. These are stored in XUL files, which have a &lt;tt&gt;.xul&lt;/>t;li&gt;'''Locale''' - Locale specific files&lt;br /&gt; All the 
>tt&gt; extension. A content package can have multiple XUL files, >text that is displayed within a window is stored separately. This
>but the main window should have a filename that is the same as th> way, a user can have a set for their own language. &lt;/li&gt; &
>e package name. For example, the editor package will have a file >lt;/ul&gt; == Content Packages == The name of the JAR file might 
>within it called &lt;tt&gt;editor.xul&lt;/tt&gt;. Scripts are pla>describe what it contains, but you can't be sure unless you view 
>ced in separate files alongside the XUL files. &lt;/li&gt; &lt;li>its contents. Let's use the browser package included with Firefox
>&gt;'''Skin''' - Style sheets, images and other theme specific fi> as an example. If you extract the files in &lt;tt&gt;browser.jar
>les&lt;br /&gt; Style sheets describe details of the appearance o>&lt;/tt&gt;, you will find that it contains a directory structure
>f a window. They are stored separately from XUL files to facilita> much like the following: &lt;pre&gt; content browser browser.xul
>te modifying the skin (theme) of an application. Any images used > browser.js -- other browser XUL and JS files goes here -- bookma
>are stored here also. &lt;/li&gt; &lt;li&gt;'''Locale''' - Locale>rks -- bookmarks files go here -- preferences -- preferences file
> specific files&lt;br /&gt; All the text that is displayed within>s go here -- . . . &lt;/pre&gt; This is easily recognizable as a 
> a window is stored separately. This way, a user can have a set f>content package, as the top-level directory is called &lt;tt&gt;c
>or their own language. &lt;/li&gt; &lt;/ul&gt; == Content Package>ontent&lt;/tt&gt;. For skins, this directory will usually be call
>s == The name of the JAR file might describe what it contains, bu>ed &lt;tt&gt;skin&lt;/tt&gt; and for locales, it will usually be 
>t you can't be sure unless you view its contents. Let's use the b>called &lt;tt&gt;locale&lt;/tt&gt;. This naming scheme isn't nece
>rowser package included with Firefox as an example. If you extrac>ssary, but this is a common convention to make the parts of a pac
>t the files in &lt;tt&gt;browser.jar&lt;/tt&gt;, you will find th>kage clearer. Some packages may include a content section, a skin
>at it contains a directory structure much like the following: &lt>, and a locale. In this case, you will find a subdirectory for ea
>;pre&gt; content browser browser.xul browser.js -- other browser >ch type. For example, Chatzilla is distributed in this way. The &
>XUL and JS files goes here -- bookmarks -- bookmarks files go her>lt;tt&gt;content/browser&lt;/tt&gt; directory contains a number o
>e -- preferences -- preferences files go here -- . . . &lt;/pre&g>f files with &lt;tt&gt;.xul&lt;/tt&gt; and &lt;tt&gt;.js&lt;/tt&g
>t; This is easily recognizable as a content package, as the top-l>t; extensions. The XUL files are the ones with the &lt;tt&gt;.xul
>evel directory is called &lt;tt&gt;content&lt;/tt&gt;. For skins,>&lt;/tt&gt; extension. The files with &lt;tt&gt;.js&lt;/tt&gt; ex
> this directory will usually be called &lt;tt&gt;skin&lt;/tt&gt; >tensions are JavaScript files containing scripts that handle the 
>and for locales, it will usually be called &lt;tt&gt;locale&lt;/t>functionality of a window. Many XUL files have a script file asso
>t&gt;. This naming scheme isn't necessary, but this is a common c>ciated with them, and some may have more than one. In the listing
>onvention to make the parts of a package clearer. Some packages m> above, two files have been shown. There are of course others, bu
>ay include a content section, a skin, and a locale. In this case,>t for simplicity they aren't shown. The file &lt;tt&gt;browser.xu
> you will find a subdirectory for each type. For example, Chatzil>l&lt;/tt&gt; is the XUL file that describes the main browser wind
>la is distributed in this way. The &lt;tt&gt;content/browser&lt;/>ow. The main window for a content package should have the same na
>tt&gt; directory contains a number of files with &lt;tt&gt;.xul&l>me as the package with a &lt;tt&gt;.xul&lt;/tt&gt; extension. In 
>t;/tt&gt; and &lt;tt&gt;.js&lt;/tt&gt; extensions. The XUL files >this case, the package name is "browser" so we expect to find &lt
>are the ones with the &lt;tt&gt;.xul&lt;/tt&gt; extension. The fi>;tt&gt;browser.xul&lt;/tt&gt;. Some of the other XUL files descri
>les with &lt;tt&gt;.js&lt;/tt&gt; extensions are JavaScript files>be separate windows. For example, the file &lt;tt&gt;pageInfo.xul
> containing scripts that handle the functionality of a window. Ma>&lt;/tt&gt; describes the page info dialog. Many packages will in
>ny XUL files have a script file associated with them, and some ma>clude a &lt;tt&gt;contents.rdf&lt;/tt&gt; file, which describes t
>y have more than one. In the listing above, two files have been s>he package, its author, and the overlays it uses. However, this f
>hown. There are of course others, but for simplicity they aren't >ile is obsolete and has been replaced with a simpler mechanism. T
>shown. The file &lt;tt&gt;browser.xul&lt;/tt&gt; is the XUL file >his newer method is the manifest file mentioned earlier, and you 
>that describes the main browser window. The main window for a con>will find these as files with the &lt;tt&gt;.manifest&lt;/tt&gt; 
>tent package should have the same name as the package with a &lt;>extension in the chrome directory. For instance, &lt;tt&gt;browse
>tt&gt;.xul&lt;/tt&gt; extension. In this case, the package name i>r.manifest&lt;/tt&gt; describes the browser package. Several subd
>s "browser" so we expect to find &lt;tt&gt;browser.xul&lt;/tt&gt;>irectories, such as &lt;tt&gt;bookmarks&lt;/tt&gt; and &lt;tt&gt;
>. Some of the other XUL files describe separate windows. For exam>preferences&lt;/tt&gt;, describe additional sections of the brows
>ple, the file &lt;tt&gt;pageInfo.xul&lt;/tt&gt; describes the pag>er component. They are placed in different directories only to ke
>e info dialog. Many packages will include a &lt;tt&gt;contents.rd>ep the files more organized. == Skins or Themes == Although the u
>f&lt;/tt&gt; file, which describes the package, its author, and t>nderlying code for Mozilla calls them skins and the user interfac
>he overlays it uses. However, this file is obsolete and has been >e calls them themes, they're both referring to the same thing. Th
>replaced with a simpler mechanism. This newer method is the manif>e &lt;tt&gt;classic.jar&lt;/tt&gt; file describes the default the
>est file mentioned earlier, and you will find these as files with>me provided with Firefox. The structure is similar to the content
> the &lt;tt&gt;.manifest&lt;/tt&gt; extension in the chrome direc> packages. For example, examining &lt;tt&gt;classic.jar&lt;/tt&gt
>tory. For instance, &lt;tt&gt;browser.manifest&lt;/tt&gt; describ>;: &lt;pre&gt; skin classic browser browser.css -- other browser 
>es the browser package. Several subdirectories, such as &lt;tt&gt>skin files go here -- global -- global skin files go here -- . . 
>;bookmarks&lt;/tt&gt; and &lt;tt&gt;preferences&lt;/tt&gt;, descr>. &lt;/pre&gt; Again, this directory structure isn't necessary an
>ibe additional sections of the browser component. They are placed>d is used for convenience. You can actually put all the files in 
> in different directories only to keep the files more organized. >one directory at the top level and not use subdirectories. Howeve
>== Skins or Themes == Although the underlying code for Mozilla ca>r, for larger applications, subdirectories are used to separate t
>lls them skins and the user interface calls them themes, they're >he different components. In the example above, a directory exists
>both referring to the same thing. The &lt;tt&gt;classic.jar&lt;/t> for theme related files for the browser and another for global t
>t&gt; file describes the default theme provided with Firefox. The>heme related files. The global directory contains skin files that
> structure is similar to the content packages. For example, exami> are general to all packages. These files will apply to all compo
>ning &lt;tt&gt;classic.jar&lt;/tt&gt;: &lt;pre&gt; skin classic b>nents and will be included with your own standalone applications.
>rowser browser.css -- other browser skin files go here -- global > The global part defines the appearance of all of the common XUL 
>-- global skin files go here -- . . . &lt;/pre&gt; Again, this di>widgets, whereas the other directories have files that are specif
>rectory structure isn't necessary and is used for convenience. Yo>ic to those applications. Firefox includes both the global and br
>u can actually put all the files in one directory at the top leve>owser theme files in one archive, but they can be included separa
>l and not use subdirectories. However, for larger applications, s>tely. A skin is made up of CSS files and a number of images used 
>ubdirectories are used to separate the different components. In t>to define the look of an interface. The file &lt;tt&gt;browser.cs
>he example above, a directory exists for theme related files for >s&lt;/tt&gt; is used by &lt;tt&gt;browser.xul&lt;/tt&gt; and cont
>the browser and another for global theme related files. The globa>ains styles that define the appearance of various parts of the br
>l directory contains skin files that are general to all packages.>owser interface. Again, note how the file &lt;tt&gt;browser.css&l
> These files will apply to all components and will be included wi>t;/tt&gt; has the same name as the package. By changing the CSS f
>th your own standalone applications. The global part defines the >iles, you can adjust the appearance of a window without changing 
>appearance of all of the common XUL widgets, whereas the other di>its function. This is how you can create a new theme. The XUL par
>rectories have files that are specific to those applications. Fir>t remains the same but the skin part changes independently. == Lo
>efox includes both the global and browser theme files in one arch>cales == The file &lt;tt&gt;en-US.jar&lt;/tt&gt; describes the la
>ive, but they can be included separately. A skin is made up of CS>nguage information for each component, in this case for US Englis
>S files and a number of images used to define the look of an inte>h. Like the skins, each language file contains files that specify
>rface. The file &lt;tt&gt;browser.css&lt;/tt&gt; is used by &lt;t> text used by the package for a specific language. The locale str
>t&gt;browser.xul&lt;/tt&gt; and contains styles that define the a>ucture is similar to the others, so it won't be listed here. The 
>ppearance of various parts of the browser interface. Again, note >localized text is stored in two types of files: DTD files and pro
>how the file &lt;tt&gt;browser.css&lt;/tt&gt; has the same name a>perties files. The DTD files have a &lt;tt&gt;.dtd&lt;/tt&gt; ext
>s the package. By changing the CSS files, you can adjust the appe>ension and contain entity declarations, one for each text string 
>arance of a window without changing its function. This is how you>that is used in a window. For example, the file &lt;tt&gt;browser
> can create a new theme. The XUL part remains the same but the sk>.dtd&lt;/tt&gt; contains entity declarations for each menu comman
>in part changes independently. == Locales == The file &lt;tt&gt;e>d. In addition, keyboard shortcuts for each command are also defi
>n-US.jar&lt;/tt&gt; describes the language information for each c>ned, because they may be different for each language. DTD files a
>omponent, in this case for US English. Like the skins, each langu>re used by XUL files so, in general, you will have one per XUL fi
>age file contains files that specify text used by the package for>le. The locale part also contains properties files, which are sim
> a specific language. The locale structure is similar to the othe>ilar, but are used by script files. The file &lt;tt&gt;browser.pr
>rs, so it won't be listed here. The localized text is stored in t>operties&lt;/tt&gt; contains a few such localized strings. This s
>wo types of files: DTD files and properties files. The DTD files >tructure allows you to translate Mozilla or a component into a di
>have a &lt;tt&gt;.dtd&lt;/tt&gt; extension and contain entity dec>fferent language by just adding a new locale for that language. Y
>larations, one for each text string that is used in a window. For>ou don't have to change the XUL code at all. In addition, another
> example, the file &lt;tt&gt;browser.dtd&lt;/tt&gt; contains enti> person could supply a separate package that applies a skin or lo
>ty declarations for each menu command. In addition, keyboard shor>cale to your content part, thus providing support for a new theme
>tcuts for each command are also defined, because they may be diff> or language without having to change the original package. == Ot
>erent for each language. DTD files are used by XUL files so, in g>her Packages == There is a special package called toolkit (or glo
>eneral, you will have one per XUL file. The locale part also cont>bal). We saw the global directory earlier for skins. The file &lt
>ains properties files, which are similar, but are used by script >;tt&gt;toolkit.jar&lt;/tt&gt; contains the corresponding content 
>files. The file &lt;tt&gt;browser.properties&lt;/tt&gt; contains >part for it. It contains some global dialogs and definitions. It 
>a few such localized strings. This structure allows you to transl>also defines the default appearance and functionality of the vari
>ate Mozilla or a component into a different language by just addi>ous common XUL widgets such as textboxes and buttons. The files l
>ng a new locale for that language. You don't have to change the X>ocated in the global part of a skin package contain the default l
>UL code at all. In addition, another person could supply a separa>ook for all of the XUL interface elements. The toolkit package is
>te package that applies a skin or locale to your content part, th> used by all XUL applications. == Adding a Package == Mozilla pla
>us providing support for a new theme or language without having t>ces the packages that are included with the installation in the &
>o change the original package. == Other Packages == There is a sp>lt;tt&gt;chrome&lt;/tt&gt; directory. However, they do not need t
>ecial package called toolkit (or global). We saw the global direc>o be placed there. When installing another package, you can place
>tory earlier for skins. The file &lt;tt&gt;toolkit.jar&lt;/tt&gt;> it anywhere on the disk, as long as a manifest file points to it
> contains the corresponding content part for it. It contains some>. It is common to place packages into the &lt;tt&gt;chrome&lt;/tt
> global dialogs and definitions. It also defines the default appe>&gt; directory simply because it is convenient; however, they wil
>arance and functionality of the various common XUL widgets such a>l work just as well from another directory or somewhere on your l
>s textboxes and buttons. The files located in the global part of >ocal network. You cannot store them on a remote site, unless the 
>a skin package contain the default look for all of the XUL interf>remote site is mounted through the local file system. There are t
>ace elements. The toolkit package is used by all XUL applications>wo &lt;tt&gt;chrome&lt;/tt&gt; directories used for XUL applicati
>. == Adding a Package == Mozilla places the packages that are inc>ons: one is installed in the same place where the application is 
>luded with the installation in the &lt;tt&gt;chrome&lt;/tt&gt; di>installed, while the other is part of user's profile. The former 
>rectory. However, they do not need to be placed there. When insta>allows packages that are shared by all users while the latter all
>lling another package, you can place it anywhere on the disk, as >ows packages to be created only for a specific user or users. Ext
>long as a manifest file points to it. It is common to place packa>ensions, while installed in a separate extensions directory, are 
>ges into the &lt;tt&gt;chrome&lt;/tt&gt; directory simply because>also usually user specific. Any manifest files located in either 
> it is convenient; however, they will work just as well from anot>chrome directory will be examined to see which packages are insta
>her directory or somewhere on your local network. You cannot stor>lled. In the next section, we'll look at how to refer to chrome p
>e them on a remote site, unless the remote site is mounted throug>ackages using the chrome URL.</span> {{template.PreviousNext("XUL
>h the local file system. There are two &lt;tt&gt;chrome&lt;/tt&gt> Tutorial:Einfuehrung", "XUL Tutorial:Die Chrome-URL")}} <span cl
>; directories used for XUL applications: one is installed in the >ass="comment">Interwiki Language Links</span>
>same place where the application is installed, while the other is 
> part of user's profile. The former allows packages that are shar 
>ed by all users while the latter allows packages to be created on 
>ly for a specific user or users. Extensions, while installed in a 
> separate extensions directory, are also usually user specific. A 
>ny manifest files located in either chrome directory will be exam 
>ined to see which packages are installed. In the next section, we 
>'ll look at how to refer to chrome packages using the chrome URL. 
></span> {{template.PreviousNext("Tutorial XUL:Einfuehrung", "XUL  
>Tutorial:Die Chrome-URL")}} <span class="comment">Interwiki Langu 
>age Links</span> 

Zurück zur Versionsgeschichte