From 33058f2b292b3a581333bdfb21b8f671898c5060 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:40:17 -0500 Subject: initial commit --- .../chrome/css/-moz-window-dragging/index.html | 107 ++++++ .../index.html | 19 + .../_doublecolon_-moz-tree-cell-text/index.html | 32 ++ .../css/_doublecolon_-moz-tree-cell/index.html | 40 ++ .../css/_doublecolon_-moz-tree-column/index.html | 31 ++ .../index.html | 30 ++ .../css/_doublecolon_-moz-tree-image/index.html | 36 ++ .../_doublecolon_-moz-tree-indentation/index.html | 29 ++ .../css/_doublecolon_-moz-tree-line/index.html | 30 ++ .../index.html | 30 ++ .../_doublecolon_-moz-tree-row(hover)/index.html | 19 + .../css/_doublecolon_-moz-tree-row/index.html | 55 +++ .../_doublecolon_-moz-tree-separator/index.html | 31 ++ .../css/_doublecolon_-moz-tree-twisty/index.html | 35 ++ files/fr/mozilla/gecko/chrome/css/index.html | 25 ++ files/fr/mozilla/gecko/chrome/index.html | 15 + files/fr/mozilla/gecko/faq/index.html | 201 ++++++++++ .../gecko/gecko_embedding_basics/index.html | 403 ++++++++++++++++++++ files/fr/mozilla/gecko/index.html | 118 ++++++ .../api_overview/index.html" | 422 +++++++++++++++++++++ .../embarquer_gecko/index.html" | 133 +++++++ .../index.html" | 53 +++ .../gecko/mozilla_embarqu\303\251/index.html" | 59 +++ .../int\303\251gration_\303\251diteur/index.html" | 133 +++++++ files/fr/mozilla/gecko/sdk_gecko/index.html | 61 +++ 25 files changed, 2147 insertions(+) create mode 100644 files/fr/mozilla/gecko/chrome/css/-moz-window-dragging/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text(hover)/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-column/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-drop-feedback/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-image/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-indentation/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-line/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-progressmeter/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row(hover)/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-separator/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-twisty/index.html create mode 100644 files/fr/mozilla/gecko/chrome/css/index.html create mode 100644 files/fr/mozilla/gecko/chrome/index.html create mode 100644 files/fr/mozilla/gecko/faq/index.html create mode 100644 files/fr/mozilla/gecko/gecko_embedding_basics/index.html create mode 100644 files/fr/mozilla/gecko/index.html create mode 100644 "files/fr/mozilla/gecko/mozilla_embarqu\303\251/api_overview/index.html" create mode 100644 "files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/embarquer_gecko/index.html" create mode 100644 "files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/introduction_\303\240_gecko_et_\303\240_l'embarqu\303\251/index.html" create mode 100644 "files/fr/mozilla/gecko/mozilla_embarqu\303\251/index.html" create mode 100644 "files/fr/mozilla/gecko/mozilla_embarqu\303\251/int\303\251gration_\303\251diteur/index.html" create mode 100644 files/fr/mozilla/gecko/sdk_gecko/index.html (limited to 'files/fr/mozilla/gecko') diff --git a/files/fr/mozilla/gecko/chrome/css/-moz-window-dragging/index.html b/files/fr/mozilla/gecko/chrome/css/-moz-window-dragging/index.html new file mode 100644 index 0000000000..55ddef129a --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/-moz-window-dragging/index.html @@ -0,0 +1,107 @@ +--- +title: '-moz-window-dragging' +slug: Mozilla/Gecko/Chrome/CSS/-moz-window-dragging +tags: + - CSS + - Non-standard + - Propriété + - Reference + - XUL +translation_of: Mozilla/Gecko/Chrome/CSS/-moz-window-dragging +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

La propriété -moz-window-dragging indique si une fenêtre peut être déplacée. Elle ne peut être utilisée qu'à partir de code appelé pour l'interface utilisateur du navigateur et uniquement sur macOS X.

+ +

Cette propriété a été ajoutée à Firefox 35 afin de résoudre certains problèmes liés à la fenêtre de Firefox qui ne pouvait pas être déplacé lorsque celui-ci était occupé ({{bug(944836)}}).

+ +

{{cssinfo}}

+ +

Syntaxe

+ +

La propriété -moz-window-dragging s'utilise avec un des mots-clés parmi ceux de la liste suivante.

+ +

Valeurs

+ +
+
drag
+
La fenêtre peut être déplacée.
+
no-drag
+
La fenêtre ne peut pas être déplacée.
+
+ +

Syntaxe formelle

+ +
{{csssyntax}}
+ +

Exemple

+ +
toolbarpaletteitem {
+  -moz-window-dragging: no-drag;
+}
+ +

Spécifications

+ +

Cette propriété ne fait partie d'aucune spécification.

+ +

Compatibilité des navigateurs

+ +
{{CompatibilityTable}}
+ +
+ + + + + + + + + + + + + + + + + + + + + +
FonctionnalitéChromeEdgeFirefox (Gecko)Internet ExplorerOperaSafari (WebKit)
Support simple{{CompatNo}}{{CompatNo}} +

{{CompatGeckoDesktop(35)}}

+ 		{{CompatNo}}{{CompatNo}}{{CompatNo}}
+
+ +
+ + + + + + + + + + + + + + + + + + + + + + + + + +
FonctionnalitéAndroidWebview AndroidEdgeFirefox Mobile (Gecko)IE PhoneOpera MobileSafari MobileChrome pour Android
Support simple{{CompatNo}}{{CompatNo}}{{CompatNo}}{{CompatGeckoMobile(35)}}{{CompatNo}}{{CompatNo}}{{CompatNo}}{{CompatNo}}
+
+ +

 

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text(hover)/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text(hover)/index.html new file mode 100644 index 0000000000..37bcb675cd --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text(hover)/index.html @@ -0,0 +1,19 @@ +--- +title: ':-moz-tree-cell-text(hover)' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell-text(hover)' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell-text(hover)' +--- +
{{Non-standard_header}}{{CSSRef}}{{Fx_minversion_header(1.9)}}
+ +

La pseudo-classe :-moz-tree-cell-text(hover) correspond à un élément si le curseur de la souris est en train de survoler une cellule d'un arbre.

+ +

Ce sélecteur est principalement destiné aux développeurs de thèmes.

+ +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text/index.html new file mode 100644 index 0000000000..c20c552b1f --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell-text/index.html @@ -0,0 +1,32 @@ +--- +title: ':-moz-tree-cell-text' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell-text' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell-text' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell/index.html new file mode 100644 index 0000000000..5397076180 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-cell/index.html @@ -0,0 +1,40 @@ +--- +title: ':-moz-tree-cell' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-cell' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

+ +

Voir aussi

+ + diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-column/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-column/index.html new file mode 100644 index 0000000000..8e0bcb2932 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-column/index.html @@ -0,0 +1,31 @@ +--- +title: ':-moz-tree-column' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-column' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-column' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-drop-feedback/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-drop-feedback/index.html new file mode 100644 index 0000000000..2b81402253 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-drop-feedback/index.html @@ -0,0 +1,30 @@ +--- +title: ':-moz-tree-drop-feedback' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-drop-feedback' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-drop-feedback' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-image/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-image/index.html new file mode 100644 index 0000000000..2305bb1423 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-image/index.html @@ -0,0 +1,36 @@ +--- +title: ':-moz-tree-image' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-image' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/:-moz-tree-image' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Exemples

+ +

Bookmark icons in the Places window - Mozillazine Forum (en anglais)

+ +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-indentation/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-indentation/index.html new file mode 100644 index 0000000000..83d93fe084 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-indentation/index.html @@ -0,0 +1,29 @@ +--- +title: ':-moz-tree-indentation' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-indentation' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-indentation' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-line/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-line/index.html new file mode 100644 index 0000000000..b3306ea046 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-line/index.html @@ -0,0 +1,30 @@ +--- +title: ':-moz-tree-line' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-line' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-line' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée avec l'attribut properties.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-progressmeter/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-progressmeter/index.html new file mode 100644 index 0000000000..09f8ce7451 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-progressmeter/index.html @@ -0,0 +1,30 @@ +--- +title: ':-moz-tree-progressmeter' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-progressmeter' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-progressmeter' +--- +
{{Non-standard_header}}{{CSSRef}}
+ +

Cette pseudo-classe est activée lorsque l'attribut type est défini sur progressmeter.

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row(hover)/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row(hover)/index.html new file mode 100644 index 0000000000..bfc3bed3de --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row(hover)/index.html @@ -0,0 +1,19 @@ +--- +title: ':-moz-tree-row(hover)' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-row(hover)' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-row(hover)' +--- +
{{Non-standard_header}}{{CSSRef}}{{Fx_minversion_header(3)}}
+ +

La pseudo-classe :-moz-tree-row(hover) correspond à un élément si le curseur de la souris est en train de survoler une ligne d'un arbre.

+ +

Ce sélecteur est principalement destiné aux développeurs de thèmes.

+ +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row/index.html new file mode 100644 index 0000000000..6fd4596d0b --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-row/index.html @@ -0,0 +1,55 @@ +--- +title: ':-moz-tree-row' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-row' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-row' +--- +
{{CSSRef}}{{Non-standard_header}}
+ +

La pseudo-classe -moz-tree-row est utilisée afin de sélectionner des lignes d'un arbre pour leur appliquer des styles

+ +

Éléments XUL associés

+ + + +

Syntaxe

+ +
treechildren::-moz-tree-row { propriétés de style }
+
+ +

Propriétés associées

+ + + +

Exemples

+ +

CSS

+ +
treechildren::-moz-tree-row( toto bar )
+{
+  margin: 2%;
+}
+
+ +

XUL

+ +
<treerow properties="toto">…</treerow>
+
+ +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-separator/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-separator/index.html new file mode 100644 index 0000000000..2f0f6e1769 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-separator/index.html @@ -0,0 +1,31 @@ +--- +title: ':-moz-tree-separator' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-separator' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-separator' +--- +
{{CSSRef}}{{Non-standard_header}}
+ +

Cette pseudo-classe est activée via l'attribut properties .

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-twisty/index.html b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-twisty/index.html new file mode 100644 index 0000000000..b863bca3ff --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/_doublecolon_-moz-tree-twisty/index.html @@ -0,0 +1,35 @@ +--- +title: ':-moz-tree-twisty' +slug: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-twisty' +tags: + - CSS + - Non-standard + - Pseudo-classe + - Reference +translation_of: 'Mozilla/Gecko/Chrome/CSS/::-moz-tree-twisty' +--- +
{{CSSRef}}{{Non-standard_header}}
+ +

Cette pseudo-classe est activée via l'attribut properties .

+ +

Éléments XUL associés

+ + + +

Propriétés associées

+ + + +

Spécifications

+ +

Cette pseudo-classe est une pseudo-classe propriétaire liée à Gecko/Mozilla et ne fait partie d'aucune spécification.

diff --git a/files/fr/mozilla/gecko/chrome/css/index.html b/files/fr/mozilla/gecko/chrome/css/index.html new file mode 100644 index 0000000000..1edf837046 --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/css/index.html @@ -0,0 +1,25 @@ +--- +title: Chrome-only CSS reference +slug: Mozilla/Gecko/Chrome/CSS +tags: + - Aperçu + - CSS + - Gecko + - Mozilla + - Non-standard + - Reference +translation_of: Mozilla/Gecko/Chrome/CSS +--- +
{{CSSRef}}
+ +

Cette page liste les propriétés CSS uniquement accessible depuis le code du chrome de Gecko.

+ +

{{SubpagesWithSummaries}}

+ +

Voir aussi

+ + diff --git a/files/fr/mozilla/gecko/chrome/index.html b/files/fr/mozilla/gecko/chrome/index.html new file mode 100644 index 0000000000..6f5de4f5ea --- /dev/null +++ b/files/fr/mozilla/gecko/chrome/index.html @@ -0,0 +1,15 @@ +--- +title: Gecko Chrome +slug: Mozilla/Gecko/Chrome +tags: + - Aperçu + - Chrome + - Gecko + - Mozilla +translation_of: Mozilla/Gecko/Chrome +--- +
{{FirefoxSidebar}}
+ +
Cette page contient des informations spécifiques au code de Gecko responsable du "chrome" (les éléments de l'interface utilisateur).
+ +

{{SubpagesWithSummaries}}

diff --git a/files/fr/mozilla/gecko/faq/index.html b/files/fr/mozilla/gecko/faq/index.html new file mode 100644 index 0000000000..be9fbe5bd8 --- /dev/null +++ b/files/fr/mozilla/gecko/faq/index.html @@ -0,0 +1,201 @@ +--- +title: Gecko FAQ +slug: Mozilla/Gecko/FAQ +translation_of: Gecko/FAQ +--- +

Qu'est-ce que Gecko?

+ +

Gecko est un moteur open source de rendu web supportant différents standards d'internet comme le HTML, le CSS, le DOM, XML, javascript et d'autres standards encore.

+ +

Gecko est utilisé par de nombreux navigateurs internet, avec bien entendu Mozilla Firefox, mais aussi SeaMonkey, Camino. Gecko est en développement constant par les développeurs de Mozilla. Gecko est le nom final du moteur, il s'appelait aussi "Raptor" et "NGLayout"; mais le nom final du moteur a été choisi suite à un litige.

+ +

Pour plus d'informations, visitez l'article Gecko (moteur de rendu) sur Wikipedia.

+ +

Qu'est-ce qu'un moteur de rendu?

+ +

Un moteur de rendu va aller traduire le contenu des fichiers (les fichiers pouvant être une page internet en HTML, XML, des images...) et s'occupe de formater les informations contenus dans les fichiers, généralement le HTML, qui décrivent l'emplacement des textes, des images etc... afin de faire affiché l'information comme le voulait le webmaster. Il dessine la page web dans la zone de rendu de la fenêtre du navigateur.

+ +

Ainsi officiellement, un moteur de rendu définie la politique de placement pour un docuement et fait la mise en page. Gecko est un moteur de rendu trés rapide. Il offre la possibilité de parser de nombreux types de docuements (HTML, XML, SVG, etc...). Il est capable de donné un rendu avancé en incluant les compositions et les transformations. Il supporte aussi le javascript et les plugins.

+ +

Gecko est si rapide et puissant qu'il peut être utiliser pour créer des interfaces utilisateurs pour certaines applications ("chrome").  En d'autres termes, Gecko ne fait pas seulement que affiché le contenu d'un document, il peut aussi être utiliser pour dessiner des barres de défilement, des menus à l'écran. Pour plus d'information, reportez-vous à la documentation sur XUL.

+ +

How is a layout engine like Gecko different from a Web browser?

+ +

Gecko fournit la base nécessaire pour afficher l'information à l'écran, en incluant un moteur de rendu ainsi qu'un ensemble complémentaire de composants du navigateur. Cependant, Gecko ne supporte pas tous les composants aux côtés d'autres modules d'interface dans une application cohérente (y compris les menus, les barres d'outils, etc...) tel que Firefox.

+ +

La fondation Mozilla assemble les composants nécessaires dans ses logiciels, comme Firefox, Thunderbird, SeaMonkey, Camino, qui sont disponibles au téléchargement sur le site mozilla.org. Netscape a publié sa propre version du navigateur sous la marque Netscape Navigator. D'autres compagnies crée aussi leur propre logiciel et matériel qui utilisent Gecko. Voir la page recensant une liste de logiciel dans lequel Gecko est utilisé via XULRunner.

+ +

Les éditeurs tiers comme les éditeurs de logiciels et fournisseurs de matériels vont choisir les composants qu'ils souhaitent utiliser dans leurs logiciels ou matériels. Certains composants du navigateur ne sont pas fournis dans les fonctionnalités de Gecko, comme les marque page, l'historique de navigation, les faboris.... Cependant, la source de tous ces composants sont disponibles au téléchargement sur le portail mozilla.org.

+ +

Why was Gecko built?

+ +

The original Mozilla browser, first released as Navigator 1.0, was developed rapidly by a small team that was passionate about creating the next killer app, and they succeeded. Now that the web has evolved, a new generation layout engine was needed upon which future products could be built. Gecko enables a pioneering new class of dynamic content that is more interactive and offers greater presentation control to Web developers, using open and recommended Internet standards instead of proprietary APIs. You are encouraged to join this team by getting involved.

+ +

How is mozilla.org using Gecko?

+ +

mozilla.org will assemble the Gecko layout engine and other browser components into the Mozilla browser application.

+ +

How does Mozilla use Gecko?

+ +

Gecko lies at the heart of Mozilla and Firefox browsers, as well as others, powering all of the individual components. Gecko technologies will also power the display of the mozilla.com portal site, speedily delivering more exciting content and services. Gecko's architecture will serve Mozilla well into the future, enabling faster time to market, more innovation, less costly development, easier distribution and updating, and better cross platform support.

+ +

How can other companies and organizations use Gecko?

+ +

Because Gecko is small, lightweight, and open source, other companies and organizations can easily reuse it. Many hardware vendors are creating devices with network access and wish to include web browsing functionality. Likewise, many software developers want to include Web browsing capability in their applications, but don't want to independently develop browser software. These developers can pick and choose the browser components they want from among those that Gecko offers, and package these components alongside their own within their finished products.

+ +

Which open standards is the Gecko development project working to support, and to what extent does it support them?

+ +

By the end of calendar year 2000, Gecko is expected to support the following recommended open Internet standards fully except for the areas noted below and open bugs documented in Bugzilla:

+ + + +

Does "full support" mean that Gecko has zero bugs today or will have zero bugs at some point in the future?

+ +

Of course not. As Robert O'Callahan notes in {{ Bug(25707) }}, "Full HTML4/CSS1 compliance can't mean '100% bug free'. If it does, no-one will ever ship a fully compliant browser."

+ +

Because web pages can be arbitrarily long and complex and have arbitrarily deeply nested markup, it will always be possible to construct web pages that do not display in a given browser the way the specifications would recommend. So long as QA testing and test case development continues, there will always be known bugs at any given point in time in the open-source Gecko codebase, and it follows that every commercial product that has ever shipped and ever will ship based on Gecko will have known bugs at the time of its release. (The same principle of course applies to other browser engine development projects and products based upon them as well.)

+ +

Known bugs in the open-source Gecko codebase are documented in Bugzilla. Here are some links to lists of reported bugs related to the standards mentioned above; be aware that these raw lists of open in-process bugs will inevitably include some duplicate, out of date, unreproducible, invalid, and incorrectly tagged reports:

+ +
The links themselves are probably outdated too.
+ + + +

For information about the known bugs of a specific commercial product based on Gecko, see that product's release notes.

+ +

How does Gecko format XML documents?

+ +

Gecko supports the use of CSS and XSLT to format XML documents.

+ +

For XML documents without associated CSS or XSLT, Gecko displays the pretty-printed source of the document.

+ +

How does Gecko help content developers?

+ +

Content developers are sick and tired of developing and testing every single web page multiple times in order to support the different, incompatible, proprietary DOMs of browsers from different vendors. They have been demanding that all vendors fully support the open standards listed above so that they can

+ +
    +
  1. have a rich, powerful formatting system and object model at their disposal, and
    2. +
  2. "write once, view anywhere."
    3. +
+ +

Gecko's robust support for these standards makes Gecko the platform of choice for web content and web application developers worldwide.

+ +

Are Gecko's APIs based on ActiveX? COM? JavaBeans?

+ +

Gecko is reusable on all platforms thanks to XPCOM, a subset of COM that works across platforms. COM, developed by Digital and later adopted by Microsoft, is the de facto standard for modular interfaces on Windows platforms.

+ +

Additionally, on the Windows platform, Gecko's XPCOM interfaces are wrapped in an ActiveX control that VB developers can utilize (ActiveX wrappers are not available on other platforms because ActiveX is a Windows-only technology).

+ +

A JavaBean wrapper is not currently under development, but there is nothing in Gecko's architecture that precludes such development in the future. Source code and documentation for these interfaces are available through mozilla.org.

+ +

For future embedding API plans, see {{ interwiki('wikimo', 'Mozilla_2:Embedding_APIs', 'wikimo:Mozilla 2:Embedding APIs') }}.

+ +

Are Gecko's APIs compatible with Microsoft's Trident APIs?

+ +

Gecko's XPCOM interfaces are different than Microsoft's. The most important differences between the two models involve reflection of the Document Object Model (DOM) in the interfaces.

+ +

Microsoft's Trident interfaces reflect the DOM in a proprietary API, whereas Gecko exposes the DOM according to the W3C's recommended standard. Other incompatibilities exist. Adam Lock created a partial compatibility layer that may enable developers to more easily migrate from Microsoft's engine to the Gecko engine.

+ +

Which platforms does Gecko run on?

+ +

Gecko runs today on Win32 (Windows XP Service Pack 2, Windows Vista, Windows 7, Windows 8, Windows 8.1), Mac OS X 10.5 and later, and Linux. OEMs and contributors from the Net participating in mozilla.org are porting Gecko to other platforms. Such porting efforts are underway for Solaris, HP/UX, AIX, Irix, OS/2, OpenVMS, BeOS, and Amiga, among others.

+ +

Older versions of Gecko supported earlier versions of Win32 and Mac OS X.

+ +

What are the components of Gecko?

+ +

Gecko includes the following components:

+ + + +
+

Original Document Information

+ + +
+ +

{{ languages( { "ja": "ja/Gecko_FAQ", "zh-cn": "cn/Gecko_FAQ" } ) }}

diff --git a/files/fr/mozilla/gecko/gecko_embedding_basics/index.html b/files/fr/mozilla/gecko/gecko_embedding_basics/index.html new file mode 100644 index 0000000000..2a116f5d88 --- /dev/null +++ b/files/fr/mozilla/gecko/gecko_embedding_basics/index.html @@ -0,0 +1,403 @@ +--- +title: Les bases de Gecko embarqués +slug: Mozilla/Gecko/Gecko_Embedding_Basics +translation_of: Mozilla/Gecko/Gecko_Embedding_Basics +--- +

{{ Outdated("It was last updated a very long time ago.") }}

+ +
+
Compte tenu de l'importance croissante du Web comme source d'information, de divertissement, et la connectivité individuelle, la possibilité d'accéder et d'afficher des données enregistrées au format HTML devient de plus en plus important pour une grande variété d'applications logicielles par ailleurs très diverses. Que ce soit pour un simple visualiseur HTML ou pour créer un navigateur web à part entière, la capacité d'analyser et d'afficher des documents de type HTML est une fonction de plus en plus importante dans de nombreuses situations. Pour le développeur d'applications, le problème est de savoir comment mettre en œuvre cette fonctionnalité cruciale d'une manière qui minimise encore le temps de développement qui va permettre de créer un produit agile et robuste. Intégrer Gecko, le moteur de rendu au cœur des navigateurs Netscape et Mozilla, est une solution pour ce problème.
+ +
 
+
+ +

Pourquoi Gecko

+ +

Intégrer Gecko est un choix pertinent. Il est rapide, robuste, et respecte les standards du web. Chez Mozilla et Netscape, il a été largement diffusé et abondamment testé.

+ +

Il est Open-Source. Contrairement à d'autres choix d'intégration, tout le code source de Gecko est librement disponible et personnalisable. Vous pouvez le bricoler autant que vous le voulez sans limite. Pourtant, selon la licence choisie, il est possible d'utiliser Gecko comme un composant dans un produit commercial et propriétaire.

+ +

Comme Gecko est associé avec le projet Mozilla, il y a beaucoup de ressources disponibles pour aider à son intégration. Le site officiel de Mozilla a un espace dédié aux projets d'intégration. Il y a un groupe de discussion, mozilla.dev.embedding, qui met l'accent sur l'échange d'informations entre les intégrateurs, ainsi qu'à un certain nombre d'autres groupes de discussion connexes. On peut accéder à un index croisé complet de la base de code et il est simple d'ajouter du code, de suivre ses progrès ou d'aider à corriger des bogues via la base de données de bugs Bugzilla.

+ +

De plus, Gecko a été architecturé dès le commencement pour être multi-plateforme. La version de mozilla.org, tourne aussi bien sur  Wintel, Mac OS 9.0, OS X et Linux et il existe des portages faits par des tiers sur nombre d'autres plateformes.

+ +

Enfin, la license Gecko is gratuite, même si l'application finale est un produit commercial propriétaire. La plupart du temps, toute modification apportée au code originellement fourni par Mozilla (mais pas le code dans lequel il est intégré) doit revenir à la communauté, ce même code originel doit être rendu disponible aux utilisateurs de l'application (souvent via un lien sur le site web de mozilla.org), et l'application doit indiquer de manière évidente (Par exemple un logo sur la boîte ou sur la page APropos) que le produit intègre Gecko. La description exacte des licenses possibles est visible sur Mozilla & Netscape Public Licenses, qui est la seule source légale des information de license.

+ +

Ce dont vous avez besoin pour embarquer

+ +

Une fois que vous avez décidé d'intégrer, il y a trois étapes à suivre. Premierement, vous devez vous procurer le code. Ensuite, vous devez comprendre les quelques technologies spécifiques qui sont utilisées pour manipuler le code de base de Gecko. Enfin, vous devez décider quelles fonctionalités vous pouriez ajouter. Cette section vous guidera dans ces étapes.

+ +

Vous procurer le code

+ +

Actuellement, le meilleur moyen d'obtenir les fichiers dont vous avez besoin pour intégrer Gecko consiste à télécharcher et compiler les source de Mozilla dans leur totalité. C'est en fait un processu assez simple. Les liens vers les instructions completes sont disponibles dans la section Télécharger le Code source de Mozilla. Une seconde méthode, composant par composant, est en cours de développement, mais est encore au niveau béta. Vous pouvez trouver des informations sur ce projet dans la section Compilation. De plus, nous développons un Environnement d'exécution Gecko (Gecko Runtime Environment ou GRE), de maniere à supporter plusieurs outils batis sur des composants Mozilla tout en n'utilisant qu'un seul ensemble de bibliotheque. (Si vous avez l'intention de travailler composant par composant, soyez particulierement attentifs aux probleme de versions et de compatibilité des binaires. Pour vous aidez sur ce point, regardez la section Réutilisation des composants XPCOM.)

+ +

Déjà, vous devz vous procurer quelques outils (en bref, un compilateur, une distribution Perl, et quelaues utilitaires génériques). Ensuite, vous devez les installer sur votre ordinateur. Apres quoi, vous devez télécharger la source. En supposant que vous allez télécharger l'ensemble de l'arborescence, il y a deux manieres de procéder: vous pouvez télécharger en FTP une archive contenant l'ensemble de l'arborescence (c'est la maniere la plus simple, et la plus sure de compiler, mais elle peut contenir une version dépourvue des modifications les plus récentes) ou vous pouvez utiliser CVS pour etre certain que vous téléchargezla version la plus récente. Une fois que vous avez l'arborescence et les outils, et que votre environement est corectement installé, il ne vous reste qu'à exécuter le makefile. Vous pouvew trouver des instructions détaillées pour chacune des plateformes supportées. 

+ +

Une fois la source compilée, rendez-vous dans le dossier mozilla/embedding/config. Vous y trouverez des fichiers de démonstration (chacun d'entre eux porte un nom commencant par "basebrowser") intégrables sur chacune des plateformes. Ce sont uniquement des exemples, peut-etre inadaptés à votre besoin particulier, mais ce sont un bon moyen de débuter. Il y a aussi des exemples de projets d'intégration pour chacune des plateforme que vous pouvez utiliser en tant que modele. Voir Intégration : Exemples de Mozilla et projets externes. 

+ +

Understanding the Coding Environment

+ +

Mozilla was set up from the beginning to support design and development across multiple platforms and programming languages. To this end, a number of in-house programming technologies were developed, all based around an ideal of object encapsulation. Embedding Gecko necessarily implies acquiring a working knowledge of these technologies, including XPCOM, XPIDL, XPConnect, special string classes, and, optionally, XUL. The following provides a brief introduction to them. More information can be found at the mozilla.org site.

+ +

XPCOM

+ +

The most important of the Mozilla technologies is XPCOM, the Cross-Platform Component Object Model. XPCOM provides a framework which manages the creation, ownership, and deletion of objects and other data throughout Mozilla. If you have used MSCOM, you will recognize certain basic similarities. But there are also significant differences -- XPCOM is cross-platform and designed to run largely in a single thread -- and the two are not at this time compatible.

+ +
The interface
+ +

At the core of XPCOM is the concept of the interface. An interface is simply a description of a set of methods, attributes, and related constants all associated with a particular functionality: it is completely distinct from the class that implements those things. The interface serves as a kind of contract: any object that supports a particular interface guarantees that it will perform the services described in it. To keep the interface as language neutral as possible, it is written in a special language, the Interface Definition Language, or IDL. Interface files are often referred to as .idl files. In addition to specifying the functionality of the interface, these files also carry the interface's IID, its globally unique identifying number.

+ +

Much of the communication within Gecko takes place in terms of these abstract structures (by convention, their names follow the form nsISomething).

+ +
//this
+void ProcessSample(nsISample* aSample) {
+	aSample->Poke("Hello");
+//not this
+void ProcessSample(nsSampleImpl* aSample) {
+	aSample->Poke("hello");
+
+ +
@status FROZEN
+ +

XPCOM's level of abstraction produces great flexibility in the system. Implementations are free to change as needed. But, to work, the interfaces themselves must remain fixed. Throughout Mozilla's initial design and development period, interfaces have been somewhat fluid, but as the project has matured, more and more of the interfaces have been marked FROZEN. Any interface so marked is guaranteed not to change in the future.

+ +

Most of the main interfaces key to the embedding effort are now frozen, but it's always a good idea to check before using any interface. An interface's status is listed in the .idl file's comments. A frozen interface is marked @status FROZEN. You can search for frozen interfaces by using the Mozilla cross referencing tool. Until it is frozen, an interface may change at any time. For more information on the freezing process, see the embedding project page.

+ +

Once an interface has been frozen, it is added to the Gecko Embedding API Reference.

+ +
nsISupports
+ +

A single object can support more than one interface. In fact, essentially all objects support at least two interfaces -- a minimum of one that does something specifically useful and one, nsISupports, that serves a more general purpose. In a sense, nsISupports is the progenitor of all XPCOM interfaces. All interfaces inherit from it, most directly so. It serves two main functions: runtime type discovery and object lifetime management. It is functionally identical to IUnknown in MSCOM.

+ +

Since an object can support multiple interfaces, it's possible to have a pointer to one interface and want to know whether that same object also supports a different interface whose functionality you might also need. The first nsISupports method, QueryInterface(), does exactly that: it asks, in effect, "I know that this object is of type A (supports interface A) but is it also of type B (supports interface B)?"

+ +

If it is (or does), QueryInterface() returns to the caller a pointer bound to the newly requested interface.

+ +
void ProcessSample(nsISample* aSample) {
+	nsIExample *example;
+	nsresult rv;
+	rv = aSample->QueryInterface(NS_GET_IID(nsIExample),(void **)&example);
+	if (NS_SUCCEEDED(rv)) {
+		example->DoSomeOperation();
+		NS_RELEASE(example); // using a macro to call Release
+	}
+}
+
+ +

Because XPCOM uses an indirect method, the Component Manager, to actually instantiate objects, and because multiple pointers to the same object -- often bound to different interfaces -- can exist, it can quickly become very difficult for callers to keep accurate track of all of the objects to which those pointers point. Objects could be kept around in memory longer than they need to be, causing leaks, or objects could be deleted prematurely, causing dangling pointers. The other two methods in nsISupports, AddRef() and Release(), are designed to deal with this issue. Every time a pointer is given out AddRef() must be called on the object, incrementing an internal counter. Every time a pointer is released, Release() must be called, which decrements that same counter. When the counter reaches zero, there are no pointers to the object remaining and the object can safely delete itself. Control of the object's lifetime stays within the object itself. See below for information on XPCOM's "smart" pointer, nsCOMPtr, a utility which helps automate this process.

+ +
Object creation
+ +

The instantiation of objects is also an indirect process in XPCOM. Just as interfaces have a globally unique ID number (the IID), XPCOM classes are assigned their own GUIDs, the CID. In addition, they are also often given a text-based ID, called a contract ID. One or the other of these IDs is passed to a method on a persistent XPCOM component, the Component Manager, which actually creates the object. When a new library of classes (called a module in XPCOM) is first introduced into the system, it must register itself with the Component Manager, which maintains a registry that maps classes (with their IDs) to the libraries in which they reside.

+ +

A limited number of persistent services, supplied by singleton objects, are created and controlled by a companion to the Component Manager, the Service Manager. The Component Manager itself is an example of such a persistent service.

+ +
Summing up
+ +

Functionality in XPCOM is described by abstract interfaces, and most communication among parts of the system takes place in terms of those interfaces. The underlying objects that implement the interfaces, on the other hand, are created indirectly by the Component Manager based on a cross-indexed registry that it maintains.

+ +

One functionality shared by all interfaces is the ability to query the underlying object at runtime to see if also implements other interfaces. In theory an interface is fixed and unchangeable, but at this stage in the Mozilla codebase, only interfaces that have been declared FROZEN are guaranteed not to change significantly. Object lifetime management takes place inside the object itself through an internal counter that keeps track of the number of pointers to the object that have been added or released. The client's only responsibility is to increment and decrement the counter. When the internal counter reaches zero, the object deletes itself.

+ +
nsCOMPtr
+ +

Sometimes, however, even remembering to call AddRef() and Release() at the right times can be difficult. To make this process easier and more reliable, XPCOM has a built-in "smart" pointer, nsCOMPtr. This pointer takes care of calling AddRef() and Release() for you. Using nsCOMPtr whenever possible will make your code cleaner and more efficient. For more information on the smart pointer, see "The Complete nsCOMPtr User's Manual".

+ +

Mozilla actually provides a large number of built-in macros (by convention, written in all caps in the code) and utilities like nsCOMPtr that can make the entire process of coding with XPCOM easier. Many of these can be found in the following files: nsCom.h, nsDebug.h, nsError.h, nsIServiceManager.h, and nsISupportsUtils.h. Mozilla also supplies other development tools for tracking memory usage and the like. More information on these can be found at http://www.mozilla.org/performance/

+ +
For more information
+ +

More information on XPCOM in general can be found at XPCOM. For an overview of creating XPCOM components, see Chapter 8 of O'Reilly's Creating Applications with Mozilla. There is also a new book completely devoted to this topic, Creating XPCOM Components. A fuller explanation of some of the underlying logic to COM systems can be found in the early chapters of Essential COM by Don Box. While it focuses on MSCOM in particular, the book does provide an excellent background on some of the core rationales for using such an object model.

+ +

XPIDL

+ +

Interfaces are abstract classes written in XPIDL, the Cross Platform Interface Definition Language. Yet to be useful the functionality promised in those interfaces must be implemented in some regular programming language. Facilitating this is the job of the XPIDL compiler. Once an interface is defined in an .idl file, it can be processed by the XPIDL compiler.

+ +

The compiler can be set to output a number of things, but generally the output is two-fold: a C++ .h file that includes a commented out template for a full C++ implementation of the interface and an XPT file that contains type library information which works with XPConnect to make the interface available to JavaScript. More information on the syntax of XPIDL (a simple C-like language) and the use of the compiler is available.

+ +

XPConnect and XPT files

+ +

XPConnect is an XPCOM module that allows code written in JavaScript to access and manipulate XPCOM components written in C++ and vice versa. By means of XPConnect, components on either side of an XPCOM interface do not, in general, need to know or care about which of these languages the object on the other side is implemented in.

+ +

When an interface is run through the XPIDL compiler, it produces an XPT or type library file. Because XPconnect uses the information in this file to implement transparent communication between C++ objects and JavaScript objects across XPCOM interfaces, it is important to make sure they are generated and included with your code even if you are developing exclusively in C++. Not only is a substantial part of the browser, in fact, implemented in JS, it is possible that in the future someone may wish to use JS-based code to interact with whatever components you create .

+ +

As is from Mozilla, XPConnect currently facilitates interoperability between C++ and JS. Modules to extend it to allow access from other languages (including Python) are under independent development.

+ +

String classes

+ +

Web browsing typically involves a large amount of string manipulation. Mozilla has developed a hierarchy of C++ classes to facilitate such manipulation and to render it efficient and quick. To make communication among objects simpler and more error free, Mozilla uses interfaces, which are, in essence, abstract classes. The string hierarchy is also headed up by a set of abstract classes, nsAString, nsASingleFragmentString, and nsAFlatString, and for the same reasons. (These refer to double-byte strings. There is a parallel hierarchy topped with nsACString, etc., that refers to single-byte strings.) nsAString guarantees only a string of characters. nsASingleFragmentString guarantees that the characters will be stored in a single buffer. nsAFlatString guarantees that the characters will be stored in a single null-terminated buffer. While there are underlying concrete classes, in general it is best to use the most abstract type possible in a given situation. For example, concantenation can be done virtually, through the use of pointers, resulting in an nsAString that can be used like any other string. This saves the allocating and copying that would otherwise have to be done. For more information, see "XPCOM string guide".

+ +

XUL/XBL

+ +

Use of this final Mozilla technology is optional, depending on how you decide to create the user interface for your application. XUL is Mozilla's highly flexible XML UI Language. It provides a number of largely platform independent widgets from which to construct a UI. Netscape and Mozilla both use XUL for their interfaces, but not all embedders choose to use it. XBL or the eXtensible Binding Language allows you to attach behaviors to XUL's XML elements. More information on XUL can be found at XUL Programmer's Reference and on XBL at XBL:XBL_1.0_Reference. There is also a wealth of good information on XUL at XULPlanet.

+ +

Choosing Additional Functionalities

+ +

As of this writing (8/19/02), Gecko is a partially modularized rendering engine. Some functionalities beyond basic browsing are always embedded with Gecko, and, as a result of certain architectural decisions, always will be; some are at present always embedded with Gecko, but may, at some point in the future, be separable; and some are now available purely as options. The following table describes the present status of these additional functionalities:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
FunctionsStatus NowStatus in Future
FTP supportOptional 
HTTPS supportOptional 
International character supportOptional 
XUL supportRequiredProbably optional
Network supportRequiredMaybe optional
JavaScript supportRequiredMaybe optional
CSS supportRequiredAlways required
DOM supportRequiredProbably always
XML supportRequiredProbably always
+ +

At this time embedding Mozilla's editor along with the rendering engine Gecko is an uncertain proposion, although the situation continues to improve. For more information on the status of the embeddable editor, see http://www.mozilla.org/editor/Editor...ing_Guide.html.

+ +

What Gecko Provides

+ +

The following is a description of some of the interfaces most commonly used in embedding Gecko. It is by no means an exhaustive list of the available interfaces. The interfaces in this section are on classes provided by Mozilla. There is also a set of interfaces for which Gecko expects the embedder to provide the implementation. A sample of those are covered in the next section.

+ +

Initialization and Teardown

+ +

There are two C++ only functions which serve to initalize and terminate Gecko. The initialization function (NS_InitEmbedding) must be called before attempting to use Gecko. It ensures XPCOM is started, creates the component registry if necessary, and starts global services. The shutdown function (NS_TermEmbedding) terminates the Gecko embedding layer, ensuring that global services are unloaded, files are closed and XPCOM is shut down.

+ +

nsIWebBrowser

+ +

Use of this interface during initialization allows embedders to associate a new nsWebBrowser instance (an object representing the "client-area" of a typical browser window) with the embedder's chrome and to register any listeners. The interface may also be used at runtime to obtain the content DOM window and from that the rest of the DOM.

+ +

The XULPlanet nsWebBrowser reference also has a lot of useful information on this class.

+ +

nsIWebBrowserSetup

+ +

This interface is used to set basic properties (like whether image loading will be allowed) before the browser window is open.

+ +

nsIWebNavigation

+ +

The nsIWebNavigation interface is used to load URIs into the web browser instance and provide access to session history capabilities - such as back and forward. As of June 6, 2006, this interface is not yet frozen.

+ +

nsIWebBrowserPersist

+ +

The nsIWebBrowserPersist interface allows a URI to be saved to file. As of June 6, 2006, this interface is not yet frozen.

+ +

nsIBaseWindow

+ +

The nsIBaseWindow interface describes a generic window and basic operations (size, position, window title retrieval, etc.) that can be performed on it. As of June 6, 2006, this interface is not yet frozen.

+ +

nsISHistory

+ +

The nsISHistory interface provides access to session history information and allows that information to be purged.

+ +

nsIWebBrowserFind

+ +

The nsIWebBrowserFind interface controls the setup and execution of text searches in the browser window.

+ +

What You Provide

+ +

The following is a description of some of the more common embedder-provided interfaces used in embedding Gecko. It is by no means an exhaustive list of the available interfaces.

+ +

nsIWebBrowserChrome

+ +

The nsIWebBrowserChrome interface corresponds to the top-level, outermost window containing an embedded Gecko web browser. You associate it with the WebBrowser through the nsIWebBrowser interface. It provides control over window setup and whether or not the window is modal. It must be implemented.

+ +

nsIEmbeddingSiteWindow

+ +

The nsIEmbeddingSiteWindow interface provides Gecko with the means to call up to the host to resize the window, hide or show it and set/get its title. It must be implemented.

+ +

nsIWebProgressListener

+ +

The nsIWebProgressListener interface provides information on the progress of loading documents. It is added to the WebBrowser through the nsIWebBrowser interface. It must be implemented. As of this writing (8/19/02), it is not frozen.

+ +

nsISHistoryListener

+ +

The nsISHistoryListener interface is implemented by embedders who wish to receive notifications about activities in session history. A history listener is notified when pages are added, removed and loaded from session history. It is associated with Gecko through the nsIWebBrowser interface. Implementation is optional.

+ +

nsIContextMenuListener

+ +

The nsIContextMenuListener interface is implemented by embedders who wish to receive notifications for context menu events, i.e. generated by a user right-mouse clicking on a link. It should be implemented on the web browser chrome object associated with the window for which notifications are required. When a context menu event occurs, the browser will call this interface if present. Implementation is optional.

+ +

nsIPromptService

+ +

The nsIPromptServices interface allows the embedder to override Mozilla's standard prompts: alerts, dialog boxes, and check boxes and so forth. The class that implements these embedder specific prompts must be registered with the Component Manager using the same CID and contract ID that the Mozilla standard prompt service normally uses. Implementation is optional. As of this writing (8/19/02), this interface is not frozen.

+ +

Common Embedding Tasks

+ +

The following is a series of code snippets (taken from MFCEmbed, the Windows based embedding Gecko sample) which demonstrate very briefly implementation associated with common embedding tasks. MFCEmbed code was deleted from the current repository as the code quality was not very high and it did not use good embedding APIs. If you need a MFC embedding example, maybe take a look at the K-Meleon source. There are also Linux- and Mac OS-based examples, see http://mxr.mozilla.org/mozilla-central/source/embedding/tests/ for a list of examples.

+ +

Gecko setup

+ +

The Gecko embedding layer must be initialized before you can use Gecko. This ensures XPCOM is started, creates the component registry if necessary, and starts global services. There is an equivalent shutdown procedure.

+ +

Note that the embedding layer is started up by passing it two parameters. The first indicates where the executable is stored on the file system (nsnull indicates the working directory). The second indicates the file location object "provider" that specifies to Gecko where to find profiles, the component registry preferences, and so on.

+ +
nsresult rv;
+rv = NS_InitEmbedding(nsnull, provider);
+if(NS_FAILED(rv))
+{
+ASSERT(FALSE);
+return FALSE;
+}
+
+ +

Creating a browser instance

+ +

The embedder-provided BrowserView object calls its method CreateBrowser(). Each browser object (a webbrowser) represents a single browser window. Notice the utility directive do_CreateInstance() and the use of macros.

+ +
//Create an instance of the Mozilla embeddable browser
+
+HRESULT CBrowserView::CreateBrowser()
+{
+// Create a web shell
+nsresult rv;
+mWebBrowser = do_CreateInstance(NS_WEBBROWSER_CONTRACTID, &rv);
+if(NS_FAILED(rv))
+return rv;
+
+ +

Once the nsWebBrowser object is created the application uses do_QueryInterface() to load a pointer to the nsIWebNavigation interface into the mWebNav member variable. This will be used later for web page navigation.

+ +
rv = NS_OK;
+mWebNav = do_QueryInterface(mWebBrowser, &rv);
+if(NS_FAILED(rv))
+return rv;
+
+ +

Next the embedder-provided CBrowserImpl object is created. Gecko requires that some interfaces be implemented by the embedder so that Gecko can communicate with the embedding application. See the What You Provide Section. In the sample, CBrowserImpl is the object that implements those required interfaces. It will be passed into the SetContainerWindow() call below.

+ +
mpBrowserImpl = new CBrowserImpl();
+if(mpBrowserImpl == nsnull)
+return NS_ERROR_OUT_OF_MEMORY;
+
+ +

The mWebBrowser interface pointer is then passed to the CBrowserImpl object via its Init() method. A second pointer to the platform specific BrowserFrameGlue interface is also passed in and saved. The BrowserFrameGlue pointer allows CBrowserImpl to call methods to update status bars, progress bars, and so forth.

+ +
mpBrowserImpl->Init(mpBrowserFrameGlue, mWebBrowser);
+mpBrowserImpl->AddRef();
+
+ +

Next the embedder-supplied chrome object is associated with the webbrowser. Note the use of an nsCOMPtr.

+ +
mWebBrowser->SetContainerWindow
+	(NS_STATIC_CAST(nsIWebBrowserChrome*, mpBrowserImpl));
+nsCOMPtr<nsIWebBrowserSetup>setup(do_QueryInterface(mWebBrowser));
+if (setup)
+	setup->SetProperty(nsIWebBrowserSetup::SETUP_IS_CHROME_WRAPPER,PR_TRUE);
+
+ +

Then, the real webbrowser window is created.

+ +
rv = NS_OK;
+mBaseWindow = do_QueryInterface(mWebBrowser, &rv);
+if(NS_FAILED(rv))
+return rv;
+
+ +

Binding a window

+ +

Basic location information is passed in.

+ +
RECT rcLocation;
+GetClientRect(&rcLocation);
+if(IsRectEmpty(&rcLocation))
+{
+	rcLocation.bottom++;
+	rcLocation.top++;
+}
+rv = mBaseWindow->InitWindow(nsNativeWidget(m_hWnd),
+		nsnull,0, 0, rcLocation.right - rcLocation.left,
+		rcLocation.bottom - rcLocation.top);
+rv = mBaseWindow->Create();
+
+ +

Note the m_hWnd passed into the call above to InitWindow(). (CBrowserView inherits the m_hWnd from CWnd). This m_hWnd will be used as the parent window by the embeddable browser.

+ +

Adding a listener

+ +

The BrowserImpl object is added as an nsIWebProgressListener. It will now receive progress messages. These callbacks will be used to update the status/progress bars.

+ +
nsWeakPtr weakling
+	(dont_AddRef(NS_GetWeakReference(NS_STATIC_CAST(nsIWebProgressListener*,
+			mpBrowserImpl))));
+void mWebBrowser->AddWebBrowserListener(weakling, NS_GET_IID(nsIWebProgressListener));
+
+ +

Finally the webbrowser window is shown.

+ +
mBaseWindow->SetVisibility(PR_TRUE);
+
+ +

Using session history to navigate

+ +

The pointer to nsIWebNavigation saved above is used to move back through session history.

+ +
void CBrowserView::OnNavBack()
+{
+if(mWebNav)
+	mWebNav->GoBack();
+}
+
+ +

Appendix: Data Flow Inside Gecko

+ +

While it isn't strictly necessary for embedders to understand how Gecko does what it does, a brief overview of the main structures involved as Gecko puts bits on a display may be helpful.

+ +

Image:EmbeddingBasicsa.gif

+ +

HTML data comes into Gecko either from the network or a local source. The first thing that happens is that it is parsed, using Gecko's own HTML parser. Then the Content Model arranges this parsed data into a large tree. The tree is also known as the "Document" and its structure is based on the W3C Document Object Model. Any use of DOM APIs manipulates the data in the Content Model.

+ +

Next the data is put into frames using CSS and the Frame Constructor. A frame in this sense (which is not the same thing as an HTML frame) is basically an abstract box within which a DOM element will be displayed. This process produces a Frame Tree, which, like the Content Model, is a tree of data, but this time focused not on the logical relationship among the elements but on the underlying calculations needed to display the data. In the beginning a frame has no size. Using CSS rules specifying how the elements of the DOM should look when they are displayed, including information like font type or image size, the eventual size of each frame is calculated. Because the same data may need to be displayed in different ways -- to a monitor and to a printer, for example -- a particular Content Model may have more than one Frame Tree associated with it. In such a case, each individual Frame Tree would belong to a different "presentation" mode.

+ +

Calculations continue as new information flows into the system using a process called reflow. As information in the Frame Tree changes, the section of the Frame Tree involved is marked "dirty" by the Frame Constructor. Reflow repeatedly steps through the tree, processing every "dirty" item it encounters until all the items it encounters are "clean". Every item in the Frame Tree has a pointer back to its corresponding item in the Content Model. A change in the Content Model, say through using the DOM APIs to change an element from hidden to visible, produces an equivalent change in the Frame Tree. It's important to note that all of these operations are purely data manipulations. Painting to the display itself is not yet involved at this point.

+ +

The next stage is the View Manager. With a few small exceptions that have to do with prompting the Frame Constructor to load graphics, the View Manager is the first place in the process that accesses the native OS. Delaying OS access until this point both helps Gecko to run more quickly and makes cross-platform issues easier to deal with. The View Manger is the place where Gecko figures out where on the display the data will need to be drawn. It then tells the system that that area is "invalid" and needs to be repainted. The actual painting is managed by the gfx submodule, while other low-level system operations are run through the widget submodule, which handles things like platform specific event (mouse clicks and so forth) processing loops and accessing system defaults (colors, fonts, etc.) Both gfx and widget are system specific.

+ +

If you want to take a look at the code underlying these structures, the code for the Content Model can be found in /mozilla/content, for the Frame Constructor, CSS, and Reflow in /mozilla/layout, for the View Manager in /mozilla/view, and for the DOM APIs in /mozilla/dom.

+ +
+

Original Document Information

+ + +
+ +

{{ languages( { "ja": "ja/Gecko_Embedding_Basics" } ) }}

diff --git a/files/fr/mozilla/gecko/index.html b/files/fr/mozilla/gecko/index.html new file mode 100644 index 0000000000..fcd4a8e202 --- /dev/null +++ b/files/fr/mozilla/gecko/index.html @@ -0,0 +1,118 @@ +--- +title: Gecko +slug: Mozilla/Gecko +translation_of: Mozilla/Gecko +--- +

Gecko est le nom du moteur de rendu développé par la fondation Mozilla. Il s'appelait à l'origine NGLayout.

+ +

La fonction de Gecko est de lire le contenu Web tel que HTML, CSS, XUL et JavaScript, puis de le représenter sur l'écran de l'utilisateur ou à l'impression. Dans les applications basées sur XUL, Gecko est également utilisé pour afficher l'interface utilisateur de l'application.

+ +

Gecko est utilisé dans de nombreuses applications dont quelques navigateurs comme Firefox, la Suite Mozilla, Camino, etc. (Pour obtenir la liste complète, référez-vous à cet article de Wikipedia sur Gecko). Les produits utilisant la même version de Gecko ont un support identique des standards.

+ +

Le nom et le logo Gecko sont des marques de Netscape Communications Corporation, utilisés sous licence.

+ +

Les versions de Gecko

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Version de GeckoApplications basées sur cette version
Gecko 17.0 (en cours de développement)Firefox 17, SeaMonkey 2.14, Thunderbird 17
Gecko 16.0 (en cours de développement)Firefox 16, SeaMonkey 2.13, Thunderbird 16
Gecko 15.0 (en cours de développement)Firefox 15, SeaMonkey 2.12, Thunderbird 15
Gecko 14.0Firefox 14, SeaMonkey 2.11, Thunderbird 14
Gecko 13.0Firefox 13, SeaMonkey 2.10, Thunderbird 13
Gecko 12.0Firefox 12, SeaMonkey 2.9, Thunderbird 12
Gecko 11.0Firefox 11, SeaMonkey 2.8, Thunderbird 11
Gecko 10.0Firefox 10, SeaMonkey 2.7, Thunderbird 10
Gecko 9.0Firefox 9, SeaMonkey 2.6, Thunderbird 9
Gecko 8.0Firefox 8, SeaMonkey 2.5, Thunderbird 8
Gecko 7.0Firefox 7, SeaMonkey 2.4, Thunderbird 7
Gecko 6.0Firefox 6, SeaMonkey 2.3, Thunderbird 6
Gecko 5.0Firefox 5, SeaMonkey 2.2, Thunderbird 5
Gecko 2.0Firefox 4, SeaMonkey 2.1
Gecko 1.9.2Firefox 3.6, Thunderbird 3.1
Gecko 1.9.1Firefox 3.5, SeaMonkey 2.0, Thunderbird 3.0
Gecko 1.9.0Firefox 3
Gecko 1.8.1Firefox 2, SeaMonkey 1.1, Thunderbird 2.0
Gecko 1.8.0Firefox 1.5, SeaMonkey 1.0, Thunderbird 1.5
Gecko 1.7Firefox 1.0, Mozilla Suite 1.7, Nvu 1.0, Thunderbird 1.0
Les versions plus anciennes de Gecko correspondent aux versions de la Suite Mozilla
+ +
+

Ressources

+ + + +

{{ languages( { "de": "de/Gecko", "en": "en/Gecko", "es": "es/Gecko", "it": "it/Gecko", "ja": "ja/Gecko", "ko": "ko/Gecko", "pl": "pl/Gecko", "pt": "pt/Gecko", "zh-cn": "cn/Gecko" } ) }}

diff --git "a/files/fr/mozilla/gecko/mozilla_embarqu\303\251/api_overview/index.html" "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/api_overview/index.html" new file mode 100644 index 0000000000..bf0dbc85cf --- /dev/null +++ "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/api_overview/index.html" @@ -0,0 +1,422 @@ +--- +title: Vue d'ensemble des APIS embarquées de Mozilla +slug: Mozilla/Gecko/Mozilla_embarqué/API_overview +translation_of: Mozilla/Gecko/Embedding_Mozilla/API_overview +--- +

Introduction

+

The Mozilla Public API consists of a collection of services and components which are accessed via XPCOM interfaces. Mozilla's XPCOM layer consists of a component model (called XPCOM) and the infrastructure necessary to support dynamic registration, instantiation and manipulation of XPCOM components.

+

At the heart of XPCOM's implementation is the Service Manager and the Component Manager. Together, these two services provide a centralized point for gaining access to all of the public Mozilla interfaces.

+

The Service Manager exposes all of the available XPCOM services - each service represents a global object which provides some piece of functionality. The Component Manager allows new instances of registered XPCOM components to be instantiated.

+

Image:public-apis-image2.gif

+

The embedding layer consists of several components built on top of XPCOM and its services. Much of the Gecko functionality is exposed through a component called the nsWebBrowser. Embedding applications can leverage this component to easily access many of Gecko's features. Each WebBrowser instance represents the "client-area" of a typical browser window. The WebBrowser exposes a set of interfaces which allow the embedding application to control activity and respond to changes within this client area. Using these interfaces an embedding application can build up its own user interface around a WebBrowser instance.

+

Image:public-apis-image1.gif

+

Public Classes

+

The following utility classes are available from the XPCOM DLL. They provide some basic functionality which should be leveraged when building new XPCOM components.

+ +

These are templatized smart pointers which transparently deal with XPCOM reference counting issues. See the nsCOMPtr User's Manual for more information.

+ +

There are a collection of string classes which support both unicode and ASCII strings. These classes provide a variety of string operations as well as dealing with the memory management issues of storing the underlying data. See the String Guide for more details.

+ +

This is an nsCOMPtr which encapsulates XPCOM weak reference support. See the nsIWeakReference document for more information.

+

Public Return Codes

+ +

Public Functions

+

The following functions are available from the XPCOM DLL.

+ +

This function initializes the Gecko embedding support. This must be the first function call made into Gecko.

+ +

This function shuts down Gecko and cleans up any remaining resources... Currently, once Gecko has been shutdown, it cannot be restarted in the same process space... This should change in the future.

+ +

This helper class provides static accessors to the global nsMemory Service.

+ +

This function returns an instance of the Component Manager service.

+ +

This is a helper class which converts an ASCII string into a UCS2 string. Typically, instances of this class are stack allocated, and wrap ASCII arguments which must be converted into UCS2.

+ +

This is a helper class which works in conjunction with nsCOMPtr to perform a simplified call to nsISupports::QueryInterface(...) with a typesafe assignment.

+ +

This function simplfies retrieving interfaces via the nsIInterfaceRequestor::GetInterface(...) method. Using this function, one can use nsISupports instances and still easily access other interfaces via nsIInterfaceRequestor.

+

Internally, this function tries to convert the nsISupports argument into an nsIInterfaceRequestor and then calls GetInterface(...) to retrieve the requested interface.

+ +

This function is the equivilent of do_QueryInterface except that it performs the QI through a weak reference.

+ +

This function simplifies accessing services from the Service Manager.

+ +

This function simplifies creating new component instances.

+ +

This template helper class allows easy access to an interface's nsIID. Typically the NS_GET_IID(...) macro is used instead of using the nsCOMTypeInfo template directly.

+ +

This function creates a weak reference to a component which implements the nsIWeakReference interface.

+

Global Services

+

nsServiceManager

+

The Service Manager is the central repository for accessing instances of the various XPCOM services. Each service is represented by a singleton object which is instantiated the first time it is requested and remains alive until the Service Manager is shut down, or the service is explicitly unloaded.

+

Through the Service Manager, individual services can be loaded, unloaded and accessed.

+

Implemented Interfaces:

+ +

Related Interfaces:

+ +

nsMemory

+

The nsMemory service provides the global memory manager implementation for XPCOM. In addition to memory allocation and release, this service provides low memory notifications, called a memory pressure observers, which are notified when memory is low - thus allowing cached resources to be freed.

+

All heap access should be done via the nsMemory service. To facilitate this, a set of global functions are available to access the nsMemory methods without requiring an instance of the nsMemory service (see nsMemory.h).

+

Contract-id: NS_MEMORY_CONTRACTID

+

Implemented Interfaces:

+ +

Related Interfaces:

+ +

nsComponentManager

+

The nsComponentManager service is responsible for creating new instances of XPCOM components. The Component Manager is also responsible for registering and managing the class factories used for component creation...

+

Contract-id: NS_COMPONENTMANAGER_CONTRACTID

+

Implemented Interfaces:

+ +

Requestor Interfaces:

+ +

Related Interfaces:

+ +

nsURILoader

+

The nsURILoader service is responsible for targeting a URI at an appropriate content handler. A content handler may be an existing or new window, a helper application or the Unknown Content Handler - if no other handler can be found for the content-type.

+

Contract-id: NS_URI_LOADER_CONTRACTID

+

Implemented Interfaces:

+ +

Related Interfaces:

+ +

nsUnknownContentTypeHandler

+

The UnknownContentTypeHandler service is the last resort of the URILoader when no other content handler can be located. If no registered content handlers are available, the UnknownContentTypeHandler is notified.

+

The default implementation of this service displays a dialog box asking the user if the content should be saved to disk...

+

Contract-id: NS_IUNKNOWNCONTENTTYPEHANDLER_CONTRACTID

+

Implemented Interfaces:

+ +

HelperApp Launch Dialog

+

Contract-id: NS_EXTERNALHELPERAPPSERVICE_CONTRACTID

+

Implemented Interfaces:

+ +

Preferences Service

+

The Preferences service provides access to persistent data stored within a user's profile directory.

+

Contract-id: NS_PREF_CONTRACTID

+

Implemented Interfaces:

+ +

Related Interfaces:

+ +

Profile Manager Service

+

Contract-id:

+

Implemented Interfaces:

+

Document Loader Service (WebProgress)

+

Eventually, this service will be replaced by theWebProgress service...

+

Contract-id: NS_DOCUMENT_LOADER_SERVICE_CONTRACTID

+

Implemented Interfaces:

+ +

Related Interfaces:

+ +

Public Components

+

nsWebBrowser

+

The nsWebBrowser is the main embedding component which Gecko exposes. Conceptually, each nsWebBrowser instance represents a HTML content area.

+

Conceptually, for each document being rendered, Gecko creates a container called a DOMWindow. Each WebBrowser exposes a tree of DOMWindows - representing the frame hierarchy for the current document. As such, access to individual document frames is done via the DOMWindow interfaces. Manipulation of the entire document structure is done via the various WebBrowser interfaces.

+

Contract-id: NS_WEBBROWSER_CONTRACTID

+

Implemented Interfaces:

+ +

Requestor Interfaces:

+ +

Related Interfaces:

+ +

Overview:

+

Most of Gecko's functionality is exposed through the nsWebBrowser component. The WebBrowser provides a simple mechanism for other applications to leverage Gecko functionality. Each instance of a WebBrowser encapsulates a full featured HTML content area.

+

The embedding application receives notifications from Gecko through a set of callback interfaces it may choose to implement.

+

Image:public-apis-image3.gif

+

Below is a code snippet which an embedding application can use to create and initialize a WebBrowser:

+
      nsresult rv;
+      nsCOMPtr<nsIBaseWindow> baseWindow;
+      nsCOMPtr<nsIWebBrowser> webBrowser;
+
+      // Create a nsWebBrowser instance...
+      webBrowser = do_CreateInstance(NS_WEBBROWSER_CONTRACTID, &rv);
+      if (NS_FAILED(rv)) return rv;
+
+      // Give the WebBrowser a pointer to the embedding component which
+      // implements the callback interfaces.  Replace 'this' with
+      // an appropriate object...
+      rv = webBrowser->SetContainerWindow((nsIWebBrowserChrome*)this);
+      if (NS_FAILED(rv)) return rv;
+
+      baseWindow = do_QueryInterface(webBrowser);
+
+      // Initialize the WebBrowser with a native parent window
+      // (ie. HWND on Win32).  Replace 'nativeWindow' with a
+      // reference to an appropriate native resource...
+      rv = baseWindow->InitWindow(nativeWindow,   // Native window
+                                  nsnull,         // Always nsnull.
+                                  x, y, cx, cy);  // Initial dimensions...
+      if (NS_FAILED(rv)) return rv;
+
+      // Create the child window for the WebBrowser.
+      rv = baseWindow->Create();
+      if (NS_FAILED(rv)) return rv;
+
+      // At this point webBrowser contains the new initialized instance
+      // of the nsWebBrowser component...
+      // Save webBrowser before it goes out of scope :-)
+
+
+

Web Navigation

+

The nsIWebNavigation interface is used to load URIs into the WebBrowser and provide access to session history capabilities - such as back and forward.

+

Clipboard

+

The WebBrowser exposes access to the system clipboard via the nsIClipboardCommands interface. This interface supports cut/copy/paste operations on the current selection within the WebBrowser window.

+

Printing (not yet implemented)

+

Printing the contents of a DOMWindow within a WebBrowser is a two step process. First, the printer and page options are collected via the nsIPrintOptions interface. On most platforms this involves displaying a native Print dialog box. Once all of the options have been set, the nsIWebBrowserPrint interface is used to print the contents of the desired DOMWindow.

+

Searching

+

Searching within a nsWebBrowser is controlled via the nsIWebBrowserFind interface. The search is always performed within the DOMWindow which currently has the focus.

+

Focus Management

+

Focus managment within the WebBrowser is accessed via the nsIWebBrowserFocus interface.

+

This interface serves two purposes. First, it provides methods for the embedding application to notify a WebBrowser of activation/deactivation and to control tabbing order... This interface also allows access to the currently focused DOMWindow and DOMElement.

+

Context Menu notifications

+

Right-click context menu notifications are passed up to the embedding application through the nsIContextMenuListener interface. These notifications allow the embedding application to display context menus based on user activity within the WebBrowser (such as a right-click on a hypertext link).

+

Saving Documents

+

Notification Interfaces which the embedding application should implement

+

nsFile

+

Public Interfaces

+

nsISupports

+

Base Component Object Model interface. This interface provides runtime interface discovery and a reference counted memory model fashioned after the Microsoft COM IUnknown interface.

+

Interface status... none

+

Interface definition: nsISupportsUtils.h

+


+ nsIInterfaceRequestor

+

This Interface provides an interface discovery mechanism which does not imply aggregation. Interface status... none

+

Interface definition: nsIInterfaceRequestor.idl

+

nsIWeakReference

+

This interface is used to retern a proxy reference to a component.

+

Interface status... being reviewed

+

Interface definition: nsIWeakReference.idl

+

nsISimpleEmunerator

+

This interface provides a simple enumeration abstraction.

+

Interface status... being reviewed

+

Interface definition: nsISimpleEnumerator.idl

+

nsIServiceManager

+

This interface allows access to global services within mozilla.

+

Interface status... none

+

Interface definition: nsIServiceManager.h

+


+ nsIShutdownListener

+

This interface is used to receive notifications when the Service Manager is being shutdown.

+

Interface status... none

+

Interface definition: nsIServiceManager.h

+


+ nsIComponentManager

+

This interface allows new instances of registered XPCOM components to be instantiated.

+

Interface status... none

+

Interface definition: nsIComponentManager.idl

+


+ nsIFactory

+

This interface is used by the Component Manager to create new instances of a particular XPCOM component. Each component must provide a factory implementation for creating new instances.

+

Interface status... none

+

Interface definition: nsIFactory.idl

+


+ nsIMemory

+

This interface provides access to the global memory management functionality.

+

Interface status... being reviewed

+

Interface definition: nsIMemory.idl

+


+ nsIDOMWindow

+

This interface is used to represent the window containing a specific document.

+

Interface status... being reviewed

+

Interface definition: nsIDOMWindow.idl

+


+ nsIBaseWindow

+

This interface provides access to various window operations.

+

Interface status... being reviewed

+

Interface definition: nsIBaseWindow.idl

+


+ nsIRequest

+

This interface provides a means to control various operations.

+

Interface status... being reviewed

+

Interface definition: nsIRequest.idl

+


+ nsIWebBrowser

+

This is the primary interface to the WebBrowser component.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowser.idl

+


+ nsIWebBrowserSetup

+

This interface is used to enable or disable various capabilities of a nsWebBrowser instance.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowserSetup.idl

+


+ nsIWebBrowserChrome

+

This interface provides access to the window containing an nsWebBrowser instance.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowserChrome.idl

+


+ nsIWebNavigation

+

This interface exposes the web navigation functionality of the nsWebBrowser component.

+

Interface status... being reviewed

+

Interface definition: nsIWebNavigation.idl

+


+ nsIWebBrowserPersist

+

This interface exposes the save-as functionality of the nsWebBrowser component.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowserPersist.idl

+


+ nsIWebBrowserPrint

+

This interface allows printing of individual (or a collection of) DOM Windows within a nsWebBrowser component.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowserPrint.idl

+


+ nsIWebBrowserFind

+

This interface exposes the searching capabilities of the nsWebBrowser component.

+

Interface status... none

+

Interface definition: nsIWebBrowserFind.idl

+


+ nsIWebBrowserFocus

+

This interface provides access to the focus information of a nsWebBrowser instance.

+

Interface status... being reviewed

+

Interface definition: nsIWebBrowserFocus.idl

+


+ nsIWebProgress

+

Interface status...

+

Interface definition:

+


+ nsIWebProgressListener

+

Interface status...

+

Interface definition:

+


+ nsIPrompt

+

Interface status...

+

Interface definition:

+


+ nsIPrefs

+

Interface status...

+

Interface definition:

+


+ {{ interface("nsIProfile") }}

+

The Profile Manager creates and manages user profiles; each profile is essentially a complete configuration of the application, including preferences, installed extensions, and so forth.

+


+ nsIDirectoryServiceProvider

+

Interface status...

+

Interface definition:

+


+ nsILocalFile

+

Interface status...

+

Interface definition:

+


+ nsIFile

+

Interface status...

+

Interface definition:

+


+ nsIClipboardCommands

+

Interface status...

+

Interface definition:

+


+ nsISelection

+

Interface status...

+

Interface definition:

+


+ nsIURILoader

+

Interface status...

+

Interface definition:

+


+ nsIURIContentListener

+

Interface status...

+

Interface definition:

+

 

+

Defining New XPCOM Components

+
+

Original Document Information

+ +
+

 

diff --git "a/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/embarquer_gecko/index.html" "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/embarquer_gecko/index.html" new file mode 100644 index 0000000000..e35036fbf4 --- /dev/null +++ "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/embarquer_gecko/index.html" @@ -0,0 +1,133 @@ +--- +title: Embarquer Gecko +slug: Mozilla/Gecko/Mozilla_embarqué/FAQ_de_Mozilla_embarqué/Embarquer_Gecko +tags: + - FAQ_de_Mozilla_embarqué +translation_of: Mozilla/Gecko/Embedding_Mozilla/FAQ/Embedding_Gecko +--- +

Obsolète
Cette fonctionnalité est obsolète. Bien qu'encore supportée par des navigateurs, son utilisation est découragée pour tout nouveau projet. Évitez de l'utiliser.

+ +
Embedding of Gecko is no longer supported. If you currently embed Gecko, you should use an alternate solution, because you will not be able to pick up new security improvements. Do not use the techniques covered on this page; this material is retained for historical purposes only.
+ +

Section 2 : Embarquer Gecko

+ +

De quels fichiers ai-je besoin pour embarquer ?

+ +

Actuellement, vous devez télécharger et compiler toute l'arborescence des sources du navigateur Mozilla puis choisir les fichiers binaires que vous souhaitez embarquer dans votre application.
+ Lesnightly builds sont créées automatiquement depuis les manifests donc vous pouvez commencer à chercher de ce coté.

+ +

Comment puis-je compiler les sources à embarquer ?

+ +

Premièrement compilez Mozilla, puis saisissez :

+ +
cd mozilla/embedding/config
+make
+
+ +

Note : Si vous utilisez un objdir, placez-vous plutôt dans le répertoire mozilla/<objdir>/embedding/config puis lancez la compilation avec make.

+ +

Un répertoire appelé mozilla/dist/Embed est créé, il contient les fichiers spécifiés par les manifests par défaut et chrome. Vous pouvez tester les compilations par défaut en exécutant les applications de test TestGtkEmbed sous Unix ou MFCEmbed sous Win32. Pour exécuter TestGtlEmbed sous Unix saisissez :

+ +
cd mozilla/dist/Embed
+./run-mozilla.sh ./TestGtkEmbed
+
+ +

Comment est faite la distribution embarquée ?

+ +

Look in embedding/config/ to see a the embedding build process. The basebrowser-win (or basebrowser-unix etc.) file determines which files need to be copied. The embed-jar.mn specifies what chrome is required.

+ +

Note that this sample only contains atypical subset of files. You may wish to add or remove files from basebrowser-foo (where foo is win, unix or mach as appropriate) depending on the capabilities you need in your product, or supplement these files by writing your own client-foo file which will be read in addition to basebrowser-foo.

+ +

For instance, you can remove the "necko2" library if you do not need FTP, but you will need to add the "appcomps" and "mork" libraries in order to use the Mozilla browser's global history implementation.

+ +

The embedding distribution readme file provides more information.

+ +

Todo: provide a more complete map of features <-> files

+ +

Pourquoi ai-je besoin de distribuer des fichiers XPT avec mon application ?

+ +

XPT files are XPCOM type libraries and contain binary definitions of interfaces used by cross-thread marshalling routines and JavaScript to call objects. In other words they are as vital as DLLs to ensure Gecko functions properly.

+ +

XPT files can be concatenated together using the xpt_link tool to reduce clutter and improve startup performance. There is a special perl script for this purpose, that you can see here.

+ +

Comment me prémunir des changements de Gecko ?

+ +

If you want to be protected against changes in the Gecko, you should only use interfaces and API that are clearly marked FROZEN in their idl description. This query will find most of the frozen interfaces: Frozen Interface and APIs. Interfaces are being reviewed and frozen all the time and cover most things embedders will want to do.

+ +

You can still use unfrozen interfaces (hey it's open source and we can't stop you!) and even reach into the guts of the code but you do so at your own risk. Subsequent releases of Mozilla may well change these interfaces and your source and binary will break as a result.

+ +

See the Embedding API Reference for more information

+ +

Cela veut-il dire que mon application fonctionnera avec toutes les futures versions de GRE/Gecko/Mozilla ?

+ +

As long as you use frozen interfaces, the answer is: "Almost." Unfortunately vtable layout can vary from compiler to compiler. This mostly affects Linux compilers such as gcc which have changed their vtable layout more than once in the past few years. See the document on binary compatibility. when ported too, this should be an internal link

+ +

Quelles plate-formes sont supportées ?

+ +

Short answer is anything Mozilla can run on, then Gecko can too. However, the embedding is concentrating on three primary platforms:

+ + + +

L'embarquement supporte-t-il des protocoles sécurisés comme HTTPS ?

+ +

Yes, psm is supported in embedding.

+ +

Comment mes applications communiquent-elles avec Gecko ?

+ +

The Embedding API provides a set of interfaces and to control the embedded application, and another set of interfaces that the containing application must implement in order to receive asynchronous notifications from the embedded browser.

+ +

Todo: insert jud's picture here?

+ +

Puis-je embarquer sans...

+ +

(Some of the more common questions)

+ + + +

Puis-je embarquer l'éditeur HTML de Mozilla ?

+ +

Sort of. The latest word is that you can embed an editor in a native app, and do command handling and updating via the command handling APIs. There is some lacking functionality (e.g. controlling editor types, inserting and extracting HTML). In addition, the command handling APIs are soon going to change, when Mike Judge lands a long-standing patch (which missed the 1.0 change, and bas been delayed way too long).

+ +

Documentation is lacking, mostly because of pending API changes. Check out the Embedding Editor page for more info.

+ +

Quel toolkit de widget peut utiliser Mozilla ?

+ +

Mozilla makes its own cross-platform widgets for HTML forms, and does not use a 3rd-party cross platform toolkit, nor the native widgets that a platform provides. The widgets are drawn using GFX, Mozilla's abstraction of a drawing toolkit. They are styled with CSS, including minor per-platform tweaks to allow them to look like the native platform's native widgets. This allows full CSS and DOM support of all HTML widgets across all platforms, without requiring each platform to separately support every part of CSS and DOM.

+ +

There have been a number of requests for native widget support but at this time there are no plans to support a second widget set beyond the cross-platform widgets.

+ +

In the future, widgets may be defined with XBL.

+ +

Mozilla embarqué supporte-t-il Java ?

+ +

We provide Java support through the OJI plugin API. The Java plugin from Sun takes ~7Mb of disk space (Linux). If you want Java support you should edit the basebrowser-win / basebrowser-unix etc. file and uncomment the OJI section or copy those files manually after an embedding dist has been created.

+ +

Puis-je embarquer Mozilla dans n'importe quel autre cas ?

+ +

Aside from programming direct to the embedding API you may also embed Mozilla:

+ + + +

Interwiki Language Links

+ +
 
diff --git "a/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/introduction_\303\240_gecko_et_\303\240_l'embarqu\303\251/index.html" "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/introduction_\303\240_gecko_et_\303\240_l'embarqu\303\251/index.html" new file mode 100644 index 0000000000..1836cab0bb --- /dev/null +++ "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/faq_de_mozilla_embarqu\303\251/introduction_\303\240_gecko_et_\303\240_l'embarqu\303\251/index.html" @@ -0,0 +1,53 @@ +--- +title: Introduction à Gecko et à l'embarqué +slug: >- + Mozilla/Gecko/Mozilla_embarqué/FAQ_de_Mozilla_embarqué/Introduction_à_Gecko_et_à_l'embarqué +tags: + - FAQ_de_Mozilla_embarqué +translation_of: Mozilla/Gecko/Embedding_Mozilla/FAQ/How_do_I... +--- +

 

+

Introduction à Gecko et à l'embarquement

+

Qu'est-ce que Gecko ?

+

Gecko est le moteur interne du navigateur, ce qui inclut networking, un parser, un modèle de contenu, chrome et les autres technologies sur lesquelles Mozilla et les autres applications sont basées. En d'autres termes, tout ce qui n'est pas spécifique à une application.

+

La FAQ de Gecko est légèrement obsolète FAQ.

+

Qu'est-ce que Mozilla ?

+

Mozilla est un navigateur web open-source multi plates-formes, un éditeur et une application de messagerie / newsgroup créé sur Gecko.

+

Qu'est-ce que le GRE ?

+

Le GRE (formellement le MRE) qui est l'acronime de Gecko Runtime Environment, est un support d'exécution partagé que toutes les applications peuvent utiliser. Il est maintenant développé comme un projet indépendant connu sous le nom de XULRunner.

+

Qu'est-ce que XPCOM ?

+

XPCOM est un + + modèle objet de composants + (semblable à COM/DCOM de MS Windows mais conçut pour être portable sur plusieurs plates-formes) utilisé pour unifier la création, le contrôle, et la suppression d'objets et d'autres données à travers Mozilla. Le coeur de XPCOM est l'interface + + nsISupports + , qui offre des services de comptage des références et d'introspection (possibilité d'interroger les objets afin de se renseigner sur leurs capacités). Tout les objets XPCOM implémentent l'interface + + nsISupports + , en plus de toutes les interfaces spécifiques qui lui sont nécessaire. En fin de compte, XPCOM fournit une couche de services indépendante du language appelé + + XPConnect + qui permet l'implémentation d'objets dans tout language supporté. Grâce à + + XPConnect + , ces objets peuvent aussi être appelés à partir de n'importe lequel de ces languages.

+

On peut trouver plus d'informations ici.

+

Que signifie embarquer Gecko ?

+

Gecko autorise des developpeurs tiers à utiliser la même technologie que Mozilla. Cela signifie que vous pouvez tirer partie, dans une application tierce, des services d'un navigateur web, ouvrir des canaux de communications et faire transiter des flux de données à travers le service réseau, le + + Modèle Objet de Document + (NdT: en anglais DOM, + + Document Object Model + ) et plus encore. Vous pouvez même bâtir entièrement une nouvelle application en utilisant Gecko.

+

Quels sont les termes de licence pour embarquer Gecko ?

+

Les mêmes que pour le reste de Mozilla. Voir la page du MPL pour plus d'informations.

+

Existe-t'il un SDK ?

+

Nous travaillons lentement sur une SDK, gelant et documentant les interfaces et retouchant le processus de construction. Pour le moment nous vous recommandons de télécharger le code source puis de le compiler.

+

Des compilations nocturnes du SDK pour la plateforme Windows 32bits peuvent être disponibles ici.

+

Quelle est la dernière version ? Quelle version utiliser ?

+

Les compilations embarquées et les source tarballs sont produites la nuit et peuvent être obtenues ici. Si vous privilégiez la stabilité, les compilations de la branche 1.7.x de Mozilla sont vivement recommendées.

+

Qui utilise déjà gecko ?

+

Voir ici la liste des logiciels embarquant Gecko.

+

Interwiki Language Links

diff --git "a/files/fr/mozilla/gecko/mozilla_embarqu\303\251/index.html" "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/index.html" new file mode 100644 index 0000000000..b8a2b5bb4c --- /dev/null +++ "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/index.html" @@ -0,0 +1,59 @@ +--- +title: Mozilla embarqué +slug: Mozilla/Gecko/Mozilla_embarqué +tags: + - Mozilla_embarqué +translation_of: Mozilla/Gecko/Embedding_Mozilla +--- +
+

Gecko permet aux développeurs d'applications tierces de pouvoir bénéficier de la même technologie que celle présente dans Mozilla. Il est possible d'intégrer un navigateur Web à l'intérieur d'une autre application, d'ouvrir des canaux et de parcourir des flux de données à travers le réseau, de manipuler le DOM et ainsi de suite. Des applications entières peuvent être crées en s'appuyant sur Gecko.

+
+ + + + + + + + +
+

Documentation

+ +
+
FAQ de Mozilla embarqué
+
Une Foire Aux Questions très complète concernant Mozilla embarqué.
+
+ +
+
Les bases de Gecko embarqué
+
Une introduction à l'incorporation du moteur de rendu Gecko dans une application (à traduire de en:Gecko Embedding Basics).
+
+ +
+
Intégration de l'éditeur
+
Ce document détaille la situation actuelle de l'éditeur dans ce domaine, les problèmes dans l'implémentation existante, certains scénarios possibles d'intégration de l'éditeur qui doivent être pris en compte, et une solution embarquée qui les intègrera.
+
+ +
+
Construisez votre propre navigateur - Comment embarquer Mozilla
+
Une introduction rapide à Mozilla embarqué (à traduire de en:Roll your own browser - An embedding HowTo.
+
+ +

Tous les articles…

+ 		+

Communauté

+ +
    +
  • Voir les forums de Mozilla…
    • +
+ +

{{ DiscussionList("dev-embedding", "mozilla.dev.embedding") }}

+ + + +
+
Gecko, XPCOM
+
+
+ +

 

diff --git "a/files/fr/mozilla/gecko/mozilla_embarqu\303\251/int\303\251gration_\303\251diteur/index.html" "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/int\303\251gration_\303\251diteur/index.html" new file mode 100644 index 0000000000..4e6e8c8281 --- /dev/null +++ "b/files/fr/mozilla/gecko/mozilla_embarqu\303\251/int\303\251gration_\303\251diteur/index.html" @@ -0,0 +1,133 @@ +--- +title: Intégration de l'éditeur +slug: Mozilla/Gecko/Mozilla_embarqué/Intégration_éditeur +tags: + - Midas + - Mozilla_embarqué +translation_of: Mozilla/Gecko/Embedding_Mozilla/Embedding_the_editor +--- +

Introduction

+ +

Ce document présente les possibilités actuelles d'intégration d'un éditeur, les problèmes causés par l'intégration existante, quelques scénarios d'intégration possibles pour s'en sortir, et une solution d'intégration pour les réaliser. Pour finir, la solution retenue sera décrite étape par étape.

+ +

Mises en œuvre possibles de l'intégration

+ +

Ici sont décrits des scénarios d'intégration nécessaires pour faire fonctionner un éditeur. Notez que j'utilise le terme de « Compositeur » pour désigner une interface de composition au format HTML qui fait de l'édition de texte enrichi et « Éditeur » pour un éditeur en texte brut (aussi bien que pour la technologie sous-jacente du compositeur). <htmlarea> est vu comme une formule pour désigner un objet texte contenant du texte enrichi, cela ne veut pas dire pour autant que cette balise sera supportée dans les versions suivantes de Mozilla.

+ +

Compositeur intégré dans une application XUL

+ +

Les développeurs ont besoin d'intégrer des compositeurs dans leurs applications XUL en utilisant la balise <editor>, comme cela se fait aujourd'hui. Ils devraient avoir le moins possible de travail à faire pour obtenir les fonctions basiques d'édition, avoir autant d'<editor>s par fenêtre qu'ils le souhaitent et pouvoir contrôler si ces <editor>s sont en mode HTML ou en mode texte.

+ +

Compositeur intégré dans une application native

+ +

Dans ce cas de figure, l'<iframe> dans laquelle fonctionne l'éditeur est directement intégrée dans l'application native. Cela revient à intégrer un navigateur via nsIWebBrowser, mais en obtenant, à la place, un document éditable. L'interface du compositeur (barres d'outils, etc.) doit être implémentée à partir des éléments d'interface graphique présents dans le conteneur ou en utilisant du XUL. Cette interface doit être configurable, avec notamment des barres d'outils flottantes déplaçables (dockable ?), une même barre d'outils pour plusieurs objets compositeur, ou une pour chaque.

+ +

Ce type d'intégration requiert que le code du compositeur fonctionne quelle que soit l'interface utilisateur (IU). La communication entre le noyau de l'éditeur et l'interface utilisateur doit pouvoir passer par une ou plusieurs interfaces qui isolent l'éditeur de l'application hôte. (L'nsEditorShell existant fait des suppositions sur l'hébergement de document XUL, qui doivent être contredites.)

+ +

Compositeur intégré dans une page web (<htmlarea>)

+ +

IE 5 supporte l'élément <HTMLArea> ; si Mozilla travaille à supporter quelque chose de similaire, l'éditeur devra être intégrable dans la mesure du possible. Il est probable qu'on utilise XBL pour implémenter ce type d'objet, comme c'est prévu pour d'autres types de contrôles.

+ +

Dans le cas de l'intégration du compositeur dans une application native, il est donc ici nécessaire de rendre l'interface utilisateur configurable, de façon que l'on puisse aussi bien l'afficher comme une barre d'outils au dessus de <htmlarea>, comme une fenêtre flottante, ou comme une barre d'outil de haut-niveau (top-level).

+ +

Problèmes connus

+ +

L'architecture du compositeur existant a été créée alors que d'autres parties de Mozilla étaient encore en cours de développement. Il en résulte de nombreux points faibles et anachronismes. Cette section décrit ses défauts majeurs.

+ +

Problème d'appartenance de l'éditeur

+ +

L'éditeur d'une fenêtre compositrice appartient au nsEditorShell, qui à son tour est créé, dirigé et détruit par nsEditorBoxObject. L'objet box est une structure de présentation qui appartient aux noeuds de contenu et survit à la destruction/reconstitution de la frame. L'objet box a également une référence vers le docShell de la frame éditrice. XBL créé un nsEditorBoxObject pour chaque balise <editor>, et permet à Javascript d'accéder aux propriétés de cet objet box (tel que le nsIEditorShell). La balise <editor> est tout simplement une <iframe> dans laquelle l'éditeur est créé. Dans les autres aspects, il se comporte comme une <iframe> XUL.

+ +

Le problème avec ce modèle d'appartenance est qu'il ne peut y avoir qu'un éditeur par balise <editor>, alors que le document chargé dans l'<iframe> peut très bien contenir de multiples <iframe>s (dans le cas d'un document frameset ou dans un document contenant lui-même un <html:iframe>). Aujourd'hui, le compositeur ne fonctionne pas très bien avec ce types de document.

+ +

Limitation d'un éditeur par fenêtre

+ +

Le compositeur construit sur une architecture XUL/C++ s'est développé sur le présupposé qu'une seule balise <editor> par fenêtre suffirait. Lors de la construction de la fenêtre, nous prenons l'editorShell de l'élément <editor> que l'on met dans window.editorShell. A partir de là, beaucoup de Javascript dans editor.js, ComposerCommands.js et les différents fichiés JS de dialogue s'assurent de pouvoir atteindre le seul bon éditeur via window.editorShell. Ce présupposé manquait de clairevoyance et doit être corrigé.

+ +

L'éditeur suppose une structure de document XUL

+ +

Du code C++ et JS présent dans l'éditeur suppose que celui-ci se trouve dans un document XUL et qu'il y ait des nœuds du document XUL en dehors, dont les attributs peuvent être récupérés pour changer l'état de l'interface utilisateur (par exemple le style des boutons). Cela doit être changé pour permettre aux conteneurs d'utiliser leurs propres apparences, probablement natives. L'éditeur doit pouvoir faire des appels à travers une ou plusieurs interfaces quand il communique avec l'interface utilisateur.

+ +

Objectifs de l'intégration

+ +

L'éditeur requiert des changements de conception de façon à ce que les applications intégrées soient fonctionnelles. Ces changements doivent nécessairement prendre en compte les problèmes existants. Brièvement, les objectifs de l'intégration sont :

+ + + +

Atteindre ces objectifs doit également permettre de résoudre les problèmes suivants, liés au compositeur :

+ + + +

Solutions proposées

+ +

Régler les problèmes d'appartenance de l'éditeur

+ +

Comme décrit plus haut, les liens d'appartenance (racines) de l'éditeur doivent être changés de façon à ce qu'un éditeur se trouve au plus haut niveau du nsDocShell, plutôt que d'être accroché à l'objet nsEditorBoxObject. Il doit y avoir un docShell par <iframe> éditable. Cela implique :

+ + + + + +

Plus d'un éditeur par fenêtre

+ +

Les clients compositeurs basés sur Mozilla supposent tous qu'il n'y a qu'une balise <editor> par fenêtre. Ils ont tous besoin de fonctionner avec plusieurs éditeurs. Corriger cela nécessite des modifications JS de cette ordre :

+ + + +

Isoler l'éditeur de l'interface

+ +

Le compositeur doit ne rien connaitre de l'IU qui le contrôle. Le plan est d'isoler le compositeur de l'IU via une nouvelle interface que le conteneur implémente. N'importe quel IU qui est aujourd'hui créée par le compositeur doit passer par cette interface.

+ + + +

Les étapes de l'intégration

+ +

Cette section tente de préparer un plan d'implémentation, dans le but de garder tout en état de marche étape après étape (? as the various steps are taken). Certaines de ces tâches peuvent être faite simultanément.

+ +
    +
  1. Décider comment implémenter le support d'une session édition muti-éditeur
    2. +
  2. Éliminer les interdépendances spécifiques entre le compositeur et le document XUL, via nsIEditorUserInterface
    3. +
  3. Créer un goulet d'étranglement pour communiquer avec l'éditeur qui a le focus; s'assurer que les changements de focus mettent bien à jour l'état
    4. +
  4. Faire du docShell,le propriétaire de l'éditeur, créant nsIEditorFrame
    5. +
  5. Créer l'API de la session d'édition qui s'occupera des collections d'éditeurs (ou rendre l'éditeur refocusable)
    6. +
+ +

Questions ouvertes

+ +

Ou doit se trouver la logique d'ouverture et enregistrement de fichier ?

+ +

Il semble que certains conteneurs voudront composer leur logique d'ouverture et enregistrement de fichier, d'autres non. Ou devrait se trouver cette logique ? Peut-elle être en JavaScript ? Bien sur, un conteneur doit pouvoir utiliser ses propres boîtes de dialogue Ouvrir et Enregistrer et communiquer avec le compositeur pour coordonner le processus d'ouverture et enregistrement.

+ +
Réponse possible
+ +

Le conteneur fournit les boîtes de dialogue Ouvrir et Enregistrer s'il le veut. Dans le compositeur, on peut adopter (? pose) ces boîtes de dialogue à partir de JS (? certains problèmes liés à nsIFile ont été résolu - once some nsIFile problems have been solved).

+ +

Toute l'IU du compositeur doit-elle être remplaçable ?

+ +

Une immense partie de l'IU du compositeur se trouve dans les différentes boîtes de dialogue pour l'édition des tableaux, liens, images etc. Doit-on donner la possibilité à un conteneur de remplacer tout cela par une IU native ?

+ +
Réponse possible
+ +

Les boîtes de dialogue utilisent les API de l'éditeur disponible pour obtenir et affecter les données, donc elles peuvent faire tout leur travail en passant par les API existantes. Si un intégrateur veut une IU entièrement native, il aura à coder ses propres boîtes de dialogue et logiques associées, mais les API devraient toujours leurs être accessibles. Il semble que ce ne soit pas une bonne solution.

diff --git a/files/fr/mozilla/gecko/sdk_gecko/index.html b/files/fr/mozilla/gecko/sdk_gecko/index.html new file mode 100644 index 0000000000..306fb0590f --- /dev/null +++ b/files/fr/mozilla/gecko/sdk_gecko/index.html @@ -0,0 +1,61 @@ +--- +title: SDK Gecko +slug: Mozilla/Gecko/SDK_Gecko +tags: + - Développement_de_Mozilla + - Extensions + - Gecko +translation_of: Mozilla/Gecko/Gecko_SDK +--- +

+

+

Aperçu

+

Le SDK Gecko est un ensemble de fichiers XPIDL, d'entêtes et d'outils pour développer des composants XPCOM pouvant à leur tour être accéder depuis XUL grâce à JavaScript. +

Notez que le développement de tels composants ne nécessite pas que vous possédiez la totalité des sources, par exemple de Firefox, puisque vous n'accédez pas à l'interface utilisateur depuis un composant. Comme le composant contient des fonctions basiques, il doit pouvoir fonctionner avec chaque application de la plateforme Mozilla. Il n'y a donc aucune raison de se baser sur une application particulière pour créer une fonctionnalité générique. C'est la raison pour laquelle a été conçu le SDK Gecko. +

Il ne faut pas confondre le SDK Gecko avec XULRunner. Le SDK Gecko est une collection de fichiers d'entêtes et d'outils utilisée pour développer des composants XPCOM généraux afin d'ajouter des fonctionnalités à une plateforme existante, alors que XULRunner peut servir de support à l'éxécution d'applications autonomes ou embarquées basées sur la technologie Mozilla. +

+

Obtenir le SDK

+

Notez qu'il n'est pas nécessaire de re-télécharger ou de re-compiler le SDK Gecko à chaque mise à jour de sécurité de Mozilla puisque le SDK Gecko ne subit pas de modifications lors de ces mises à jour. +

+

Téléchargement

+

Lorsque vous téléchargez le SDK Gecko, vous devez choisir la version correspondant à la plus ancienne version de Mozilla que vous ciblez. Autrement dit, vous ne devez pas télécharger le SDK Gecko 1.7 si vous souhaitez utiliser votre composant avec Mozilla 1.6. C'est un point important car la compatibilité binaire n'est assurée qu'avec les versions futures du moteur de rendu Gecko. Pour ce tutoriel, nous utiliserons la version 1.7 du SDK Gecko, ainsi notre composant sera compatible avec Mozilla 1.7 (et ses produits dérivés tels que Firefox 1.0 ou Netscape 7.2). +

+ + + + + +
Lien de téléchargement +Gecko 1.7 (Firefox 1.0) +Gecko 1.8 (Firefox 1.5 et 2.0) +
Windows +Download +Download +
Mac +N/A +Download +
Linux i686 +Download +Download +
+

Le SDK n'est pas officiellement disponible pour d'autres plateformes ; si vous en avez besoin, vous devrez probablement le compiler vous même. +

Décompressez le fichier dans un répertoire de votre disque. +

+

Compiler le SDK

+

Pour compiler le SDK, vous devez compiler XULRunner (le SDK Gecko est compilé en même temps que XULRunner). Consultez la documentation sur la compilation pour plus de précisions. +

Le SDK Gecko est généré dans dist/sdk dans votre répertoire objet. Vous pouvez ensuite copier ce répertoire vers un autre emplacement et supprimer l'arborescence XULRunner. +

+

Contenu du SDK

+

Le SDK contient les éléments suivants : +

+ +

Pour plus d'informations sur la manière de lier des composants XPCOM en utilisant la bibliothèque "glue" XPCOM, consultez XPCOM Glue. +

+
+
+{{ languages( { "en": "en/Gecko_SDK", "ja": "ja/Gecko_SDK", "zh-cn": "cn/Gecko_SDK" } ) }} -- cgit v1.2.3-54-g00ecf