mozilla

Compare Revisions

A XUL Bestiary

Change Revisions

Revision 68994:

Revision 68994 by Andreas Wuest on

Revision 68995:

Revision 68995 by Mgjbot on

Title:
A XUL Bestiary
A XUL Bestiary
Slug:
XUL/A_XUL_Bestiary
XUL/A_XUL_Bestiary
Tags:
NeedsTechnicalReview, Extensions, Add-ons, XUL
NeedsTechnicalReview, Extensions, Add-ons, XUL
Content:

Revision 68994
Revision 68995
n23&lt;?xml-stylesheet href="chrome://global/skin/" type="text/css"?n23&lt;?xml-stylesheet href="<a class=" external" href="chrome://glo
>&gt;>bal/skin/" rel="freelink">chrome://global/skin/</a>" type="text/c
 >ss"?&gt;
n31  oncommand="window.openDialog('chrome://help/content/help.xul',n31  oncommand="window.openDialog('<a class=" external" href="chrome
 >://help/content/help.xul" rel="freelink">chrome://help/content/he
 >lp.xul</a>',
n36      In this example, the chrome url is being used to point to an36      In this example, the chrome url is being used to point to a
> chrome within the package hierarchy of the Mozilla application. > chrome within the package hierarchy of the Mozilla application. 
>A Help chrome defined in mozilla/bin/chrome/help/ is being invoke>A Help chrome defined in mozilla/bin/chrome/help/ is being invoke
>d from the Help menu. Note that when no file name is specified af>d from the Help menu. Note that when no file name is specified af
>ter the chrome directory path, a file name with the same name as >ter the chrome directory path, a file name with the same name as 
>the package is assumed. In other words, a chrome url like the glo>the package is assumed. In other words, a chrome url like the glo
>bal pointer above picks up a file called global.css, and the help>bal pointer above picks up a file called global.css, and the help
> pointer above could also be written as 'chrome://help/content', > pointer above could also be written as '<a class=" external" hre
>because the name of the package itself is "help.">f="chrome://help/content" rel="freelink">chrome://help/content</a
 >>', because the name of the package itself is "help."
n45mozilla -chrome chrome://help/content/help.xuln45mozilla -chrome <a class=" external" href="chrome://help/content/
 >help.xul" rel="freelink">chrome://help/content/help.xul</a>
n72      The default directory underneath each of these main packagen72      The default directory underneath each of these main package
> subdirectories is assumed in the chrome url (i.e., chrome://help> subdirectories is assumed in the chrome url (i.e., <a class=" ex
>/content/help.xul does not include a default directory as part of>ternal" href="chrome://help/content/help.xul" rel="freelink">chro
> the url, though that directory exists in the actual structure). >me://help/content/help.xul</a> does not include a default directo
>When you create different chrome for a package, you can create a >ry as part of the url, though that directory exists in the actual
>subdirectory underneath content whose contents are loaded instead> structure). When you create different chrome for a package, you 
> of default. For example, if you want to create a different skin >can create a subdirectory underneath content whose contents are l
>for the navigator package, you can create a subdirectory undernea>oaded instead of default. For example, if you want to create a di
>th navigator/skin/ whose contents will be loaded instead of defau>fferent skin for the navigator package, you can create a subdirec
>lt's. So the following structure obtains:>tory underneath navigator/skin/ whose contents will be loaded ins
 >tead of default's. So the following structure obtains:
n97chrome://navigator/skin/myNewSkin/newskin.cssn97<a class=" external" href="chrome://navigator/skin/myNewSkin/news
 >kin.css" rel="freelink">chrome://navigator/skin/myNewSkin/newskin
 >.css</a>
n187      Mozilla is obviously a lot more than simply an interface. In187      Mozilla is obviously a lot more than simply an interface. I
>t's cross-platform, and standards-based, and yet in some way, the>t's cross-platform, and standards-based, and yet in some way, the
> event handlers written once in JavaScript and living in the XUL > event handlers written once in JavaScript and living in the XUL 
>interface are getting very serious things done down in the applic>interface are getting very serious things done down in the applic
>ation core. Things like socket interfaces, editing, mail/news, se>ation core. Things like socket interfaces, editing, mail/news, se
>curity. The technologies that make this possible are perhaps the >curity. The technologies that make this possible are perhaps the 
>least understood of the phalanx of innovations that is Mozilla. I>least understood of the phalanx of innovations that is Mozilla. I
>n addition to the small matter of programming these serious thing>n addition to the small matter of programming these serious thing
>s in C++ and compiling them platform for platform, the architects>s in C++ and compiling them platform for platform, the architects
> and developers of Mozilla use three "XP" technologies to link th> and developers of Mozilla use three "XP" technologies to link th
>e core with the interface. XPCOM is not a programming language bu>e core with the interface. XPCOM is not a programming language bu
>t an approach to programming (in C++, say) that provides for a tr>t an approach to programming (in C++, say) that provides for a tr
>uly cross-platform Component Object Model, whence the technology >uly cross-platform Component Object Model, whence the technology 
>gets its name. Based on COM, XPCOM insists that chunks of code pr>gets its name. Based on COM, XPCOM insists that chunks of code pr
>ovide language- and platform-neutral interfaces that other object>ovide language- and platform-neutral interfaces that other object
>s can use to access its services. XPCOM enforces rules for design>s can use to access its services. XPCOM enforces rules for design
> and compilation that make it possible to use the services of an > and compilation that make it possible to use the services of an 
>object without knowing anything about implementation. XPIDL, the >object without knowing anything about implementation. XPIDL, the 
>Cross-Platform Interface Definition Language, is a language in wh>Cross-Platform Interface Definition Language, is a language in wh
>ich these interfaces insisted upon by XPCOM can be described. Whe>ich these interfaces insisted upon by XPCOM can be described. Whe
>n XPIDL is used to describe the XPCOM interfaces, it makes those >n XPIDL is used to describe the XPCOM interfaces, it makes those 
>interfaces available in special header files. Finally, XPConnect >interfaces available in special header files. Finally, XPConnect 
>is the technology that connects these XPCOM/XPIDL interfaces to J>is the technology that connects these XPCOM/XPIDL interfaces to J
>avaScript, the scripting language XUL uses. These three cross-pla>avaScript, the scripting language XUL uses. These three cross-pla
>tform glue technologies fit in the middle of an architecture that>tform glue technologies fit in the middle of an architecture that
> looks something like this: <img align="none" alt="Bridging C++ a> looks something like this: <img align="none" alt="Bridging C++ a
>nd JavaScript" src="File:en/Media_Gallery/Moz_xp.png">>nd JavaScript" fileid="775" src="File:en/Media_Gallery/Moz_xp.png
 >">
188    </p>
189    <p>188    </p>
189    <p>
190      Author: <a class="external" href="mailto:oeschger@netscape.190      Author: <a class="link-mailto" href="mailto:oeschger@netsca
>com">Ian Oeschger</a><br>>pe.com">Ian Oeschger</a><br>
n198        <li>Author(s): <a class="external" href="mailto:oeschger@n198        <li>Author(s): <a class="link-mailto" href="mailto:oeschg
>netscape.com">Ian Oeschger</a>>er@netscape.com">Ian Oeschger</a>
n202        <li>Copyright Information: Copyright (C) <a class="externn202        <li>Copyright Information: Copyright (C) <a class="link-m
>al" href="mailto:oeschger@netscape.com">Ian Oeschger</a>>ailto" href="mailto:oeschger@netscape.com">Ian Oeschger</a>
t205    </div>t205    </div>{{ languages( { "ja": "ja/A_XUL_Bestiary" } ) }}

Back to History