Re: terminal servers

[Vlad Harchev <hvv hippo ru>]

On Mon, 12 Nov 2001, Maciej Stachowiak wrote:

 Hi, 

 I would like to add that currently oafd is severely broken with respect to
component activation.
 It doesn't export any environment variables of the component activator
(including LANG, XFT_*, LC_*, GTK_RC_FILES, all GDK_* and GTK_*).

 See http://bugzilla.gnome.org/show_bug.cgi?id=60701

 So an instance of the component should exist for each unique set of
(important?) environment variables of the component's activator, not only for
each DISPLAY. And it should be the default behaviour - there shouldn't be any
need to activate component specially in order to be able to run it on
several different DISPLAYs. All "important" environment variables of the
activator should be exported to the component.

 Best regards,
  -Vlad

> On 12Nov2001 03:37PM (-0500), Jody Goldberg wrote:
> > On Mon, Nov 12, 2001 at 03:17:26PM -0500, Havoc Pennington wrote:
> > > 
> > >  - Nautilus doesn't properly register itself per-display or something,
> > >    so trying to start it on a second terminal results in displaying a
> > >    new window on first terminal
> 
> Specifically this problem is with the Application object. To get it to
> work right, you would need the Application object to be per-display,
> but the metadata server to be display-independent. And then you get
> nasty issues when you run nautilus on one display and then another,
> and then close the one running on the first display; it couldn't
> actually exit because the second nautilus would be using it as a
> metadata server.
> 
> That problem would go away when/if we get metadata support in
> gnome-vfs and thus a separate metadata server.
>  
> > If this is what I think it is then it is more of an oaf issue than a
> > nautilus problem. 
> 
> oaf supports the feature, but components need to register themselves
> per display explicitly. The way to do this is to register as
> "DISPLAY,OAFIID" instead of just "OAFIID". Some of the Nautilus
> components do this properly.
> 
> > The same thing happens if I create a guppi component on one display
> > then exit gnumeric and do it again from another display.  My bet is
> > that the first run starts an oafd that inherits the first DISPLAY
> > setting, then later apps use the wrong display.
> 
> Nope, oafd passes the app's DISPLAY, not it's own, when launching
> components. Or rather, it did last I checked, but I don't test this
> feature regularly.
> 
> However, if the component is not registered per-display, later apps
> that use it will get the same server (on the same display) as previous
> apps that ran it. This can be exacerbated by component process leaks.
> 
> > Has this been addressed in bonobo-activation ?
> 
> I haven't made changes in this area but it ought to work no worse than
> before.
> 
> Ideally bonobo-activation would not have to care about this issue.
> 
> The best solution would be multi-DISPLAY support in gtk+, and a change
> to bonobo to pass the DISPLAY as well as the X window ID when creating
> a Control.
> 
> Perhaps that change should be made to bonobo now at the IDL level,
> since we are expecting multihead support in 2.2.
> 
> Regards,
> 
> Maciej
> _______________________________________________
> gnome-hackers mailing list
> gnome-hackers gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-hackers
> 

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers