faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
thread
|
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 |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
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 )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
