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.
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
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
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
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.
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
Short answer is anything Mozilla can run on, then Gecko can too. However, the embedding is concentrating on three primary platforms:
- Windows (95? definitely 98 and later)
- Linux (and probably most other X-windows based *nix variants)
- Macintosh OS X. MacOS 8.6 and 9 support is now deprecated to the ports section of the Mozilla project and are not being actively worked on.
Yes, psm is supported in embedding.
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?
(Some of the more common questions)
- FTP support? Yes.
- HTTPS support? Yes.
- Network support? No, maybe someday
- XUL support? No, but someday yes.
- CSS support? No, never.
- DOM support? No, probably never.
- XML support? No, probably never.
- International Characters Sets? Yes.
- Java support? Yes.
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.
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.
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.
Aside from programming direct to the embedding API you may also embed Mozilla:
- In GTK applications using the Gtk Mozilla Embedding Widget.
- In Win32 ActiveX applications using the Mozilla ActiveX Control.
- In Mac applications using PPEmbed.
- In a Java Application using Webclient.
Interwiki Language Links