File: ch13lev1sec7.html

package info (click to toggle)
ebook-dev-kde20 200010-3
links: PTS
area: non-free
in suites: etch, etch-m68k, sarge
size: 11,428 kB
ctags: 2,726
sloc: sh: 96; makefile: 35
file content (642 lines) | stat: -rw-r--r-- 18,535 bytes
parent folder | download | duplicates (2)
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<HTML
><HEAD
><TITLE
>DCOP Use in KDE 2.0&#8212;A Few Examples</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.54"/><LINK
REL="HOME"
TITLE="KDE 2.0 Development"
HREF="index.html"/><LINK
REL="UP"
TITLE="DCOP&#8212;Desktop Communication Protocol"
HREF="ch13.html"/><LINK
REL="PREVIOUS"
TITLE="Developer Concerns and Tools in DCOP"
HREF="ch13lev1sec6.html"/><LINK
REL="NEXT"
TITLE="Summary"
HREF="ch13lev1sec8.html"/><META
HTTP-EQUIV="Content-Style-Type"
CONTENT="text/css"/><LINK
REL="stylesheet"
HREF="kde-common.css"
TYPE="text/css"/><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=iso-8859-1"/><META
HTTP-EQUIV="Content-Language"
CONTENT="en"/><LINK
REL="stylesheet"
HREF="kde-localised.css"
TYPE="text/css"
TITLE="KDE-English"/><LINK
REL="stylesheet"
HREF="kde-default.css"
TYPE="text/css"
TITLE="KDE-Default"/></HEAD
><BODY
CLASS="section"
LINK="#336699"
VLINK="#336699"
ALINK="#336699"
BGCOLOR="#FFFFFF"
><DIV
ALIGN="RIGHT"
CLASS="NAVBAR"
><P
><A
HREF="ch13lev1sec6.html"
>Prev</A
> <A
HREF="ch13lev1sec8.html"
>Next</A
> <A
HREF="index.html"
>Table of Contents</A
></P
></DIV
><DIV
CLASS="section"
><TABLE
WIDTH="100%"
CELLPADDING="0"
CELLSPACING="0"
BORDER="0"
ALIGN="CENTER"
><TR
><TD
WIDTH="90%"
><H1
CLASS="section"
><A
NAME="ch13lev1sec7"
>13.7. DCOP Use in KDE 2.0&#8212;A Few Examples</A
></H1
><P
>Perhaps that the most exciting thing about the DCOP technology is the amazingly effective way in which its use speeds up the KDE development by many orders of magnitude. The team of KDE developers made insistent attempts to use a traditional CORBA implementation as a technological basis for the accomplishment of a project's interprocess communication needs. It is now generally accepted that this was a conceptual error. One of the central reasons of this humble acceptance is exactly the outcome of the greatly successful DCOP/KParts experiment.</P
><P
>DCOP was introduced in general use in KDE's development only days after its inception. This was possible thanks to its brilliant technological simplicity and to the sound conceptual principles employed. The authors acknowledged to have been surprised by the extent to which the members of the development team currently use DCOP in all categories of KDE code. Following are a few examples of such usage.</P
><DIV
CLASS="section"
><TABLE
WIDTH="100%"
CELLPADDING="0"
CELLSPACING="0"
BORDER="0"
ALIGN="CENTER"
><TR
><TD
WIDTH="90%"
><H2
CLASS="section"
><A
NAME="ch13lev2sec12"
>13.7.1. <TT
CLASS="literal"
>KUniqueApplication</TT
></A
></H2
><P
>One visibly weak point of the KDE 1 API was the lack of an easy-to-use programming technique that would have allowed the creation of <I
CLASS="emphasis"
>unique applications</I
>. The term unique applications designates a special category of programs that don't need to&#8212;or must not&#8212;exist in more than one running instance at a time in a distinct active desktop environment session. This problem is solved in the current iteration of KDE. A special class named <TT
CLASS="literal"
>KUniqueApplication</TT
> exists now. This inherits the central <TT
CLASS="literal"
>KApplication</TT
> class. The unique application concept defines special requirements:</P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>Detecting whether previously running instances of the same application exists.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Communication with the previously running instance.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Limited control of the previously running instance.</P
></LI
></UL
><P
>These are all achieved by proper use of the DCOP technology.</P
><P
>A simplified description of the way a <TT
CLASS="literal"
>KUniqueApplication</TT
> functions follows:</P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>At construction, a DCOP client is automatically created and then attached to the DCOP server.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>The current instance of the application tries to detect whether a previously running instance of itself exists:</P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>If no previous instance exists, a proper  registration with DCOP server is automatically performed and the application proceeds with its  normal functioning.</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>If a previous instance exists, command-line parameters (and eventually programmed messages)  are passed to a special method of the object and then this instance immediately quits.</P
></LI
></UL
></LI
></UL
><P
>Typical usage of this class is simple. There are two aspects that require attention.</P
><P
>First, the existence of a previously running instance is checked by the use of the <TT
CLASS="literal"
>KUniqueApplication::start()</TT
> method, which is statically defined. It is recommended that you take advantage of the static definition of this method; that is, call it <I
CLASS="emphasis"
>before</I
> the proper construction of the main object (of type <TT
CLASS="literal"
>KUniqueApplication</TT
>). This way, fewer resources are used during startup if a previous instance already exists. Startup times are reduced by 40% in such a case. These ideas are exemplified in many places in the real KDE 2.0 code base (many applications are built as <TT
CLASS="literal"
>KUniqueApplication</TT
>s). <A
HREF="ch13lev1sec7.html#ch13list15"
>Listing 13.15</A
> offers such an exemplification as extracted from the International Keyboard application.</P
><DIV
CLASS="example"
><HR/><A
NAME="ch13list15"
></A
><P
><B
>Example 13.15. A <TT
CLASS="literal"
>KUniqueApplication</TT
> has a Special Way of Starting</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="programlisting"
>   1&nbsp;
   2&nbsp;File: kikbd/main.cpp (from real KDE-2.0 base code)
   3&nbsp;--------------------------------------------------
   4&nbsp;.
   5&nbsp;.
   6&nbsp;16:   KAboutData about("kikbd", I18N_NOOP("International Keyboard Selector"),
   7&nbsp;17:                    "2.0", I18N_NOOP("Run time selector for keyboard layout"
   8&nbsp;18:                                 "on the desktop or on individual windows"),
   9&nbsp;19:                    0, " 1998-2000 Alexander Budnik, Cristian Tibirna",
  10&nbsp;20:                    "","http://devel-home.kde.org/~kikbd");
  11&nbsp;21:   about.addAuthor("Cristian Tibirna", I18N_NOOP("Current maintainer"),
  12&nbsp;22:                   "tibirna@kde.org");
  13&nbsp;23:   about.addAuthor("Alexander Budnik", I18N_NOOP("Original author"));
  14&nbsp;24:   about.addCredit("Dimitrios Bouras", I18N_NOOP("Bug fixing"));
  15&nbsp;25:
  16&nbsp;26:   KCmdineArgs::init(argc, argv, &amp;about);
  17&nbsp;27:
  18&nbsp;28:   static KCmdLineOptions opts[] =
  19&nbsp;29:   {
  20&nbsp;30:     {"rotate", "change the keyboard layout programmatically", 0};
  21&nbsp;31:     {"reconfig", "read again the configuration,
  22&nbsp;          probably on kcmkikbd's demand", 0};
  23&nbsp;32:   };
  24&nbsp;33:
  25&nbsp;34:   KCmdLineArgs::addCmdLineOptions( opts );
  26&nbsp;35:
  27&nbsp;36:   KiKbdApplication::addCmdLineOptions();
  28&nbsp;37:   if (!KiKbdApplication::start())
  29&nbsp;38:     exit(0);
  30&nbsp;39:   KiKbdApplication appl();
  31&nbsp;40:   appl.exec();
  32&nbsp;.
  33&nbsp;.
  34&nbsp;</PRE
></TD
></TR
></TABLE
><HR/></DIV
><P
>Second, when you want to pass command-line arguments to a previously running instance of the application, you must reimplement the <TT
CLASS="literal"
>KUniqueApplication::newInstance()</TT
> method. The automatically created DCOP client passes the parameters over the desktop communication protocol from the new instance to the previously existing one (the master). The <TT
CLASS="literal"
>DCOPObject::process()</TT
> method of the master implicitly calls the special <TT
CLASS="literal"
>newInstance()</TT
> method and passes to it a string list containing the said command-line arguments, as exemplified in the <A
HREF="ch13lev1sec7.html#ch13list16"
>Listing 13.16</A
>.</P
><DIV
CLASS="example"
><HR/><A
NAME="ch13list16"
></A
><P
><B
>Example 13.16. A <TT
CLASS="literal"
>KuniqueApplication</TT
> has a Special Way of Passing Command-Line Parameters to Predecessors</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="programlisting"
>   1&nbsp;
   2&nbsp;File: kikbd/kikbd.cpp (from real KDE-2.0 base code)
   3&nbsp;--------------------------------------------------
   4&nbsp;.
   5&nbsp;.
   6&nbsp;151: int KiKbdApplication::newInstance () {
   7&nbsp;152:
   8&nbsp;153:   kdDebug(1420) &lt;&lt; "Parse cmdline args" &lt;&lt; endl;
   9&nbsp;154:   KCmdLineArgs *params = KCmdLineArgs::parsedArgs();
  10&nbsp;155:   if(params-&gt;isSet("reconfig")) {
  11&nbsp;156:     kdDebug(1420) &lt;&lt; "Remotely trigger loadConfig" &lt;&lt; endl;
  12&nbsp;157:     QTimer::singleShot(configDelay, this, SLOT(askReloadConfig()));
  13&nbsp;158:     ::exit(0);
  14&nbsp;159:   }
  15&nbsp;160:   if(params-&gt;isSet("rotate")) {
  16&nbsp;161:     kdDebug(1420) &lt;&lt; "Remotely trigger rotateKeymap" &lt;&lt; endl;
  17&nbsp;162:     QTimer::singleShot(configDelay, this, SLOT(askRotateKeyMap()));
  18&nbsp;163:     ::exit(0);
  19&nbsp;164:   }
  20&nbsp;165:
  21&nbsp;166:   params-&gt;clear();
  22&nbsp;167:
  23&nbsp;167:   //CT if it comes up to here, it's either that the params are wrong or
  24&nbsp;168:   //    that there weren't params. Either is wrong.
  25&nbsp;169:   kdDebug(1420) &lt;&lt; "Warn for bad use" &lt;&lt; endl;
  26&nbsp;170:   KMessageBox::sorry(0,
  27&nbsp;171:              i18n("Only one instance of the international keyboard "
  28&nbsp;172:               "configuration\ncan run at a given moment."),
  29&nbsp;173:              i18n("Already running"));
  30&nbsp;174:   ::exit(0);
  31&nbsp;175:
  32&nbsp;176: }
  33&nbsp;.
  34&nbsp;.
  35&nbsp;</PRE
></TD
></TR
></TABLE
><HR/></DIV
><P
>Important components of the typical KDE desktop session are making use of the <TT
CLASS="literal"
>KUniqueApplication</TT
> paradigm:</P
><UL
COMPACT="COMPACT"
><LI
STYLE="list-style-type: disc"
><P
>KDesktop</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Kicker (the KDE desktop panel)</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>KMenuEdit (the menu editor used for Kicker)</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>Klipper (KDE's enhanced clipboard manager)</P
></LI
><LI
STYLE="list-style-type: disc"
><P
>KMail</P
></LI
></UL
><P
>These are all excellent examples for a proper use of the KUniqueApplication technology.</P
></TD
><TD
WIDTH="10%"
VALIGN="BOTTOM"
ALIGN="CENTER"
><ANNMARK
NAME="ch13lev2sec12"/></TD
></TR
><ANNOTATION
NAME="ch13lev2sec12"
TITLE="KUniqueApplication"/></TABLE
></DIV
><DIV
CLASS="section"
><TABLE
WIDTH="100%"
CELLPADDING="0"
CELLSPACING="0"
BORDER="0"
ALIGN="CENTER"
><TR
><TD
WIDTH="90%"
><H2
CLASS="section"
><A
NAME="ch13lev2sec13"
>13.7.2. <TT
CLASS="literal"
>KNotify</TT
></A
></H2
><P
>Another important improvement brought by KDE 2 code base over what KDE 1 offered is the new system notifications mechanism. In a very simplified presentation, KNotify (the KDE system notifications mechanism) is constituted from a client API and an events server (running on the desktop under the name <TT
CLASS="literal"
>knotify</TT
>). Every application that wants to use the system notifications needs simply to import the <TT
CLASS="literal"
>KNotifyClient</TT
> namespace provided in the KDE libraries. Configuring events is noticeably easy (a control center module is available). There are a few types of notifications associated with an event: sounds, dialog boxes, and log file entries. The actual contents of these notifications is also configurable.</P
><P
>The notifications server remains permanently active on the desktop and is in close relation with KDE's multimedia server (<TT
CLASS="literal"
>artsd</TT
>). The communication between clients using the KNotify mechanisms and the notifications server is once again greatly facilitated by DCOP.</P
><P
>For an easy understanding of how to implement event notifications in a KDE application, it might be useful to examine the source code of KDE's window manager, kwin (especially the files kwin/events.cpp and kwin/eventsrc).</P
></TD
><TD
WIDTH="10%"
VALIGN="BOTTOM"
ALIGN="CENTER"
><ANNMARK
NAME="ch13lev2sec13"/></TD
></TR
><ANNOTATION
NAME="ch13lev2sec13"
TITLE="KNotify"/></TABLE
></DIV
><DIV
CLASS="section"
><TABLE
WIDTH="100%"
CELLPADDING="0"
CELLSPACING="0"
BORDER="0"
ALIGN="CENTER"
><TR
><TD
WIDTH="90%"
><H2
CLASS="section"
><A
NAME="ch13lev2sec14"
>13.7.3. Little Jewels: <TT
CLASS="literal"
>dcop</TT
> and <TT
CLASS="literal"
>kdcop</TT
></A
></H2
><P
><TT
CLASS="literal"
>dcop</TT
> and <TT
CLASS="literal"
>kdcop</TT
> are perhaps some of the most surprising examples of powerful usage of the desktop communications protocol. These two little tools were born during the prolific coding session that took place in Trysil, Norway, around the middle of 2000. They are amazingly capable and make use of the latest functionalities added to the DCOP API: the information mining methods (see the section <A
HREF="ch13lev1sec6.html#ch13lev2sec7"
><SPAN
CLASS="QUOTE"
>"Stay Informed"</SPAN
></A
> earlier in this chapter).</P
><P
>These two tools enable the user to browse in real time the composition of the DCOP object pool, and even invoke functions provided in the public DCOP interfaces.</P
><P
><TT
CLASS="literal"
>dcop</TT
>, or the <I
CLASS="emphasis"
>DCOP shell</I
> client, is a command-line tool. <A
HREF="ch13lev1sec7.html#ch13list17"
>Listing 13.17</A
> is a short session using <TT
CLASS="literal"
>dcop</TT
>.</P
><DIV
CLASS="example"
><HR/><A
NAME="ch13list17"
></A
><P
><B
>Example 13.17. A Desktop at the Fingertip</B
></P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><PRE
CLASS="programlisting"
>   1&nbsp;
   2&nbsp;]:~&gt; <I
CLASS="emphasis"
>dcop &#8212;help</I
>
   3&nbsp;Usage: dcop [ application [object [function [arg1] [arg2] [arg3] &#8230; ] ] ]
   4&nbsp;]:~&gt; <I
CLASS="emphasis"
>dcop</I
>
   5&nbsp;]:~&gt; <I
CLASS="emphasis"
>dcop kdesktop</I
>
   6&nbsp;]:~&gt; <I
CLASS="emphasis"
>dcop kdesktop KScreensaverIface</I
>
   7&nbsp;]:~&gt; <I
CLASS="emphasis"
>dcop kdesktop KScreensaverIface save</I
>
   8&nbsp;</PRE
></TD
></TR
></TABLE
><HR/></DIV
><P
>Enjoy!</P
><P
><TT
CLASS="literal"
>kdcop</TT
> is the counterpart of <TT
CLASS="literal"
>dcop</TT
> but with a graphical interface. The DCOP objects hierarchy is equally easy to explore or to exploit from kdcop's graphic console (see <A
HREF="ch13lev1sec7.html#ch13fig02"
>Figure 13.2</A
>).</P
><DIV
CLASS="figure"
><HR/><A
NAME="ch13fig02"
></A
><P
><B
>Figure 13.2. The <TT
CLASS="literal"
>kdcop</TT
> tool.</B
></P
><DIV
CLASS="mediaobject"
><P
><IMG
SRC="graphics/13fig02.gif"
></IMG
></P
></DIV
><HR/></DIV
></TD
><TD
WIDTH="10%"
VALIGN="BOTTOM"
ALIGN="CENTER"
><ANNMARK
NAME="ch13lev2sec14"/></TD
></TR
><ANNOTATION
NAME="ch13lev2sec14"
TITLE="Little Jewels: dcop and kdcop"/></TABLE
></DIV
><DIV
CLASS="section"
><TABLE
WIDTH="100%"
CELLPADDING="0"
CELLSPACING="0"
BORDER="0"
ALIGN="CENTER"
><TR
><TD
WIDTH="90%"
><H2
CLASS="section"
><A
NAME="ch13lev2sec15"
>13.7.4. Neighbors in Visit&#8212;dcopc, XMLRPC, and Bindings</A
></H2
><P
>DCOP benefits from an open-minded design that avoids to a large extent the use of specific KDE technologies. Yet, DCOP itself is inherently a KDE technology. Its authors are hoping, though, that DCOP will be equally well adopted outside KDE's code base. Reasons for such hopes are the elegance of the basic principles used, as well as the great convenience and performance gains that DCOP provides.</P
><P
>Along these lines, members of the KDE developer team created a fairly large collection of bindings around the DCOP programming interface.</P
><P
><I
CLASS="emphasis"
>dcopc</I
> is a fully functional interface to DCOP written in the C language by Simon Hausmann and Rik Hemsley. It is available from the KDE project's code base and is intended for programmers willing to write applications with DCOP enhancements in plain C. This effort was at the time of this writing in a development phase, but very near completion.</P
><P
><I
CLASS="emphasis"
>KXMLRPC</I
> is written by Kurt Granroth and is an interfacing solution between DCOP and the popular XML-based remote procedure call technology. XML-RPC gained a lot of attention in the past few years from developers of computing solutions for heterogeneous platforms.</P
><P
>The greatest benefit that derives from having a bridge from DCOP to XML-RPC is the flexibility in scripting KDE. Almost all important programming languages of modern times (Python, Java, Perl) are offering an XML-RPC implementation.</P
><P
>One of the most interesting successes of binding DCOP with XML-RPC is the gained capability of controlling a KDE desktop remotely, even from a Macintosh computer or from a handheld computer (during the tests, a functional Python implementation was used on the Macintosh as a source of XML-RPC commands).</P
><P
>This is made possible by the fact that the described binding mechanism provides a lightweight server for XML-RPC on each KDE desktop&#8212;very similar to a simple http server. This server is capable of receiving XML-RPC messages and acts as a DCOP client in the meantime. Proper security and authentication mechanisms are implemented in this server.</P
><P
>More details about XML-RPC are available at <A
HREF="http://helma.org/lists/listinfo/xmlrpc"
TARGET="_top"
>http://helma.org/lists/listinfo/xmlrpc</A
>.</P
><P
><I
CLASS="emphasis"
>DCOP bindings</I
> for Python were also developed recently by Torben Weis. They are currently available as a proof of concept but they already show a strong potential.</P
></TD
><TD
WIDTH="10%"
VALIGN="BOTTOM"
ALIGN="CENTER"
><ANNMARK
NAME="ch13lev2sec15"/></TD
></TR
><ANNOTATION
NAME="ch13lev2sec15"
TITLE="Neighbors in Visit&#8212;dcopc, XMLRPC, and Bindings"/></TABLE
></DIV
></TD
><TD
WIDTH="10%"
VALIGN="BOTTOM"
ALIGN="CENTER"
><ANNMARK
NAME="ch13lev1sec7"/></TD
></TR
><ANNOTATION
NAME="ch13lev1sec7"
TITLE="DCOP Use in KDE 2.0&#8212;A Few Examples"/></TABLE
></DIV
><DIV
ALIGN="RIGHT"
CLASS="NAVBAR"
><P
><A
HREF="ch13lev1sec6.html"
>Prev</A
> <A
HREF="ch13lev1sec8.html"
>Next</A
> <A
HREF="index.html"
>Table of Contents</A
></P
></DIV
><HR
WIDTH="100%"
SIZE="2"
ALIGN="CENTER"
NOSHADE="NOSHADE"/></BODY
></HTML
>