From 90825e2392b2d70e43c7a25b8a3752299a933894 Mon Sep 17 00:00:00 2001 From: toma Date: Wed, 25 Nov 2009 17:56:58 +0000 Subject: Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. BUG:215923 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdebindings@1054174 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- xparts/doc/gtkxpart.fig | 55 +++++++++ xparts/doc/gtkxpart.png | Bin 0 -> 5917 bytes xparts/doc/kparts.fig | 71 +++++++++++ xparts/doc/kparts.png | Bin 0 -> 5916 bytes xparts/doc/kxpart.fig | 55 +++++++++ xparts/doc/kxpart.png | Bin 0 -> 6749 bytes xparts/doc/kxparthost.fig | 15 +++ xparts/doc/kxparthost.png | Bin 0 -> 1652 bytes xparts/doc/xparts.fig | 48 ++++++++ xparts/doc/xparts.html | 293 ++++++++++++++++++++++++++++++++++++++++++++++ xparts/doc/xparts.png | Bin 0 -> 4197 bytes 11 files changed, 537 insertions(+) create mode 100644 xparts/doc/gtkxpart.fig create mode 100644 xparts/doc/gtkxpart.png create mode 100644 xparts/doc/kparts.fig create mode 100644 xparts/doc/kparts.png create mode 100644 xparts/doc/kxpart.fig create mode 100644 xparts/doc/kxpart.png create mode 100644 xparts/doc/kxparthost.fig create mode 100644 xparts/doc/kxparthost.png create mode 100644 xparts/doc/xparts.fig create mode 100644 xparts/doc/xparts.html create mode 100644 xparts/doc/xparts.png (limited to 'xparts/doc') diff --git a/xparts/doc/gtkxpart.fig b/xparts/doc/gtkxpart.fig new file mode 100644 index 00000000..fc0669bd --- /dev/null +++ b/xparts/doc/gtkxpart.fig @@ -0,0 +1,55 @@ +#FIG 3.2 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 2025 13050 2025 13050 3600 10125 3600 10125 2025 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13500 3375 13500 2700 11925 2700 11925 3375 13500 3375 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 4950 13050 4950 13050 6525 10125 6525 10125 4950 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13500 6300 13500 5625 11475 5625 11475 6300 13500 6300 +2 1 0 4 0 7 100 0 20 0.000 0 0 -1 1 1 2 + 1 1 2.00 120.00 120.00 + 1 1 2.00 120.00 120.00 + 12825 5625 12825 3375 +2 1 0 2 0 7 100 0 -1 0.000 0 0 19 1 0 2 + 1 1 1.00 60.00 120.00 + 10800 6525 10350 7875 +2 2 0 1 0 7 100 0 -1 0.000 0 0 19 0 0 5 + 9225 7875 11700 7875 11700 9900 9225 9900 9225 7875 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 9450 9000 11025 9000 11025 9675 9450 9675 9450 9000 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 12375 8775 12375 8100 10800 8100 10800 8775 12375 8775 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 9225 11250 10350 11250 10350 11925 9225 11925 9225 11250 +2 1 0 2 0 7 100 0 -1 0.000 0 0 19 1 0 2 + 1 1 1.00 60.00 120.00 + 9900 9675 9675 11250 +2 1 1 2 0 7 100 0 -1 4.500 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 10350 9675 10350 11025 +2 2 1 1 0 7 100 0 -1 4.000 0 0 -1 0 0 5 + 9000 11025 11700 11025 11700 12150 9000 12150 9000 11025 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13050 9675 13050 9000 11250 9000 11250 9675 13050 9675 +4 0 0 100 0 0 12 0.0000 4 135 825 12375 3150 XPartHost\001 +4 0 0 100 0 0 12 0.0000 4 180 2040 10350 2475 KXPartHost : public KPart\001 +4 0 0 100 0 0 12 0.0000 4 180 1125 12150 6075 XPartManager\001 +4 0 0 100 0 0 12 0.0000 4 135 1680 13050 4275 DCOP communication\001 +4 0 0 100 0 0 12 0.0000 4 105 480 9900 7425 create\001 +4 0 0 100 0 0 12 0.0000 4 135 735 9450 8550 GtkXPart\001 +4 0 0 100 0 0 12 0.0000 4 180 1410 10350 5400 GtkXPartManager\001 +4 0 0 100 0 0 12 0.0000 4 135 1155 9675 9450 GtkMozEmbed\001 +4 0 0 100 0 0 12 0.0000 4 135 450 11250 8550 XPart\001 +4 0 0 100 0 0 12 0.0000 4 135 570 9450 11700 Mozilla\001 +4 0 0 100 0 0 12 0.0000 4 105 480 9225 10575 create\001 +4 0 0 100 0 16 12 0.0000 4 180 1560 10575 10575 load shared object\001 +4 0 0 100 0 0 12 0.0000 4 135 1410 11475 9450 BrowserExtension\001 diff --git a/xparts/doc/gtkxpart.png b/xparts/doc/gtkxpart.png new file mode 100644 index 00000000..32e85e54 Binary files /dev/null and b/xparts/doc/gtkxpart.png differ diff --git a/xparts/doc/kparts.fig b/xparts/doc/kparts.fig new file mode 100644 index 00000000..afed114f --- /dev/null +++ b/xparts/doc/kparts.fig @@ -0,0 +1,71 @@ +#FIG 3.2 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 1575 2025 2925 2025 2925 2700 1575 2700 1575 2025 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 2925 2025 4275 2025 4275 2700 2925 2700 2925 2025 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 1575 1350 4275 1350 4275 2700 1575 2700 1575 1350 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 7425 3150 8550 3150 8550 3825 7425 3825 7425 3150 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 6300 3150 7425 3150 7425 3825 6300 3825 6300 3150 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 6300 2475 8550 2475 8550 3150 6300 3150 6300 2475 +2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 2250 2700 1800 4275 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 1125 4275 2475 4275 2475 4950 1125 4950 1125 4275 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 2700 4275 3600 4275 3600 4950 2700 4950 2700 4275 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 900 6075 2475 6075 2475 6750 900 6750 900 6075 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 2925 6075 4050 6075 4050 6750 2925 6750 2925 6075 +2 1 0 2 0 7 100 0 -1 0.000 0 0 19 1 0 2 + 1 1 1.00 60.00 120.00 + 1800 4950 1350 6075 +2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 2025 4950 3600 6075 +2 1 0 2 0 7 100 0 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 2475 2700 3150 4275 +2 2 1 1 0 7 100 0 -1 4.000 0 0 -1 0 0 5 + 675 4050 4275 4050 4275 6975 675 6975 675 4050 +2 1 1 2 0 7 100 0 -1 4.500 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3600 2700 3600 4050 +3 2 0 2 0 7 100 0 -1 0.000 0 1 0 3 + 1 1 1.00 60.00 120.00 + 6300 3600 5400 4050 4270 4243 + 0.000 -1.000 0.000 +3 2 0 2 0 7 100 0 -1 0.000 0 1 0 3 + 1 1 1.00 60.00 120.00 + 4275 2025 5625 2250 6300 2700 + 0.000 -1.000 0.000 +4 0 0 100 0 16 12 0.0000 4 135 1035 5175 4500 offer service\001 +4 0 0 100 0 0 12 0.0000 4 180 960 1800 2475 KLibFactory\001 +4 0 0 100 0 0 12 0.0000 4 135 900 3150 2475 KLibLoader\001 +4 0 0 100 0 16 12 0.0000 4 180 945 2475 1800 Application\001 +4 0 0 100 0 16 12 0.0000 4 180 1155 5400 2025 query service\001 +4 0 0 100 0 0 12 0.0000 4 180 750 7650 3600 KSyCoCa\001 +4 0 0 100 0 16 12 0.0000 4 135 660 6525 3600 KTrader\001 +4 0 0 100 0 16 12 0.0000 4 135 315 7200 2925 KIO\001 +4 0 0 100 0 0 12 0.0000 4 105 480 1575 3375 create\001 +4 0 0 100 0 16 12 0.0000 4 135 450 1575 4725 KPart\001 +4 0 0 100 0 0 12 0.0000 4 135 450 2925 4725 KPart\001 +4 0 0 100 0 0 12 0.0000 4 135 1410 900 6525 BrowserExtension\001 +4 0 0 100 0 0 12 0.0000 4 135 810 3150 6525 TextEditor\001 +4 0 0 100 0 0 12 0.0000 4 180 1110 1575 5850 queryInterface\001 +4 0 0 100 0 0 12 0.0000 4 180 1110 3150 5625 queryInterface\001 +4 0 0 100 0 0 12 0.0000 4 105 480 2475 3825 create\001 +4 0 0 100 0 16 12 0.0000 4 180 1560 3600 3375 load shared object\001 diff --git a/xparts/doc/kparts.png b/xparts/doc/kparts.png new file mode 100644 index 00000000..b2d534b3 Binary files /dev/null and b/xparts/doc/kparts.png differ diff --git a/xparts/doc/kxpart.fig b/xparts/doc/kxpart.fig new file mode 100644 index 00000000..ce238956 --- /dev/null +++ b/xparts/doc/kxpart.fig @@ -0,0 +1,55 @@ +#FIG 3.2 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 2025 13050 2025 13050 3600 10125 3600 10125 2025 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13500 3375 13500 2700 11925 2700 11925 3375 13500 3375 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 4950 13050 4950 13050 6525 10125 6525 10125 4950 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13500 6300 13500 5625 11475 5625 11475 6300 13500 6300 +2 1 0 4 0 7 100 0 20 0.000 0 0 -1 1 1 2 + 1 1 2.00 120.00 120.00 + 1 1 2.00 120.00 120.00 + 12825 5625 12825 3375 +2 1 0 2 0 7 100 0 20 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 10575 7200 9225 10125 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 11475 6525 13050 6525 13050 7200 11475 7200 11475 6525 +2 1 1 2 0 7 100 0 -1 4.500 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 12375 7200 12375 8550 +2 2 1 1 0 7 100 0 -1 4.000 0 0 -1 0 0 5 + 7875 8550 13050 8550 13050 11475 7875 11475 7875 8550 +2 2 0 1 0 7 100 0 -1 0.000 0 0 19 0 0 5 + 8325 9000 10800 9000 10800 11025 8325 11025 8325 9000 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 11925 9900 11925 9225 10350 9225 10350 9900 11925 9900 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 8550 10125 9675 10125 9675 10800 8550 10800 8550 10125 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 6525 11475 6525 11475 7200 10125 7200 10125 6525 +2 1 0 2 0 7 100 0 -1 0.000 0 0 19 1 0 2 + 1 1 1.00 60.00 120.00 + 10086 6059 8775 9000 +4 0 0 100 0 0 12 0.0000 4 135 825 12375 3150 XPartHost\001 +4 0 0 100 0 0 12 0.0000 4 180 2040 10350 2475 KXPartHost : public KPart\001 +4 0 0 100 0 0 12 0.0000 4 180 1260 10350 5400 KXPartManager\001 +4 0 0 100 0 0 12 0.0000 4 180 1125 12150 6075 XPartManager\001 +4 0 0 100 0 0 12 0.0000 4 135 1680 13050 4275 DCOP communication\001 +4 0 0 100 0 0 12 0.0000 4 180 960 10350 6975 KLibFactory\001 +4 0 0 100 0 0 12 0.0000 4 135 900 11700 6975 KLibLoader\001 +4 0 0 100 0 16 12 0.0000 4 180 1560 12600 7875 load shared object\001 +4 0 0 100 0 0 12 0.0000 4 135 450 10800 9675 XPart\001 +4 0 0 100 0 0 12 0.0000 4 135 450 8775 10575 KPart\001 +4 0 0 100 0 0 12 0.0000 4 105 480 10350 7875 create\001 +4 0 0 100 0 0 12 0.0000 4 180 570 8550 9450 KXpart\001 +4 0 0 100 0 0 12 0.0000 4 105 480 8775 7650 create\001 diff --git a/xparts/doc/kxpart.png b/xparts/doc/kxpart.png new file mode 100644 index 00000000..70ae2e5f Binary files /dev/null and b/xparts/doc/kxpart.png differ diff --git a/xparts/doc/kxparthost.fig b/xparts/doc/kxparthost.fig new file mode 100644 index 00000000..fa34c141 --- /dev/null +++ b/xparts/doc/kxparthost.fig @@ -0,0 +1,15 @@ +#FIG 3.2 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +2 2 0 1 0 7 100 0 -1 0.000 0 0 -1 0 0 5 + 10125 2025 13050 2025 13050 3600 10125 3600 10125 2025 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 13500 3375 13500 2700 11925 2700 11925 3375 13500 3375 +4 0 0 100 0 0 12 0.0000 4 135 825 12375 3150 XPartHost\001 +4 0 0 100 0 0 12 0.0000 4 180 2040 10350 2475 KXPartHost : public KPart\001 diff --git a/xparts/doc/kxparthost.png b/xparts/doc/kxparthost.png new file mode 100644 index 00000000..d223e687 Binary files /dev/null and b/xparts/doc/kxparthost.png differ diff --git a/xparts/doc/xparts.fig b/xparts/doc/xparts.fig new file mode 100644 index 00000000..6ac73ff2 --- /dev/null +++ b/xparts/doc/xparts.fig @@ -0,0 +1,48 @@ +#FIG 3.2 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 5175 4050 5175 3375 3600 3375 3600 4050 5175 4050 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 5400 5850 5400 5175 3600 5175 3600 5850 5400 5850 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 3600 8325 3600 7650 1800 7650 1800 8325 3600 8325 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 5850 8325 5850 7650 4050 7650 4050 8325 5850 8325 +2 1 0 2 0 7 100 0 20 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 3375 6975 2925 7650 +2 1 0 2 0 7 100 0 20 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4050 6975 4950 7650 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 6750 6975 6750 6300 5175 6300 5175 6975 6750 6975 +2 1 0 2 0 7 100 0 20 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4725 5850 5850 6300 +2 1 0 2 0 7 100 0 20 0.000 0 0 -1 1 0 2 + 1 1 1.00 60.00 120.00 + 4275 5850 3825 6300 +2 4 0 1 0 7 100 0 20 0.000 0 0 19 0 0 5 + 4500 6975 4500 6300 2925 6300 2925 6975 4500 6975 +2 1 0 4 0 7 100 0 20 0.000 0 0 -1 1 1 2 + 1 1 2.00 120.00 120.00 + 1 1 2.00 120.00 120.00 + 4500 5175 4500 4050 +4 0 0 100 0 0 12 0.0000 4 135 825 4050 3825 XPartHost\001 +4 0 0 100 0 0 12 0.0000 4 180 1125 3825 5625 XPartManager\001 +4 0 0 100 0 0 12 0.0000 4 135 1410 2025 8100 BrowserExtension\001 +4 0 0 100 0 0 12 0.0000 4 135 810 4500 8100 TextEditor\001 +4 0 0 100 0 0 12 0.0000 4 135 450 5625 6750 XPart\001 +4 0 0 100 0 0 12 0.0000 4 135 450 3375 6750 XPart\001 +4 0 0 100 0 0 12 0.0000 4 105 480 5625 6075 create\001 +4 0 0 100 0 0 12 0.0000 4 180 1110 4725 7425 queryInterface\001 +4 0 0 100 0 0 12 0.0000 4 180 1110 1800 7425 queryInterface\001 +4 0 0 100 0 0 12 0.0000 4 135 1680 4725 4725 DCOP communication\001 +4 0 0 100 0 0 12 0.0000 4 105 480 3375 6075 create\001 diff --git a/xparts/doc/xparts.html b/xparts/doc/xparts.html new file mode 100644 index 00000000..0ff872be --- /dev/null +++ b/xparts/doc/xparts.html @@ -0,0 +1,293 @@ + + + + XParts - Extending KParts + + + +
+

XParts - Extending KParts

+ Matthias Ettrich, Simon Hausmann, Lars Knoll +
+ +

This article briefly describe the concepts, architecture and + reasoning behind the XParts technology. The purpose of XParts is + to extend KParts over language, toolkit, process and machine + bounderies. XParts makes it possible to write KDE components with + almost any toolkit or language an author prefers or to turn + existing applications into KDE components quite easily. + +

In addition, XParts is also an important glueing technology to + make KParts available in other component based systems or to + utilize non-KPart components transparently as KParts. + +

Classic KParts

+ +

In order to understand, what is extending about XParts, first a + brief overview on how KParts work. + + + +

Imagine an application - for example the integrated file manager + "Konqueror" - wants to utilize a component that handles the + "text/html" mimetype. It therefore asks the trader of the KIO + subsystem whether such a service is available and where. The + trader uses the system configuration cache to localize an + appropriate service that fits with the user's preferences. The + system configuration cache is a service type database + constructed from the desktop files of a KDE setup. In the case + of "text/html", the trader will very like return KDE's builtin + HTML viewer dubbed KHtml. This viewer is is most certainly + available as a KPart component. The application will then - via + KLibLoader and KLibFactory - load the shared library object that + implements the component and create a KPart instance. The + LibLoader keeps track of any objects created in the loaded + library and will automatically unload it after all objects have + been deleted. + +

If the application does not only want to display HTML, but + act as a full featured browser, the plain KPart interface is not + sufficient. If the user clicks on a link, for example, the HTML + component has to request a new URL. This kind of interaction is + defined in the BrowserExtension interface. An application can + query the KParts for additonal interfaces and get handles to + them in case those are available. In the example case of KHtml, + the BrowserExtension interface is exported. In the case of a + text editor component, it's very likely that the TextEditor + interface is available. + +

In-process components

+ +

The beauty of KParts is its simplicity. It's a clean and + flexible in-process approach with all its advantages: +

+ +

Those advantages are unvaluable for a lightweight and tightly + integrated office suite like KOffice. However, there are no silver + bullets and most certainly there are drawbacks when the system is + used in settings with different requirements. + +

Take the fourth item, it's comprehensive power while + maintaining simplicity. This was one of the main requirements of + the KOffice team, and it alone almost determines an in-process + approach with dynamically loadable shared objects. In a generic + browser like Konqueror, the requirements for integrated components + are not as high as with an office suite. In an office suite, + different components operate on one single document, whereas in a + browser, the components basically provide different views for + given Urls. To illustrate this issue, imagine how far the web + came with such primitive and inflexible component technology like + Netscape plugins. They did most of what people wanted to do with + browser plugins, though, and so became a huge success. + +

Out-of-process components

+ +

To sum this up: for multi-view applications like a generic + browser, there's no technical argument why out-of-process + components could not be sufficient. So let's look closer at the + specific advantages of such a solution. + +

+ +

Let's pick a concrete example. Imagine that you - for whatever + reason - want to offer the Mozilla rendering engine (gecko) as + KPart, so that users have an an alternative to KDE's builtin + rendering engine KHtml. + +

The first step of such a project is to find out, whether + Mozilla already is available as a reusable component that could + form the basis of a KDE integration. And in fact, it is. A small + library called GtkMozEmbed makes it possible to load the entire + Mozilla as a single Gtk widget, i.e. the rendering engine gecko, + the networking protocol implementations, the javascript + interpreter and whatever else Mozilla.org comes up with. The + MozEmbed library works pretty similar to KParts. Once + instantiated, it dynamically loads all libraries required by + Mozilla. As an interesting side note, all Unix filemanager + projects that utilize Mozilla (for example the Nautilus + filemanager) use this library to embed mozilla. This means you are + in good company using a stock MozEmbed library, as you don't have + to maintain this code but somebody else will do it for you. + +

Now that we have a dynamically loaded Gtk widget, how do we + turn that into a KPart? Quite straight forward. There is a + QGtkWidget extension available for Qt, that lets you use Gtk + widgets in your Qt applications. You simply create a QGtkWidget + with a pointer to the Gtk widget you get from MozEmbed and insert + that into your KPart. Then you do a few trivial reimplementations + of the virtual functions of the BrowserExtension interface that + map to the corresponding functions of Mozilla and you are + done. The result is a fully functional Konqueror that uses Mozilla + as backend - or rather a fully functional Mozilla that uses + Konqueror as graphical user interface, however you want to look at + it. + +

Trouble ahead

+ +

While the skedged solution works, there are some unmentioned + and ugly details. First of all, Mozilla uses the event loop of + glib, while Konqueror uses Qt. Unfortunatly, mixing both event + loops is not possible with the current release of glib, unless one + want to end up with an application that constantly requires some + CPU to run, even when being idle. While this seems to be ok for + today's Java virtual machines, it's not acceptable by KDE's + quality standards. Until glib 2.0 is released, you need to patch + glib in order to make the QGtkWidget work properly. No big deal + for most Linux users, still a hassle. And keep in mind that glib + is a fairly open system. If the component was written in some + other toolkit, it might be possible that glueing code is + impossible to get right, without wasting at least a bit of CPU. + +

The second problem is Mozilla's size. It's by no means an + ordinary component. In fact, it's a magnitude larger than the + Konqueror framework. And since Mozilla and Konqueror do not share + the same graphics toolkit, the toolkit's size has to be added to + that. It seems odd to load and unload such a huge amount of code - + and it can to lead to all kind of problems when trying to unload + it again. + +

To make things worse, Mozilla wasn't even released as final + version yet. While it is already quite usable, it's stability is + still far from being production quality. This doesn't matter too + much for a standalone browser, but can really hurt with a + component. A standalone browser usually is supposed to display one + web page. If it crashes, this page is gone, so the user simply + tries again. With a generic browser like Konqueror, there is not + just one component active at a time, but several. There might be + some directory views, an embedded console, another toplevel window + window, an imaged preview and much more. A crashing Mozilla would + take all those component with it - and leave the user with only + half of its prior desktop. + +

Imagine that some users define Mozilla to be the primary + component to handle text/html in Konqueror. After some testing, all + works well and they continue using it. A couple of days later, they + might have forgotten the configuration change they did. Whenever + they now hit a web page where Mozilla crashes, they will blame + Konqueror. This we don't want. No code is perfect, but if a crash + occurs in our code, at least it's our crash. That means, we can fix + it and we can provide newer versions. + +

Thus, from a maintainance and support point of you, it is not + acceptable for KDE to run code inprocess that is not actually + maintained or controlled by the team, at least not in the default + setup. + +

Out-of-process components

+ +

For the given reasons, it makes a lot of sense to extend KParts + over process bounderies. In addition, we also win a high degree of + toolkit and language independency. + +

To make this work, we have to identify the streamable parts of + the KParts interface and offer them via some kind of middleware. + +

We chose KDE's native desktop middleware, the desktop + communication protocol (DCOP) to establish the communication. In + addition to the fact that DCOP was explicitely designed for these + kind of tasks, there are some more benefits: +

+ + There are several DCOP implementations available. The reference + implementation is the one using C++ and Qt that is used in KDE + applications. For Mozilla, we would choose a plain ANSI-C + implementation that uses glib. + +

The following picture shows the interface structure: + +

+ +

The main thing that differs from KParts is the + XPartHost interface that is responsible for embedding a + part. The missing link now is a standard KPart component that + implements the XPartHost interface. Via this + KXPartHost component, it is possible to use any XPart + transparently as KPart without changing a single line of code: +

+ + +

On the other side of the fence, we need an implementation of + the XPartManager interface and can serve us with + XPart interfaces. We provide this through the + relatively highlevel and generic classes GtkXPartManger and + GtkXPart, as shown in the next picture: +

+ +

The GtkXPart is a standard Gtk widget that can have a MozEmbed + widget as child widget. The only code that is necessary to write + is the code used to connect the BrowserExtension + interface to the corresponding functions of Mozilla. + +

External KParts

+ +

The same technique can now be used to utilize standard KPart + components in an out-of-process fashion via the XPart system. All + we need is a KXPartManager that wraps standard KParts in + KXParts. The KXParts then export the XPart interface. The + complete structure is shown in the next picture: +

+ +

Conclusion

Although the implementation of the + external mozilla part is more a proof of concept than a finished + xpart, we have shown a clean way to realize out of process + components on top of KParts. It could also be shown that this + approach is both language and toolkit independent. + +

To accomplish this task, not a single line of code + in konqueror had to be changed. All we did was providing yet + another independent KPart component. + +

By writing a small wrapper it is possible to embed any kind of + visual component. In addition, we can provide generic wrappers for + any kind of visual component model, as long as those models are + powerful enough to describe their interfaces and GUI requirements + at runtime. This includes KParts (eg. KOffice components), Bonobo + components (like the Nautilus MP3 viewer) and Uno components + provided by OpenOffice (formerly known as StarOffice). + +

+
Matthias Ettrich
+
Simon Hausmann
+
Lars Knoll
+ + +Last modified: Tue Apr 3 20:39:13 CEST 2001 + + + diff --git a/xparts/doc/xparts.png b/xparts/doc/xparts.png new file mode 100644 index 00000000..3193842a Binary files /dev/null and b/xparts/doc/xparts.png differ -- cgit v1.2.1