Two New DCOP Tutorials

DCOP
is KDE's interprocess communication (IPC)/remote procedure call (RPC)
technology. DCOP provides a simple protocol with authentication over TCP/IP
or Unix domain sockets. Two new complementary tutorials on DCOP have just been made available
at the KDE developer site. The
first
one
, written by Richard
Moore
and entitled Creating a DCOP Interface, explains how to
add a DCOP interface to a simple KDE application, and illustrates how it can be
used. According to Richard, "Adding the interface is easy.
The example defines a number of methods of different types, and as you'll
see all these methods can be quickly used via DCOP
." The
second
one
, written by Olaf
Zanger
and entitled Automation of KDE2,
introduces DCOP as an automation interface (e.g., using
scripts to access another application's DCOP interface). According to Olaf, the tutorial is useful to "learn
how to access features you used to tackle with your mouse or key-combinations
with your favourite scripting environment
."

Dot Categories: 

Comments

Using DCOP as an automation interface from scripst is very interesting. Do someone know if KDE plans to choose a default script language for all KDE programs like ARexx on the Amiga? I think a script language like ARexx is one part that is missed on KDE. I think there is a Rexx language (Regina) for Linux. But in my opinion Rexx needs programs with Rexx ports (Rexx communication interface). Maybe a Rexx interpreter for KDE can use the DCOP interface for communication with the applications.

by Simon (not verified)

Perhaps Javascript would be a good default scripting langauge.

* It was designed as scripting language in the first place.
* It's quite easy to use/learn.
* It's supports Objects and OO in a simple/natural way. (Unlike Perl for example).
* KDE already has a Javascript interpreter.
* Many people know it already, thanks to the web.
* It's C style syntax won't freak out the unix types too much.

Perfect candidate IMHO.

Also developers need to add DCOP interfaces that power users can use for day-to-day scripting.

It would also be nice if you could launch scripts from a menu inside every KDE program (well, at least the major apps). Kind of like how most Amiga apps would let you run ARexx scripts without leaving the app.

--
Simon

by David Walser (not verified)

I thought I heard something about making Python the standard scripting language for KDE a while back. Doesn't some of KOffice already use it?

by Peter "proc" Rockai (not verified)

The best way IMHO is to make DCOP interface accessible from as many languages as possible and leave the actual choice on user.

by Peter (not verified)

No, no, ruby is far better...

See, there is a big problem what default should be. What I think would be pretty cool, are some standard bindigs which are connected to all major scripting languages.
This way everybody can chose whatever fits best. I'm not sure how this can be realised. Perhaps somebody could tell me if and how this is possible.

Peter

by Morty (not verified)

Look in kdebindings.
Java and Python are already there, and
Perl maybe even Ruby.

by Carbon (not verified)

Problem with JS is that it's (iirc) closed source.

by David Joham (not verified)

Both Konqueror and Mozilla have open-source implementations of JavaScript...

David

by Richard Moore (not verified)

It's certainly true that embedding KJS (Konq's javascript engine) is easy - I wrote some code last week which embeds it, and it only took an hour. I've since added a bridge that lets the scripts access the properties of any QObject (like the Qt-DCOP bridge). It would even be easy enough to write a plugin that uses this stuff (I already made a KPart) and this lets it extend existing apps thanks to KParts.

There are plenty of other decent script engines and embedding perl or python is no harder than javascript, and people want to use these too. The big advantage of using DCOP for scripting, is that you can use any language you want to (or even mix several languages). In addition, the Qt-DCOP bridge lets you access the the interfaces of objects that the developer did not specifically expose for scripts.

Rich.

by Simon Edwards (not verified)

You wouldn't even have to embed it per se. You could just put the JS interpretter in an external prog and have programs start it themselves and also pass the name of the script to run and maybe the name of the calling program (for convinenence). By keeping stuff out of process mem you could have as many different interpretters as you wanted, but without any extra library/startup overhead.

--
Simon

by Richard Moore (not verified)

There are advantages and disadvantages to both approaches, the nice thing is we have the choice (and you can even use both in the same app).

Rich.

by Oliver Stieber (not verified)

Did you notice if it would be easy to get all the dcop events to be sent to another application/object so that they could be recorded.
This would be great for scripting and producing 'tutorials' for applications instead of just the plain old docbook help.

by Olivier LAHAYE (not verified)

I think that would be a realy great thing for KDE. I had an Amiga in the past, and using AREXX from a math program that uses DPaint to draw its results was wonderfull.

But I agree very much that javascript is a perfect candidate. More over, I think that it would help find more bugs (because of more complex usages and different contexts)

I've seen some other posts speaking about other languages. Of course, it could be cool (more programmers), but at last, it may confuse the user. Imagine that you have to use a javascript lib-package from a pyton plugin. ("What a mess").

Or imagine just a pyton package for emacs that uses lisp libs... somewhat strange. More over, it can add bugs.

If you look at internet explorer: it can be scripted in javascript and in vbscript. So bugs are double, because you have javascript-engine bugs and vbscript-engine bugs. Behaviours are differents if you choose one or another language. (for example: regexp doesn't behave the same in ie6 :-( ). If you had an enhancement in one language, or if you change a behaviour in one language, you have to report it in the others (ex: regexp, security, ...). I think it could be difficult to synchronise such "big details".

And finaly, concerning the implementation devel speed. If one language is better implemented than another, other teams working on others languages implementation will have less developpers and become marginal. At the end, this could be a big lost of time, and I think that dividing efforts is not good at this time.

A last point I don't know is: can vbscript be easily converted into javascript?
1) yes => one language is good, and you can import M$ Office docs with scripting
2) No => we are forced to implement multilanguage like KBasic or other vblike.

(IMHO)

by Bernd Gehrmann (not verified)

There is no point in using a "javascript-lib-package",
simply because there *aren't* libraries for JavaScript.
JavaScript was made to script web pages, not more, not
less. It is not designed as a general purpose language,
and it doesn't have standard techniques for extensions.

In contrast, general purpose languages like Python and
Tcl are designed for extending applications from the
beginning. In particular, Python is extensible to the
bone, there is no difference between an extension class
and a Python class. Look at the scripting engine of
KDevelop in the HEAD branch. It makes DCOP objects fully
transparently available.

From the Python programmer's point of view, a DCOP object
looks exactly like a Python object. He can also connect
arbitrary DCOP signals to a Python function. From the
application programmer's point of view, there is no Python
at all. He just writes DCOP interfaces with methods and
signals. It is irrelevant from which language they are used.
You could also write a bridge for Tcl that does the same.

by Olivier LAHAYE (not verified)

javascript can use libs just like serverside javascript does, and you can include new javascript objects. You can create some objects and classes just like java.(even in html you can do that by including .js files defining classes using the syntax)

Concerning dcop or otherthing access, it would be done the same way you access activeX objects or java applet. The extention extends the local DOM with objects and functions.

let suppose we want to load a new document called "foo.doc" in kword

then a document.open("foo.doc") would do the job.
you could also let the user choose the document with the following line:
document.menu.file.open.select();
or you could rename that menu:
document.menu.open.rename("Open a File");

Now let say you want to include a picture:
oMyPic=document.createElement("IMG")
oMyPic.src="foo.png";
document.appendChild(oMyPic);

Now, more complex thing: you want to include a speadsheet:
oMyEmbedSpreadSheet=document.createElement("EMBED");
oMyEmbedSpreadSheet.src="foo.xls";
document.appendChild(oMyEmbedSpreadSheet);

Now you want to create an empty embeded kspread object:
oMyEmptySheet=new Kspread("Sheet1","Sheet2");
oMyEmbedEmptySheet=document.createElement("EMBED");
oMyEmbedSpreadSheet.nodeValue=oMyEmptySheet;
document.appendChild(oMyEmbedEmptySheet);

Now you want to set the background of the 1st cell of the first sheet to red:
oMyEmptySheet.sheet[0].cells[0][0].style.background="red";

As you see, oMySpreadSheet would just behave as a standard html object with datas and methods.
And by that way, exporting thoses pages to the net with scripting would be possible.

Javascript also include security concepts.

that was just my 2 cents.

PS: don't try to think in terms of netscrape 4.x javascript, its DOM is so poor that of cours almost nothing complex is possible and most of its usage is reserved to string computation and document.write().

by Olivier LAHAYE (not verified)

javascript can use libs just like serverside javascript does, and you can include new javascript objects. You can create some objects and classes just like java.(even in html you can do that by including .js files defining classes using the syntax)

Concerning dcop or otherthing access, it would be done the same way you access activeX objects or java applet. The extention extends the local DOM with objects and functions.

let suppose we want to load a new document called "foo.doc" in kword

then a document.open("foo.doc") would do the job.
you could also let the user choose the document with the following line:
document.menu.file.open.select();
or you could rename that menu:
document.menu.open.rename("Open a File");

Now let say you want to include a picture:
oMyPic=document.createElement("IMG")
oMyPic.src="foo.png";
document.appendChild(oMyPic);

Now, more complex thing: you want to include a speadsheet:
oMyEmbedSpreadSheet=document.createElement("EMBED");
oMyEmbedSpreadSheet.src="foo.xls";
document.appendChild(oMyEmbedSpreadSheet);

Now you want to create an empty embeded kspread object:
oMyEmptySheet=new Kspread("Sheet1","Sheet2");
oMyEmbedEmptySheet=document.createElement("EMBED");
oMyEmbedSpreadSheet.nodeValue=oMyEmptySheet;
document.appendChild(oMyEmbedEmptySheet);

Now you want to set the background of the 1st cell of the first sheet to red:
oMyEmptySheet.sheet[0].cells[0][0].style.background="red";

As you see, oMySpreadSheet would just behave as a standard html object with datas and methods.

Note that you could also have acces to a DCOP object and its methods and variables in the same way. (although, the purpose of a scripting language is maily to automatize things that can often be do by hand. I think it would be a bad idea to write plugins with it (even if possible). Just look at msword or other scriptable programs. Scripts are only used to automatize the behaviour of the document. I've never seen a vbscript that extends M$ Word behaviour)

By that way, exporting thoses pages to the net INCLUDING scripting would be less difficult.

Javascript also include security concepts.

that was just my 2 cents.

PS: don't try to think in terms of netscrape 4.x javascript, its DOM is so poor that of cours almost nothing complex is possible and most of its usage is reserved to string computation and document.write().

by Johnny Andersson (not verified)

I've also been missing ARexx. I never really gave DCOP much thought; however, having read these tutorials, I understand it's a lot more versatile than I thought.

by Johnny Andersson (not verified)

I've also been missing ARexx. I never really gave DCOP much thought; however, having read these tutorials, I understand it's a lot more versatile than I thought.

by Alec Smith (not verified)

You can use ANY language, if you use the XMLRPC daemon to talk to DCOP

http://developer.kde.org/documentation/library/kdeqt/kde3arch/xmlrpc.html

by Greg (not verified)

isn't it?

Can't I create a link on an html page like:

exec:/path/to/some/program

And have konqui execute that program?

(Just wondering)

by Richard Moore (not verified)

No, you can't. The exec protocol is only available to the about pages.

Rich.

by not me (not verified)

How does Konqui decide whether or not to allow a page to execute stuff?

by David Faure (not verified)

The about page is a special KParts component (based on KHTML obviously).

There is no "one Konqui", there are many components in it.

No "exec:/" in an html page is going to do anything - AND, this has nothing to do with Javascript.

by David Faure (not verified)

> nothing to do with Javascript.
nor with DCOP either ;)

does that have something to do with dcop ?

by Jeremy Petzold (not verified)

I know this is so far off the topic that I should be flamed, but I had nowhere else to go. I did searches on google/google groups, cheaked all relevent sites and on and on. I have found no answer and plead for your help.....

I just installed KDE 2.2.1, I have SUSE 7.2, I set up my CDburner and I want to use KIOSLAVE audiocd:/ but it tells me that:

the file or folder
/
can not be found

I tried to CHMOD 666 cdrom and cdrecorder but to no avail

does anyone know what is wrong??

thank-you, I will never Off post again, thank-you

Jeremy

by emmanuel (not verified)

don't know but just intuiting...
what about cdrom:, that is WITHOUT THE "/" ?

by Jeremy Petzold (not verified)

no, thats not it, I get it when I select the services button and click on audiocd. it has worked before on another system I have used, and it worked on my machine for 2.2, but in 2.2.1 it is not working.

does audiocd scan for hdx only? if so could it be because I have the cdburner working and used the ide-scsi module? if so, how would I correct that?

by someone (not verified)

It's so much the worse you recognize it being off topic but post nevertheless.
There are enough newsgroups and mailing-lists to discuss such problems!

by Jeremy Petzold (not verified)

I have attempted that.

by David Bishop (not verified)

See the archives for the debian-kde mailing list for the solution to your problem (lists.debian.org). Search for "audio cd" or somesuch.

by L.Lunak (not verified)

'Note that DCOPDemoIface is a virtual base class for the demo widget, there's no need to explain the details of the implications of this but it is important to make sure you don't forget'.
I'd like to know the details. I don't see a single reason for doing so.

by rtyrty (not verified)

rtyrtyrty

by Amazed of London (not verified)

In Olaf's tutorials, I find it rather disturbing to see programs started in DCOP scripts like this:

konqueror &
sleep 3
dcop konqueror whatever..

This is really really really yucky. If Konqui happens to take more than those 3 seconds to start up, for whatever reason, then the whole script will fail. This also means that scripts like this are totally non-portable between machines.

Is there really no way of starting an application via DCOP and having this DCOP command block until the app is started, then return the pid or (better yet) the DCOP interface name of the app?

It would be better still if DCOP returned the existing interface name if the app is running and it is a KUniqueApplication, returned -1 if the app started but has no DCOP interface, and perhaps returns -2 if some other error occurred like the app crashed on startup.

I'm not much of a hacker but this seems vital if DCOP is going to be anything but a toy.

Along the same lines, is there any standard way of quitting an app through DCOP?

by Evan "JabberWok... (not verified)

: konqueror &
: sleep 3
: dcop konqueror whatever..

: This is really really really yucky. If Konqui happens to take more than those 3 seconds to start up[...]

The quick answer is that it should be:

konqueror && dcop konqueror whatever..

: It would be better still if DCOP returned the existing interface name[...]

I think you might be confusing dcop with DCOP... i.e., DCOP the interface, which is accessable through a variety of languages like C++ and Python, and dcop the application that allows you to access DCOP through the command line.

Although I love DCOP, I agree that dcop could use a bit of work (like being able to format output based on command line paramaters and such).

--
Evan

by Amazed of London (not verified)

> The quick answer is that it should be:
> konqueror && dcop konqueror whatever..

doh! You are of course correct. However, this approach (starting apps manually rather than through DCOP) has its limitations...

Imagine a scenario where you are using DCOP over XMLRPC to control an application on a remote computer. Now, in order to start an app on that remote computer, you have to ssh in, set an appropriate DISPLAY environment variable, then start the app. But if you have ssh access to the machine, then what's the point in using DCOP over XMLRPC? Why not just use the dcop command that's on the remote computer?

This is the reason (I think) that nobody really used xmlrpcd in KDE 2.x and it is now not started by default in HEAD...

As for DCOP vs dcop, no, I'm fairly sure I'm not confusing them.

When an app registers its first DCOP interface, dcopserver assigns the app a name to be used within DCOP space. If the app is not a KUniqueApplication, then the name assigned is formatted like this:

-

e.g. konqueror-15357

So, in order for you to know how to even list the DCOP interfaces for an app that you have started from your script, you need to know exactly what the application is called (easy), whether the app is a KUniqueApplication or not, and if it isn't, then you need to know its PID (not really easy at all if you want it to be foolproof).

How do you then deal with apps that can be either a KUniqueApplication or not depending upon their settings, e.g. noatun, and may thus either be noatun or noatun-15967 in DCOP space?

A way of starting apps via DCOP, that returns the name of the app in DCOP space would solve both these problems straight away.

Please do tell me if I've missed something blindingly obvious.

by Evan "JabberWok... (not verified)

: Please do tell me if I've missed something blindingly obvious.

Nope - what you talk about for extending dcop (the application) makes sense. It's just that if you're using DCOP (the protocol) in a "real" language, then you don't need all of that (since exec() and family return pid in most languages).

Seems to me that I've seen a program or bash command that returns the pid of a given command as the errorlevel. That would work, and would make me feel better than dcop spawning the program.

--
Evan

by AC (not verified)

Anybody knows what's happend to the Kernel Cousin KDE? In the beginning there were almost weekly summaries of the KDE developper's mailing lists, and now the latest issue is still 21th of August or something like that.

by not me (not verified)

Yeah, I miss it as well. I was subscribed to some mailing lists over the summer but I don't have time to read them now and I'd really like a summary of what's happening every week. Where are you, Aaron J. Seigo?

by not me (not verified)

Oh, a quick trip to lists.kde.org shows the answer: Aaron's busy too. Well, I can certainly understand that. Hope you get some free time soon, Aaron!