[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-i18n
Subject: Re: OpenURL event (was Re: kdebase/konqueror)
From: Simon Hausmann <tronical () gmx ! net>
Date: 1999-03-02 18:01:30
[Download RAW message or body]
On Mon, 01 Mar 1999, David Faure wrote:
[...]
>
>Then why use events for talking to the view ? I don't get it.
>
We use events instead of plain interface methods (in regard to the views
as well as to the mainview) because of the filtering, that's the point IMHO.
I attached three files of Torben's KOM/OP article containing some nice
reasons/explanations. (I forgot the url where the complete article is located
but as far as I remember there's a link somewhere on developer.kde.org .
Otherwise I can send it to you, I've got a complete copy of the article on my
harddisk) .
Ciao,
Simon
--
Simon Hausmann - Tronical^Colorfast - <tronical@gmx.net> - IRCNet #colorfast
we have joy, we have fun, we have linux on our sun
["article-2.html" (text/html)]
<HTML>
<HEAD>
<TITLE>Open Parts --- a free object model for Unix: CORBA-based KDE Object Model</TITLE>
</HEAD>
<BODY>
<A HREF="article-1.html">Previous</A>
<A HREF="article-3.html">Next</A>
<A HREF="article.html#toc2">Table of Contents</A>
<HR>
<H2><A NAME="s2">2. CORBA-based KDE Object Model</A></H2>
<P>Yet, CORBA alone is not enough, as the standard only describes how distributed
objects communicate; the COSS (CORBA Standard Services) define interfaces
for a whole range of uses , for example trading, security,
transactions and license management. Again, it is obvious that a desktop did
not play an important role when designing CORBA. The nearly indispensable
event service does not even support event filtering; further it lacks a
mechanism for callbacks. So, X11 and CORBA must be made work together. Reason enough to
enhance CORBA´s object model (conforming to the standard, of course).
</P>
<P>The KDE Object Model (KOM) makes life easier for a programmer by automatically giving
each object a base set of functionality. That is event handling in the first
place. Each KOM object can receive events. An event consists of an arbitrary
data structure (<EM>CORBA::Any</EM>) and a string, describing the type of the event, for
example Desktop/Font/ChangeFont or Desktop/Color. By that name, an object can
decide whether it is interested in that event at all, and tell how the unknown
data structure is to be interpreted semantically.
</P>
<HR>
<A HREF="article-1.html">Previous</A>
<A HREF="article-3.html">Next</A>
<A HREF="article.html#toc2">Table of Contents</A>
</BODY>
</HTML>
["article-3.html" (text/html)]
<HTML>
<HEAD>
<TITLE>Open Parts --- a free object model for Unix: Flexibility with events and filters</TITLE>
</HEAD>
<BODY>
<A HREF="article-2.html">Previous</A>
<A HREF="article-4.html">Next</A>
<A HREF="article.html#toc3">Table of Contents</A>
<HR>
<H2><A NAME="s3">3. Flexibility with events and filters</A></H2>
<P>
</P>
<P>An important aspect when processing events is filtering. It allows the developer
to enhance the functionality of a program without having to change the sources.
There are three types of filters: those which merely recognize events, those
which are allowed to change or discard events, and those which finally process
them. The sense of this model can be shown with a simple WWW browser example: If
a program wants the browser to open a new URL, it has to send it an event. To
enhance the browser with a history function, the user only has to plug a
filter of the first category into the browser. This filter can record all URLs,
thereby managing a history function. A tool for blocking certain pages (for
child protection for example) belongs to category two: If the URL is rated
unsuitable for children, the filter discards the event or replaces the URL in it
with a different one. If the Browser does not support <EM>mailto</EM>, we need a third
category filter: upon arrival of a <EM>URLOpen event</EM> with <EM>mailto:joe@doe</EM> in it,
the event is discarded from the browser's point of view, but the filter offers
an alternative implementation.
</P>
<P>The mail filter is quite important, as in CORBA only interfaces are inherited,
not implementations. It would not be possible to derive from the browser object
and to just overload the function that opens a new URL. The event model does not
just solve this problem, it enables developers to install several enhancements
at the same time. A second filter, filtering FTP URLs for example, can be easily
installed in addition. It is important that an user can plug-in an arbitrary
number of such filters at run-time. A filter is installed this way:
</P>
<P>
<BLOCKQUOTE><CODE>
<HR>
<PRE>
KOM::EventTypeSeq types;
types.length (1);
types [0] = CORBA::string_dup ("OpenURL");
browser->installEventFilter ( this, "eventFilter", types);
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</P>
<P>Now, all you have to do is wait for events:
</P>
<P>
<BLOCKQUOTE><CODE>
<HR>
<PRE>
boolean MailFilter::eventFilter (in Object obj, in EventType type, in any value)
{
if ( type == "OpenURL" )
{
char *p;
if (( value >>=p ) && strcmp (type, "mailto:", 7) == 0)
{
// open mail app
CORBA::string_free (p);
return true;
}
}
return false;
}
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</P>
<P>In order to enable an object to enhance its functionality in this way, it has to
send events to itself. When an user enters an URL in the example above, the
browser sends an event to itself. This concept can also serve for a macro
recorder, because events can be filtered, saved and re-send later. As event
handling works the same way for all KOM objects, there is now - at last - the
possibility of creating a supra-component macro recording.
</P>
<P>To avoid performance loss, filters can be installed in a way that they only
receive events whose type matches a certain expression. Desktop/Font/* would
filter all events that have to do with the font settings of the whole desktop.
</P>
<HR>
<A HREF="article-2.html">Previous</A>
<A HREF="article-4.html">Next</A>
<A HREF="article.html#toc3">Table of Contents</A>
</BODY>
</HTML>
["article-4.html" (text/html)]
<HTML>
<HEAD>
<TITLE>Open Parts --- a free object model for Unix: Callbacks with signal \
and slots</TITLE> </HEAD>
<BODY>
<A HREF="article-3.html">Previous</A>
<A HREF="article-5.html">Next</A>
<A HREF="article.html#toc4">Table of Contents</A>
<HR>
<H2><A NAME="s4">4. Callbacks with signal and slots</A></H2>
<P>In an event-driven environment, programmers have to deal with callbacks \
every
time. C offers pointers to functions for that, in C++ there are signals and
slots. A very comfortable implementation of this idea is offered by the QT
toolkit. KOM offers this technique for distributed objects as well, it uses
CORBA´s DII (Dynamic Invocation Interface) for that purpose. An object can \
be
target and sender of signals at the same time. To receive a signal, an \
object
must have a slot with a matching list of parameters. Such a slot is not
different from a usual CORBA method without return value. The lines
</P>
<P>
<BLOCKQUOTE><CODE>
<HR>
<PRE>
MySender_var s = new MySender;
MyReceiver_var r = new MyReceiver;
r.connect ( "selected", s, "myslot" );
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</P>
<P>connect two objects with each other. As soon as <EM>s</EM> emits the \
<EM>selected</EM> signal,
the function <EM>myslot</EM> of object <EM>r</EM> is called. If one of the \
objects is destroyed,
the connection between the two is released automatically. It is possible to
connect one signal to different slots and one slot to different signals.
Theoretically, it would also be possible to work with events here. Signals \
and
slots however work a lot faster and are easier to handle for the
programmer, because he/she does not have to deal with event processing. On \
the
other hand, you have to work without the accomodations of filtering.
</P>
<P>As already mentioned, derivation does not solve all the problems. The \
browser
example shows that installing multiple enhancements at run-time works only
because filters are loaded which can plug into the browser. The principle \
behind
it is called <EM>dynamic aggregation</EM>. You take a core object (the \
browser) and
enhance it by other objects (plug-ins). The interface of the browser is \
expanded
with the sum of the plug-ins' interfaces. KOM support run-time installation \
and
deinstallation of those plug-ins. Those neither have to run within the same
process nor on the same computer.
</P>
<P>An object that communicates with the browser does not notice which \
interface was
implemented by the core object and which by the plug-ins. If a client wants \
to
know whether a component supports a special interface, a simple
</P>
<P>
<BLOCKQUOTE><CODE>
<HR>
<PRE>
CORBA::Object_var obj = browser->getInterface ('IDL:/foo/bar:1.0');
</PRE>
<HR>
</CODE></BLOCKQUOTE>
</P>
<P>is enough to get a reference to that interface. It is even possible to \
load the
plug-in with the required interface at run-time. This saves a lot of \
memory,
because the plug-ins allocate ressources only then when they are really \
needed. </P>
<HR>
<A HREF="article-3.html">Previous</A>
<A HREF="article-5.html">Next</A>
<A HREF="article.html#toc4">Table of Contents</A>
</BODY>
</HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic