Re: [Tigervnc-devel] Server should fail if incorrect security type passed on command line

2011-03-11 Thread Adam Tkac
On Wed, Mar 09, 2011 at 12:34:56AM -0600, DRC wrote: > In the process of testing the vncserver patch, I noticed that the server > will start up successfully even if an invalid -SecurityTypes argument is > passed. For instance, specifying > > -SecurityTypes=vnc > > will cause Xvnc to start up,

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Adam Tkac
On Thu, Mar 10, 2011 at 07:07:17AM -0600, DRC wrote: > http://www.virtualgl.org/DeveloperInfo/TigerVNCPreReleases > > -- Windows TLS refresh issue fixed (I hope) > -- New vncserver -fg switch for running TigerVNC in grid environments > -- vncserver now automatically kills Xvnc whenever the window

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Robert Goley
Just to throw my 2 cents in as well...  I would prefer this behavior be reverted as well.  I know it will end up causing us problems if for no other reason than window managers crash and we don't want everything else in our session to be taken down with them Rob

Re: [Tigervnc-devel] Server should fail if incorrect security type passed on command line

2011-03-11 Thread DRC
If you could prepare it, that would be great. On Mar 11, 2011, at 5:51 AM, Adam Tkac wrote: > On Wed, Mar 09, 2011 at 12:34:56AM -0600, DRC wrote: >> In the process of testing the vncserver patch, I noticed that the server >> will start up successfully even if an invalid -SecurityTypes argument

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread DRC
Just so I fully understand the issue, what would you normally do if the WM crashes? Is there a reasonable way to recover in that case? I am not opposed to reverting, as long as the -fg switch is kept. A user could get the same behavior by doing vncserver -fg &. On Mar 11, 2011, at 8:25 AM, Robe

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Sebastiaan Breedveld
It seems that the -fg was implemented differently than expected:  diff between old and new -system("$vncUserDir/xstartup >> " . "edString($desktopLog) . " 2>&1 &"); +if ($opt{'-fg'}) { +    system("$vncUserDir/xstartup >> " . "edString($desktopLog) . " 2>&1"

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread DRC
No, it was intentional. I was implementing both the -fg functionality and Martin's suggestion to change the default behavior. Adam and Robert objected to the change in default behavior. I am seeking clarification about the objections. On Mar 11, 2011, at 8:43 AM, Sebastiaan Breedveld wrote: >

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Adam Tkac
On Fri, Mar 11, 2011 at 08:41:02AM -0600, DRC wrote: > Just so I fully understand the issue, what would you normally do if the WM > crashes? Is there a reasonable way to recover in that case? When WM crashes then applications which are started for example from xstartup script are not terminated (

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Robert Goley
Restart the window manager and not lose any of the work we were in the middle of.  Typically, it would be the following commands in an xterm or similar: openbox&    (though this could be other WMs as well) disown exit On 03/11/2011 09:41

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Robert Goley
For less technical users or those who would not have an xterm type application up, I have setup scripts to be launched from the xstartup.  It would be called instead of calling the window manager directly.  Would look similar to the lines below. #!/bin/bash N=0

Re: [Tigervnc-devel] Improvements for Windows installer

2011-03-11 Thread Robert Goley
Have there been any additional changes regarding the refresh issue since DRC's build yesterday?  I saw some chatter about other patches but not whether they were used or were competing patches with his changes.  Overall, the windows viewer from your build yesterday is wo

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Martin Koegler
On Fri, Mar 11, 2011 at 04:05:00PM +0100, Adam Tkac wrote: > On Fri, Mar 11, 2011 at 08:41:02AM -0600, DRC wrote: > > Just so I fully understand the issue, what would you normally do if the WM > > crashes? Is there a reasonable way to recover in that case? > > When WM crashes then applications wh

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Robert Goley
You have been more fortunate then.  My users always seem to find those unknown or unlikely crashes or closes.  We have used KDE/GNOME in the past but they are kind of "heavy" and slow down the VNC session performance when using it over lower bandwidth connections.  We us

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Martin Koegler
On Fri, Mar 11, 2011 at 02:56:51PM -0500, Robert Goley wrote: > You have been more fortunate then. My users always seem to find > those unknown or unlikely crashes or closes. We have used KDE/GNOME > in the past but they are kind of "heavy" and slow down the VNC > session performance when using

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread DRC
My take on it is that we shouldn't be dictating someone's workflow. If this modification prevents people from using TigerVNC in the manner they want to use it, then we should revert it, because like I said, you can accomplish exactly the same thing with vncserver -fg & I will make the modificat

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread DRC
If you are using a display manager (gdm, etc.) then it will log you out if the WM crashes or exits. However, not everyone uses a display manager. If you are running the X server as a standalone application, then I think it will remain running if the WM crashes. Maybe I'm wrong, though. Personall

Re: [Tigervnc-devel] New pre-beta build uploaded

2011-03-11 Thread Robert Goley
You are right about how X exits. If launched from kdm/gdm it closes X when the window manager exits. When run stand alone using xinit or similar, it stays running. The whole xstartup file is basically a copy of how xinit has always worked. Beside my personal reasons for not changing the default, th