summaryrefslogtreecommitdiffstats
path: root/xparts/doc
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-05 21:58:19 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-05 21:58:19 -0600
commit26abe38d0748c549f2458da57507614fad599d83 (patch)
tree02bc387417c25ba4cc5744f8addf7e3dacf24292 /xparts/doc
parente1a0e352b6ead69ed6f55476272ace842fbbdf74 (diff)
downloadtdebindings-26abe38d0748c549f2458da57507614fad599d83.tar.gz
tdebindings-26abe38d0748c549f2458da57507614fad599d83.zip
Fix retquire
Diffstat (limited to 'xparts/doc')
-rw-r--r--xparts/doc/xparts.html14
1 files changed, 7 insertions, 7 deletions
diff --git a/xparts/doc/xparts.html b/xparts/doc/xparts.html
index ceb67563..ad51c5a1 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 retquirements.
+ used in settings with different requirements.
<p>Take the fourth item, it's comprehensive power while
- maintaining simplicity. This was one of the main retquirements of
+ 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 retquirements for integrated components
+ 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
@@ -108,7 +108,7 @@
<li>If a component handles the event loop differently from the
embedding application, an complete event loop merger is
- retquired. This glueing code can be tricky and might not work well
+ required. 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 retquired by
+ 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
@@ -157,7 +157,7 @@
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 retquires some
+ 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
@@ -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 retquirements
+ 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).