Starting a program via DCOP?

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent

Starting a program via DCOP?
by Amazed of London on Saturday 29/Sep/2001, @12:53

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?

Related Links

·   Articles on Developer
·   Also by Amazed of London
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: Starting a program via DCOP?
by Evan "JabberWokky" E. on Saturday 29/Sep/2001, @16:42

: 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

[ Reply To This | View ]

Re: Starting a program via DCOP?
by Amazed of London on Saturday 29/Sep/2001, @20:57

> 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:

<command name>-<PID>

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.

[ Reply To This | View ]

Re: Starting a program via DCOP?
by Evan "JabberWokky" E. on Sunday 30/Sep/2001, @00:39

: 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

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"I guess my process varies from time to time." -- George Staikos
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.