[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: DCOP without X server
From:       Stephan Kulow <coolo () kde ! org>
Date:       2001-11-30 14:26:25
[Download RAW message or body]

On Friday, 30. November 2001 15:16, David Faure wrote:
> On Friday 30 November 2001 15:09, Stephan Kulow wrote:
> > On Friday, 30. November 2001 13:54, Matthias Ettrich wrote:
> > > On Friday 30 November 2001 13:23, Cornelius Schumacher wrote:
> > > > Is there a way to use DCOP in a program, which doesn't have a
> > > > connection to a X server? This would be intereting for daemon-like
> > > > programs.
> > >
> > > Here I go again: DCOP is based on libICE. libICE does NOT requires Xlib
> > > or a running X server. It is designed to work without the X Window
> > > System (although it happens to live in the same software archive).
> > >
> > > > I'm also asking, because the KUniqueApplication constructor has this
> > > > GUIEnabled flag. Where is the point in creating a KUniqueApplciation
> > > > without GUI, when the X server connection is required by the DCOP
> > > > stuff anyway?
> > >
> > > Because it is not required.
> > >
> > > Where do you guys always get the idea from that dcop has anything to do
> > > with Xlib or a XServer?
> >
> > Hmm, is this a possible reason for the confusion?
> >
> > coolo@sein#~>DISPLAY= dcopserver
> > Aborting. $DISPLAY is not set.
>
> Yes, and that's because of the case where the user runs multiple X sessions
> from the same account, on the same host - IIRC we decided it should have
> different dcop servers in that case.
> Maybe the fix, to make dcop available without X too, is as simple as
> "if no DISPLAY is set, then use ~/.DCOPserver_NODISPLAY instead of
> ~/.DCOPserver_$DISPLAY" ?

Yes, DCOP without dedicated DISPLAY is a session on it's own. E.g. a daemon 
without X connection can't expect to give a process on the user's desktop a 
command (at least I hope so). But e.g. a kioslave should be useable in that 
session (even though for this case it may be easier to develop from process 
forked slaves :)

Greetings, Stephan

[prev in list] [next in list] [prev in thread] [next in thread]