signals and slots between 2 Apps?

[nupul]

Problem Statement:

You have 3 buttons layed out in one window/app A. You have a single LineEdit in a completely different window/app B. When the user clicks any Button in A, the Button name should be displayed in the LineEdit in B. (Apps A & B are independent of each other...i.e. NOT descendants of any window except the root window ofcourse).

Now, inorder to achieve this, should i have a separate "intermediate" non-gui Widget acting as a bridge or is it also possible to do so directly?

Thanks

Nupul

[wysota]

It's not Window$. You can't pass messages between apps. You have to use some other mechanism (like sockets, message queues, shared memory or other IPC mechanism -- probably X protocol has something of its own there too) -- of course both applications have to be aware of that.

[nupul]

It's not Window$. You can't pass messages between apps. You have to use some other mechanism (like sockets, message queues, shared memory or other IPC mechanism -- probably X protocol has something of its own there too) -- of course both applications have to be aware of that.

What do you suggest I can use w.r.t. Qt to achieve this...

[wysota]

It depends what do you want to achieve and in what environment. Sockets (preferably Unix Domain) and named pipes or some layer over sockets (Sun RPC, Corba, etc.) are probably the most portable, message queues probably the most universal and shared memory probably the fastest but most crude...

You can always use higher level mechanisms like dcop or dbus.

[nupul]

could you be more specific w.r.t. the example i gave at the start of the thread...on SuSe 10 KDE 3.2/Gnome 2.2

[wysota]

could you be more specific w.r.t. the example i gave at the start of the thread...on SuSe 10 KDE 3.2/Gnome 2.2

No, I can't. It can be done with any of those. The simplest way probably with dcop, but you need to implement dcop infrastructure for your Qt-only apps. The least code (in this particular case) probably with sockets or message queues.

You have to look at each of those solutions and decide which one suits you best.

[soul_rebel]

if your only using it in unix, then i would recomend making a kde app and using dcop.
if it is not important a quick and dirty solution would be just writing the information to a file, that is monitored by the other app. (you could implement read operations with a qtimer)

[nupul]

if your only using it in unix, then i would recomend making a kde app and using dcop.

Doesn't that make the system dependent on the underlying KDE? I wish to make it run on every linux distro!

if it is not important a quick and dirty solution would be just writing the information to a file, that is monitored by the other app. (you could implement read operations with a qtimer)

I can't do this, since the change in data has to reflected immediately!

Nupul

[dimitri]

I can't do this, since the change in data has to reflected immediately!

Immediately? There's no such thing :-) If it's just a question of updating the GUI, checking the file say 50 times per second ought to be enough, users will thing the application is reacting immediatly.

[wysota]

And you can use some file alternation monitor to help you.

Or provide a controller application (so something like fam) which will be notified (for example by a unix signal) that a file changed and will "emit" a unix signal to all other applications "connected" to that file. Then it's just a matter of handling such a signal in your apps. No need to implement such a loop in every app then.

BTW. Does "immediately" mean 1 second, 0.1 second, 0.01 second or what?