Re: terminal servers

[Maciej Stachowiak <mjs noisehavoc org>]

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