gnustep-dev
[Top][All Lists]
Advanced

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

Re: remote hosting


From: Fred Kiefer
Subject: Re: remote hosting
Date: Tue, 31 Jan 2006 00:00:21 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921

Hi Tim,

thank you for this long explaination. You did convince me, I am now all
in favour for your patch. Your patch seems to make scenarios possible,
that didn't work before. But this is not my area of expertice, perhaps
Adam and Richard have something to say here?

Fred


Tim McIntosh wrote:
> 
> Sorry for the confusion.  The specific case that I want to work is as 
> follows:  I have a machine running GNUstep (call it 'localhost').  I 
> log into this machine from another non-GNUstep machine (call it 
> 'remotehost') using 'Xnest' (display ":1") to connect to the xdm on 
> 'localhost'.  Thus, DISPLAY is 'remotehost:1.0' and the GNUstep 
> processes are running on 'localhost'.
> 
> This "sort of" works without the patch.  The initial processes that  are
> launched _without_ the '-NSHost' argument will correctly display  on
> 'remotehost:1.0', while printing the warning "NOTE: Only one  display
> per host fully supported."  However, the 'NSHost' default  will be
> (incorrectly) set to 'remotehost' by the code I've proposed  deleting. 
> As I understand it, this default causes the programs to  look for
> 'gdnc', 'gpbs', etc. on 'remotehost', instead of  'localhost', where
> they are actually running.
> 
> The problem gets worse when one of those initial processes (e.g. 
> GWorkspace) launches another GNUstep application via the NSWorkspace 
> methods.  Since the parent process has the 'NSHost' default set, the 
> new process will be launched with the '-NSHost' argument (see 
> NSWorkspace.m).  When the -NSHost argument is specified, the code in 
> the patched method (_initXContext) ignores the DISPLAY settings.   Thus,
> the launched applications will use 'remotehost:0.0' for the  display. 
> This leads to some surprising results when 'remotehost:0.0'  is a valid
> display.
> 
> From looking at the code, I think you would also see a similar  problem
> if you attempted to use display ":1" (or any nonzero display)  on
> 'localhost', though I haven't tried this.
> 
> I think it makes sense for the '-NSHost' argument to override the 
> DISPLAY setting, as it does today.  I think the problem is the 
> assumption that the 'NSHost' default should be set according to  DISPLAY
> if -NSHost was not explicitly specified.  As I see it, the '- NSHost'
> argument says that I want to connect to a remote GNUstep  session.  If I
> don't specify -NSHost, I'm saying I want to run  GNUstep on the local
> host and display according to the DISPLAY setting.
> 
> I realize that this is slightly less convenient in the case where you 
> want to use a remote GNUstep session on 'remotehost:0.0' and would  like
> to rely on the DISPLAY setting, but I'd rather have more control  over
> the display.  Having to specify the -NSHost argument seems  reasonable,
> especially considering that you had to do this under  OPENSTEP and you'd
> have to do it anyway if you weren't using X11.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]