dbus and kde on terminalserver

[Joerg Barfurth]

Jakub Stachowski wrote:

>> we use a gentoo-box with hal/dbus support and kde (3.5.2) as a
>> terminalserver. kde uses only the system message bus bus and therefore, if
>> one of the users plug in an usb device, the will be the kde
>> mount-popup-windows for all loged in users. How can I direct the messages
>> to only one display?
>>

Is the usb device plugged into the terminal or into the server? In the
former case the system bus may not be the right place or you need
additional facilities to associate the event with a terminal and filter
away the signal from sessions on the wrong terminal.

>> Will this be addressed in kde 4?
>>

As far as the kde recipient of this is concerned, that isn't a generic
dbus issue. But how to align dealing with hardware events on terminals
(i.e. remote hardware events from the POV of the server) and
server-local hardware events is an interesting issue.

But I think most of it must be provided by the terminal server software
that is the one instance that controls the association of terminals and
server sessions or processes. Not sure whether that calls for
per-terminal buses as an additional layer between system and session or
how much effort it would be to do that.

>> O.k., this scenario isn't very useful, but we want to use it in the future
>> with gentoo-diskless-terminals. 
> 
> It is also useful in case where several people use the same machine and 
> instead of logging out they switch between X servers (kde has session 
> switching feature for some time now).
> 
>> There we need to transport the client dbus 
>> messages to the server dbus to the right session. Is there a way to do
>> that?
> 
> I think there is way to prevent application that is not on current console 
> from receiving signals or messages. It should be enough to solve this 
> problem.
> 

How is "on the current console" determined. Does this provide for
applications assuming and losing this status over time? If it does,
there also is an inherent race condition in that such a signal could be
delivered to an application that is not "on the current console" any
more by the time it is delivered. (And of course vice versa.)

In the terminal server case the concept of "*the* current console"
doesn't necessarily make much sense any more. There can be multiple
terminals, which are all equal, with none of them being "the" (or even
"a") console.

-  Jörg

-- 
Joerg Barfurth              Sun Microsystems - Desktop - Hamburg
>>>>>>>>>>>>>>>>>> using std::disclaimer <<<<<<<<<<<<<<<<<<<<<<<
Software Engineer                         joerg.barfurth at sun.com
Thin Client Software