Re: Applications launched from dbus missing SESSION_MANAGER env. var.

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

On Seg, 2006-03-13 at 10:55 -0600, Federico Mena Quintero wrote:
> On Sun, 2006-03-12 at 19:44 +0000, Gustavo J. A. M. Carneiro wrote:
> >   I have a problem with a program that behaves badly when launched from
> > dbus[1], as opposed from starting manually from terminal, run dialog, or
> > deskbar applet.  To see what was going on, I extracted the environment
> > of the process in both situations.  The attached diff shows how the
> > environments differ (env2.good = launched from deskbar, env2.bad =
> > launched by dbus).  Besides the difference in DISPLAY (from "1.0" to
> > "1"), the missing SESSION_MANAGER variable jumped to my attention, as
> > well as missing GNOME_KEYRING_SOCKET.
> 
> Don't reinvent the wheel.  See how bonobo-activation-server handles this
> --- it has a mechanism to pass interesting environment variables to
> spawned children.

  I am aware of that.  First I wanted to raise awareness of the problem,
without suggesting any solution.

  But since we are discussing solutions...

  I think the bonobo-activation mechanism can be very useful, but on the
other hand it requires a lot of intelligence on the part of the clients.
They need to be aware of which env. vars. are important to pass to the
factory.  But why should my application need to be aware that
GNOME_KEYRING_SOCKET is important?  One could put the list of
interesting variables in the dbus client library, but then the same
question could be asked: why should the dbus client library be aware of
gnome keyring variables?

  Considering this, I see only two good alternatives:
             1. Havoc's proposal to add a remote API to dbus session to
                set environment variables in the session;
             2. Automatically copy _all_ environment from client to the
                activated server, always.

  But then we should perhaps also consider another bonobo activation
feature: you can mark some variables as special for determining
uniqueness of service instances.  For instance, bonoboui marks i18n
variables (LC_*, LANG*) as special, and multiple factories for the same
component may be activated if different clients with different LANG
variables request them.

  Regards,

-- 
Gustavo J. A. M. Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>
The universe is always one step beyond logic.