Re: bonobo activation environment matching and DISPLAY

On Fri, 2004-08-20 at 22:15, Gustavo J. A. M. Carneiro wrote:
> ...> > We're wondering what the best fix is - should we just special case the
> > > matching of DISPLAY in bonobo-activation, rather than trying to enforce
> > > consistent values of DISPLAY among desktop processes?  Or should we call
> > > gdk_get_display and re-normalize the environment of the client before
> > > doing a bonobo-activation query?
> > 
> > 
> > Nautilus does this early in main(), before registering to b-a to
> > canonicalize the DISPLAY env var:
> > 
> > 	/* Need to set this to the canonical DISPLAY value, since
> > 	   thats where we're registering per-display components */
> > 	bonobo_activation_set_activation_env_value ("DISPLAY",
> > 						    gdk_display_get_name (gdk_display_get_default()));
>   This is for the old "bonobo activation environment" API, which works
> with an artificial environment.  The new bonobo:environment property of
> <oaf_server> matches against the real unix process environment. 
> Therefore, to achieve the same effect with this method one one have to
> do the same as in nautilus, but replacing
> bonobo_activation_set_activation_env_value with setenv (or g_setenv).

Is this the right thing to do?  It seems to me that since we are mucking
about with the env, it would be safer to use the
set_activation_env_value rather than actually do a setenv() in the

What we ended up doing in at-spi is using a new bonobo-activation
environment variable, which we call AT_SPI_DISPLAY, and create from
DISPLAY at runtime in both the server and in querying clients.  In this
way we can control the correlation between DISPLAY and at-spi-registry
more effectively.  For instance, in the course of discussing this
internally we concluded that indeed we wanted one at-spi-registryd per
x-server (but not per-screen), at least in most scenarios, therefore we
needed to strip the screen number off of DISPLAY in some cases anyway.

I assume that your note above about the bonobo:environment property
doesn't mean that the "artificial environment", i.e. the constructed
req_env, is deprecated...  let me know if I've missed something.  


- Bill

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]