diff options
author | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2011-12-05 15:55:57 -0600 |
---|---|---|
committer | Timothy Pearson <kb9vqf@pearsoncomputing.net> | 2011-12-05 15:55:57 -0600 |
commit | 9ba04742771370f59740e32e11c5f3a1e6a1b70a (patch) | |
tree | c81c34dae2b3b1ea73801bf18a960265dc4207f7 /xparts/doc/xparts.html | |
parent | 1a96c45b22d01378202d9dc7ed9c47acd30f966e (diff) | |
download | tdebindings-9ba04742771370f59740e32e11c5f3a1e6a1b70a.tar.gz tdebindings-9ba04742771370f59740e32e11c5f3a1e6a1b70a.zip |
Initial TQt conversion
Diffstat (limited to 'xparts/doc/xparts.html')
-rw-r--r-- | xparts/doc/xparts.html | 20 |
1 files changed, 10 insertions, 10 deletions
diff --git a/xparts/doc/xparts.html b/xparts/doc/xparts.html index 0ff872be..ceb67563 100644 --- a/xparts/doc/xparts.html +++ b/xparts/doc/xparts.html @@ -76,13 +76,13 @@ <p>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. + used in settings with different retquirements. <p>Take the fourth item, it's comprehensive power while - maintaining simplicity. This was one of the main requirements of + maintaining simplicity. This was one of the main retquirements 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 + browser like Konqueror, the retquirements 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 @@ -108,7 +108,7 @@ <li>If a component handles the event loop differently from the embedding application, an complete event loop merger is - required. This glueing code can be tricky and might not work well + retquired. This glueing code can be tricky and might not work well in all cases. It's much easier for out-of-process components to provide full toolkit independence. @@ -131,7 +131,7 @@ 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 + instantiated, it dynamically loads all libraries retquired 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 @@ -140,8 +140,8 @@ <p>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 + TQGtkWidget extension available for Qt, that lets you use Gtk + widgets in your Qt applications. You simply create a TQGtkWidget 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 @@ -157,11 +157,11 @@ 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 + want to end up with an application that constantly retquires 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 + glib in order to make the TQGtkWidget 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 @@ -276,7 +276,7 @@ <p>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 + powerful enough to describe their interfaces and GUI retquirements 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). |