Re: remote hosting
Yes these seems like a good change. On Jan 30, 2006, at 4:00 PM, Fred Kiefer wrote: 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hi Tim, I read through your mail and your patch, but still don't quite get the issue you have. It is a know problem that GNUstep will complain about multiple displays and it even may not work fully correctly in that case, but what is causing you problems? What value are you using for DISPLAY? ":0.3" or ":1.0" or "localhost:1.0"? And in what way does it harm your application that NSHost gets automatically set? What value does it get set to? I would expect that having NSHost set to something like "localhost" would result in the same behaviour as not having it set at all. If this is not the case, we need to look into that. I am not sure, if your solution, forcing people to set two environment variable to matching values, is a great idea. It most likely will result in additional problems. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hi Fred, 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. Tim On Jan 30, 2006, at 4:30 AM, Fred Kiefer wrote: Hi Tim, I read through your mail and your patch, but still don't quite get the issue you have. It is a know problem that GNUstep will complain about multiple displays and it even may not work fully correctly in that case, but what is causing you problems? What value are you using for DISPLAY? ":0.3" or ":1.0" or "localhost:1.0"? And in what way does it harm your application that NSHost gets automatically set? What value does it get set to? I would expect that having NSHost set to something like "localhost" would result in the same behaviour as not having it set at all. If this is not the case, we need to look into that. I am not sure, if your solution, forcing people to set two environment variable to matching values, is a great idea. It most likely will result in additional problems. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hello,
I tried to send this message last week, but there were problems with
my list subscription so I think it ended up in a black hole somewhere.
Has anyone ever addressed the issues raised in http://lists.gnu.org/
archive/html/gnustep-dev/2002-01/msg00013.html, regarding -NSHost
support with X? I couldn't find any further discussion on this topic.
Two issues arising from recent discussions on the mailing list -
1. X systems can have multiple 'displays' (each display consisting
or a keyboard,
a mouse, and one or more screens), but the NSHost mechanism
presumes that a host is
a workstation with a single user.
Should we implement some extension to -NSHost to allow for this?
2. X systems can be dumb machines without GNUstep running, so would
not run the
pasteboard, notification centre, and workspace processes
Should we implement some mechanism whereby some other GNUstep
machine could run
the required processes on behalf of the dumb X terminal?
Ignoring, for now, the problem of supporting multiple GNUstep users
on a single host, I'd like to have the ability to use a DISPLAY
setting other than ":0.0" while using a local GNUstep session (gpbs,
gdnc, etc.). This would allow me to run GNUstep on a local display
other than ":0.0", or control a machine remotely via a dumb
Xterminal. Today, this doesn't seem to be possible, as it is assumed
that a GNUstep session is running on the remote host.
To allow this to work, I propose deleting the code that automatically
sets the "NSHost" default whenever -NSHost is not specified and
DISPLAY is defined (see attachment). This would produce the behavior
described by the table below. The only difference from today is in
case (B). The proposed change would make it necessary to specify the
-NSHost argument whenever you want to connect to a remote GNUstep
session; it does NOT attempt to address the issue of being able to
specify a display other than "remote:0.0" when using -NSHost.
-NSHost specified? DISPLAY defined? Behavior
A. NO NO Local GNUstep session,
display on local:0.0
B. NO YES Local GNUstep session,
display on $DISPLAY
C. YES NO Remote GNUstep session,
display on remote:0.0
D. YES YES Remote GNUstep session,
display on remote:0.0 (DISPLAY ignored)
This behavior seems reasonable to me, and supports my needs.
However, I'm not really familiar with the GNUstep internals, so
please set me straight if this is a bad idea. Otherwise, I'd be very
happy if someone could implement this change in the main
distribution. I could enter this as a bug report if that's the
appropriate course of action for change requests.
Thanks,
Tim McIntosh
XGServer.m.patch
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
