Hello All,
We are deep into the x2goclient code at the moment getting it to work better with vcxsrv and have a question around when the X server is started. It would appear that SSH, X and Pulse are all started, on Windows, when the application is initially launched. We can understand why SSH and Pulse are though unsure about X. Was there any technical reason why X could not be launched when a business card was selected and the login credentials entered ? Our thinking was that if it were launched then multiple sessions could be initiated each with there own display ID.
Thanks, Phil
On Wed, 2011-01-19 at 11:55 +0000, --[ UxBoD ]-- wrote:
I might add that this is not just a matter of curiosity but rather quite important. We see no other way in Windows of enabling the full screen experience for users, i.e., for those who want to work as if their X2Go desktop is their only desktop.
Because the current client launches the Windows X Server before the session parameters are chosen, it wisely puts the X Server into multi-window mode. We assume this is so that it can dynamically resize into whatever size the user wants it or to whatever size was previously used in the case of resuming a suspended session. However, it also means that the X Server will never grow larger than the entire screen EXCEPT for the Windows title bar and task bar.
This is ideal for some users who regularly use both desktops. For others, it is a nightmare where they frequently close their entire X2Go session accidentally by clicking in the top right most "x" button thinking they are closing their maximized running application or jut being generally confused by the desktop within a desktop approach. I also believe that -multiwindow, as opposed to -fullscreen and -rootless, does not grab the <ALT><TAB> sequence so users who are working primarily in the X2Go desktops cannot cycle through their windows easily and thus experience reduced productivity and increased frustration.
Our thought was that, by delaying the X Server start until after the session parameters were chosen, we could start the X Server in -fullscreen mode or -rootless (when "Available Area" is chosen) when those are the session parameters rather than a fixed size or specific application.
Phil, I know we originally spoke about "Available Area" being -multiwindow set to maximumSize() but I forgot about the <ALT><TAB> issue so we are better off making that -rootless I think.
Thanks - John
Am 19.01.2011 13:41, schrieb John A. Sullivan III:
At least for xming the alt-tab thing is a configuration option. This should be a user option in X2go, too! That would lessen part of the frustration.
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Hello John, Phil, Moritz, list,
I'll tray in this short mail to give answers on all your questions.
We would be happy to say "Good By" to Xming and old xorg-6 sources. I'll take a look on VcXsrv this week. It looks good, seems to be gpl-3 (http://sourceforge.net/projects/vcxsrv/develop) and based on the xorg git(http://vcxsrv.sourceforge.net/) git = Xorg-7. I think, John and Phil made a good experience with VcXsrv. I'll make some tests and will try to use it with x2goplugin. Possible, I'll need to make some changes, as I have made it with Xming. If VcXsrv will work good with x2goclient, we will include it in windows installer.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Wed, 2011-01-19 at 16:40 +0100, Oleksandr Shneyder wrote:
Thanks, Oleksandr. This is helpful. Phil and I (mostly Phil) do have vcxsrv up and running with libssh and on everything from Windows XP to Windows 7. It has eliminated all the crippling bugs and appears to perform better. We can probably send you the simple code changes we made if it will save you some time.
However, we still have some of our original issues. I'll restate them using your numbers from above.
Thankfully, vcxsrv is working perfectly fine in full screen and rootless as well as multi-windows so these possibilities are now open to us.
That's an important point but it still leaves us with the original dilemma: if we start X before we know the session parameters, we cannot run fullscreen or rootless. More accurately, we can but we must choose one of the three (fullscreen, rootless, or multi-window) before we know the session parameters. If we default to full screen, then we get a full screen but the session may only paint into a part of it and leave the rest of the screen black. My understanding from Phil is that it does not automatically resize the session to consume the entire windows like it does on Linux. Even if it did, fullscreen is not what all users will want (or rootless or multi-window - exactly why we should give them a choice). My guess would be the delayed start would be a worthwhile trade-off for giving users important options. Thoughts? Vehement disagreements? Insults? (well . . . hopefully no insults :) )
Argh!! That's really unfortunate. Our practical experience is that losing <ALT><TAB> significantly impacts productivity and makes the users more likely to resist transitioning to X2Go desktops.
I think I did not communicate this well in my original email. I'm not referring to the "magic pixel" to minimize the X2Go session. What we find happening VERY frequently is that a user has an application maximized in their X2Go desktop. They then want to close the application and do so by clicking on the top right most "x" box on the title bar, i.e., the shortcut to close (alongside restore and minimize). They click the top right most one because that's the habit they have built for closing maximized applications and briefly forget that the top rightmost "x" is not the one for the application but the one for the X2Go session. Thus, they accidentally close their X2Go session rather than the application. If they were working in full screen mode, the X2Go desktop would be more like their physical desktop rather than a desktop within a desktop and thus their habitual actions are less like to be a problem. It also gives <ALT><TAB> and eliminates the confusion we frequently hear among end users as they say "now where am I - my virtual world or my physical world".
Thanks again - John
Am 19.01.2011 17:03, schrieb John A. Sullivan III:
On Wed, 2011-01-19 at 16:40 +0100, Oleksandr Shneyder wrote:
Hello John, All I wrote is relative to Xming, not vcxsrv. Sure, we will change a behavior of X2Go client to make it work as good as possible with new Xserver. For example, we can start Xserver after the users choose his session, in this case x2goclient can use a time, that user need to type password to start Xserver. It is possible, that vcxsrv have not alt+tab problem in fullscreen mode. But I must do some researches before we will replace Xming with vcxsrv. I hope, I can give you an answer next week.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi John, hi Alex, hi list,
On Do 20 Jan 2011 04:57:48 CET "John A. Sullivan III" wrote:
If I understand it correctly the different setups require two
different XServer modes: fullscreen and multi-window mode.
The multi-window mode can handle many different sessions (desktop
type, rootless type), so these won't need separate XServer instances.
Thus only fullscreen sessions would need their own XServer instances.
How about that? (Or has anyone already provided this suggestion?).
I am thinking of choosing this approach for some later version of
pyhoca-gui. This would also be neat on Unix (have separate ttys for
local session and X2go sessions).
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Thu, 2011-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III: <snip>
Hi, Oleksandr. We certainly don't want to duplicate effort and we also doubt our own skill to do this well and quickly since neither Phil nor I are developers so we would prefer these changes come from you rather than us. Do you have any rough idea of when you would releasing this feature? If it's near term, we'll wait for your solution whereas, if it is going to be a while, we'll take a stab at it and submit our work to you. Thanks - John
Am 24.01.2011 19:32, schrieb John A. Sullivan III:
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hello list,
I've made some tests on Windows XP and Windows 7 to see if Xming can be replaced with VcXsrv.
The reasons to do this are:
The good news about our tests are:
The not so good news:
Conclusion: 1 - If we replace Xming by VcXsrv on Windows, it won't be possible to resize the x2gosession window using mouse. You can set window geometry in settings of x2goclient - these will be set for the whole connection time. If you want to change this geometry, you' need to reconnect to your session. 2 - We can not use VcXsrv for the x2goplugin at the moment, embedding in browser will not work.
Because of this two reasons we can't completely replace Xming with VcXsrv at the moment. I think, the issue named above must be fixed in code of VcXsrv. At least next two month I'll have no time to do this. If anybody is able to work on such a patch - please feel invited! Maybe it is also a good idea to contact the developers and ask if they have ideas how complex such a patch needs to be (John?).
What we can do now:
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Alex,
I'd favour to use the last option. Even better would be to use something like a sprintf, where one can start any server he/she wants, with any parameters, and can pass the needed parameters to the server as needed.
My two cent.
Morty
Am 28.01.2011 13:47, schrieb Oleksandr Shneyder:
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
Am 28.01.2011 14:05, schrieb Moritz Struebe:
Hi Moritz,
I think so too. But we should provide a working Xserver with windows installer. Most of windows users don't want to install additional software, they prefer, that they clicking on installer.exe and after that have working application. Early, we had included Xming installer in x2goclient installer with option not to install it. X2goclient was free configurable which Xserver it should use. And we got a lot of complains that installer is much to complex. In any case, windows user must have a working client after execution of installer is finished.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Hi Alex,
I agree with you. So what about keeping on providing Xming "silently" , which has some drawbacks, but seems to work ok, and add an option, to add an Xserver of your choice, which makes everyone happy who is not happy with Xming. Once the problems with VcXsrv are solved/fixed you can change over. I have now I dear how much trouble it is to package both of them. Thanks to hard-disc pricing and broadband Internet I don't think size is an issue here. :)
Cheers Morty
Am 28.01.2011 14:17, schrieb Oleksandr Shneyder:
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On 01/28/2011 07:47 AM, Oleksandr Shneyder wrote:
Alex, For clients, there should be a default (Xming) that just installs if the user does not do a "custom" install action.
If the user choses to do "custom" install then there should be a
choice to install whatever Xserver they like and pass a custom argument string to it.
For plugin, there should be choice of plugins that can be offered by
webserver. One built w/Xming, the other w/VcXsrv. That way either one, or both could be offered to users.
Regards, Gerry
Hi Gerry,
Am 28.01.2011 16:48, schrieb Gerry Reno:
The Plugin won't work with VcXsrv at the moment (due to the possible resize change of the container website). So I think in this case we should wait to integrate VcXsrv into the plugin.
Regards,
Heinz
On Fri, 2011-01-28 at 13:47 +0100, Oleksandr Shneyder wrote:
collectively found.
I'm very concerned about the inability to use it with the plugin (we did not have the knowledge to test that ourselves). What is the likelihood of that becoming possible?
Regarding the options, Phil and I have put some thought into the user interface. Please take these as suggestions rather than mandates - they are simply phrased as specs :) I would suggest the installer have options for Xming and vcxsrv with a sensible default - probably Xming until the issues with vcxsrv are resolved. There might even be a short note under the vcxsrv option to say that it is experimental. It should be possible to uncheck both options and install X2Go Client without an X Server (for those who already have their own).
The X2Go Client interface, as opposed to the installer, should have QRadioButton options to use Xming, vcxsrv, or other with a QLineEdit for options. The Xming and vcxsrv buttons can be disabled or hidden based upon what has been installed. I would suggest this to just "Other" because the Xming and vcxsrv options are identical. I would really prefer to not have to configure the vcxsrv command line for each user but rather use the settings from the session parameters.
Even if we ultimately standardize on vcxsrv, I suggest we still keep the option to not install it in the installer and the option to use Other in the client for those who already have a commercial (or future FOSS) Windows X Server. At least, that's how we thought it through. Thanks - John
On 01/28/2011 11:55 AM, John A. Sullivan III wrote:
Excellent idea. If the VcXsrv devs could see their Xserver in action w/x2go it might give them some insight into how to improve their Xserver.
We'd like to see the VcXsrv option for the plugin as well.
+1
I think it might be preferable to use disabling (grey-out) as opposed to hiding things. I never liked apps that mysteriously made things appear and disappear.
Allowing use of existing installed Xserver is good idea. Like Xming (commercial).
Regards, Gerry
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
I would suggest not to make this part of the installer. Of cause it should be part of the client configuration. The problem I see by modifying the installer is that some companies have already made the client installer part of their software deployment solution (a lot of people asked for a "silent install option"). As the installer is addressed to normal users, this might be a bit confusing.
Regards,
Heinz
On 01/28/2011 02:44 PM, Heinz-M. Graesing wrote:
Could the selection of Xserver be left to the packager?
So a company could create their own .deb file and make it depend on a certain Xserver package as they needed.
And then in the client they could either force a certain Xserver or just tell users how to configure for the Xserver that they use or just let them use whatever they like for an Xserver.
Regards, Gerry
Hi Gerry,
Am 28.01.2011 20:56, schrieb Gerry Reno:
VcXsrv is only needed on windows platforms - not on linux systems. So it won't be needed to integrate VcXsrv inside debian packages. If a company wants to build a own installer for windows (f.e. http://nsis.sourceforge.net/Main_Page), this too should be no problem!
Regards,
Heinz
On Fri, 2011-01-28 at 20:44 +0100, Heinz-M. Graesing wrote: think that this could be done without creating too much confusion or mangling the silent installation. If we have sensible defaults, then the average, non-savvy user would simply take the defaults. I'd also imagine the silent install will take the defaults unless parameters are passed to it to do otherwise. As always, I defer to your judgment and I may misunderstand the point you are making but those are my thoughts. Thanks - John
Am 28.01.2011 20:44, schrieb Heinz-M. Graesing:
Hello,
I have two new Ideas.
We providing a "netinstaller". With defaults option it will get x2goclient and Xming from net. There is "advanced>>" button in installer dialog, which opening for user advanced options. Advanced options are: "get vcxsrv instead of xming" and "not download Xserver".
We providing 3 nsis-installers: x2goclient+xming, x2goclient+vcxsrv, x2goclient without Xserver. The first installer is default and it is easy to found on download page. The two other installers are hidden under link "other downloads" or "experimental" or "name is not important, you understand what I mean".
I would prefer second choice, because for large installations (I think John have such one) is easier to provide a direct url to installer or installer itself then by every installation configure installer to get vcxsrv. There are less chances, that user make something wrong if he just clicks with his mouse without understanding what he making. And is easier to us (we don't need to create "net installer")
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Sat, 2011-01-29 at 09:03 +0100, Oleksandr Shneyder wrote:
<snip> Hi, Alex. Thanks for being so open to input. I also prefer option #2. I'll certainly defer to whatever you choose but I'm really not certain we need three installers. By doing so, users must still make the same decision (well, the downloading users which I suppose are more likely to be admins than regular users in large deployments, that is true); we've just shifted it from the installer to the download page.
I would think a single installer with sensible defaults, with vcxsrv labeled as experimental, and with a big warning that says, "Do not change the defaults unless you know what you are doing," would be fine and simpler to maintain. Whatever we do, it does seem like we are moving forward! Thanks - John
On 01/29/2011 03:03 AM, Oleksandr Shneyder wrote:
Alex, Option 2 looks good only I would just make it two choices: w/Xming, w/VcXsrv. And then make it so the client can launch whatever Xserver (including others besides xming, vcxsrv) the user wants to use.
Providers can then choose whether to provide links to one or both of
these packages on their webpage.
The reason that I think the installer should include at least one
Xserver is so that it cannot be possible to end up with a non-working installation.
Regards, Gerry
Hi Alex,
On Fr 28 Jan 2011 13:47:23 CET Oleksandr Shneyder wrote:
Your test results fully match my experiences with PyHoca-GUI.
Configurability is great! (that is a +1 for me for this last option).
In PyHoca-GUI I already do that. I have introduced a x2config
configuration file in ~/.x2goclient (without discussing it before). I
drop this in now and maybe you like it and we find a common solution
for XServer configuration on Windows.
Greetings, Mike
<quote> [XServers]
# known XServers, ordered by preference... # the first found XServer gets started (Pythonian list syntax -> turn into # string, maybe) known_xservers = ['VcXsrv', 'Xming', 'Cygwin-X']
[VcXsrv]
test_installed = C:\Programme\VcXsrv\vcxsrv.exe
process_name = vcxsrv.exe
# the parameters syntax is Pythonian, maybe turn this into a normal
# string...
parameters = [':40', '-clipboard', '-multiwindow', '-notrayicon',
'-nowinkill']
display = localhost:40
run_command = C:\Programme\VcXsrv\vcxsrv.exe
[Cygwin-X]
test_installed = C:\cygwin\bin\XWin.exe
process_name = XWin.exe
# the parameters syntax is Pythonian, maybe turn this into a normal
# string...
parameters = [':40', '-clipboard', '-multiwindow', '-notrayicon',
'-nowinkill']
display = localhost:40
run_command = C:\cygwin\bin\XWin.exe
[Xming]
test_installed = C:\Programme\Xming\Xming.exe
process_name = Xming.exe
# the parameters syntax is Pythonian, maybe turn this into a normal
# string...
parameters = [':40', '-clipboard', '-multiwindow', '-notrayicon',
'-nowinkill']
display = localhost:40
run_command = C:\Programme\Xming\Xming.exe
</quote>
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sa 29 Jan 2011 21:09:14 CET Mike Gabriel wrote:
typo here... the config name is
~/.x2goclient/xconfig
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi John,
On Sa 29 Jan 2011 21:19:15 CET "John A. Sullivan III" wrote:
Thanks for the reminder...
In PyHoca-GUI I currently use the Linux XServer or the Windows XServer
in multi-window mode.
How about the idea to have one global XServer in multi-window mode
running in the background, that can be used for all
<width>x<height>ish sessions.
Only if a fullscreen or rootless session is requested then a separate
XServer instance on a separate port gets started...
Main aspect of this though is performance, esp. on slow machines.
BTW: what would be the equivalent to the Linux x2goclient? Will
fullscreen sessions than start a new XServer instance on a new tty?
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sat, 2011-01-29 at 21:28 +0100, Mike Gabriel wrote:
Hi, Mike. Phil and I kicked that around quite a bit. Of course, our discussion was germane to our environment so you may arrive at a different conclusion. What you suggest was our initial thought. But then we realized that the vast majority of users only run a single session (except, I suppose, for published app users but we only use desktops). Thus, it seemed like an awful lot of needless bloat to launch the multi-window X server anyway.
Is there a simple way to detect if there is a current multi-windows X Server running. If so, we could test for that before launching a new multi-window session, i.e., we only launch what is requested (fullscreen, rootless, or multi-window) but, if multi-window is selected, we check for a running multi-window and, if one exists, we do not launch another.
The last question is interesting and I really don't know the answer. If I recall correctly, X2Goclient does not officially support running more than one simultaneous client. I do it all the time, however - right now in fact! I do generate errors. Typically the previous running session will generate an error about failing to connect on port 30001 but nothing seems to break. Thanks - John
Hi John,
On Sa 29 Jan 2011 21:50:43 CET "John A. Sullivan III" wrote:
multi-sessions are not supported officially but do work indeed. In
PyHoca-GUI my main focus was being able to handle multiple sessions on
multiple servers (so the essential XServer mode is multi-window) with
the same client.
The port forwarding failures are not related to x2goclient itself but
result from a somehow irregular behaviour in the SSH server code. If
you request a port forward from SSHd and do not cancel that request
the SSHd denies port forwarding for a certain period of time...
Cheers, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi John,
On Sa 29 Jan 2011 21:50:43 CET "John A. Sullivan III" wrote:
This would be my favourite approach... So we should find a way to
analyze the startup options of already running XServers...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
Hi Dick,
On Mo 31 Jan 2011 11:59:52 CET "John A. Sullivan III" wrote:
In Python you can use the WMI service of Windows to query the
taskmanager process list... No idea about C++...
I you need a wrapper in Python I could take a look...
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
----- Original Message -----
Thanks, Phil
Am 03.02.2011 16:56, schrieb --[ UxBoD ]--:
Thanks.
Unfortunately, I have no time to make this X stuff now. Please let us know if you have any informations from Vcxsrv developers.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Thu, 2011-02-03 at 18:27 +0100, Oleksandr Shneyder wrote: problem. X2Go as a viable production solution for Windows user is a no-go and we are in a catch 22. One cannot expect Windows users to live without a mouse. X2Go with Xming has this critical bug - several of our early clients need to suspend, close their X2Go client and restart several times a day and it is one of several reasons why we are delayed in the major launch of our business (I don't say that to make our problem the world's problem - just to highlight how critical this bug is). Yet X2Go on vcxsrv is broken in any multi-window mode.
The only reliable solution we have seen so far is X2Go over commercial Xming. Thus, for X2Go to be production worthy for Windows users, we must either fix Xming or vcxsrv. Xming is literally antagonistic to X2Go so our best bet is vcxsrv. Let's hope the vcxsrv devs are able to fix this and we will devote whatever resources we can to work on it as well. As always, thanks - John
On 02/03/2011 01:38 PM, John A. Sullivan III wrote:
John, that has been our assessment as well.
We've demoed x2go to some clients and let them work with it and we definitely need to have an Xserver that is stable and reliable. And right now that is not the case. And I'm getting pushback from the clients about the mouse issue and restarts. For us xming commercial is something we're looking at but that very much muddies up things with a restrictive license. If anyone has any ideas about how to produce some meaningful debug information with either Xming or VcXsrv that could lead to helping fix these problems please share it with us. We'll be glad to help with testing.
Regards, Gerry
On Thu, 2011-02-03 at 13:54 -0500, Gerry Reno wrote:
Alex, we would actually prefer you do that as we truly are not developers. Do you have time for that portion, i.e., not fixing vcxsrv but simply changing the X2Go Client code? If, not, we'll take our best stab at it.
Gerry, if we find the vcxsrv folks are not able to get to this right away, do you have anyone with X skills who could troubleshoot and fix it? That's way out of our league. Thanks, all - John
On 02/03/2011 02:26 PM, John A. Sullivan III wrote:
John, if I did we'd have fixed it already. :-)
X is not within our skill sets.
General question, is it possible to build a debug version of X? Can X be run under the control of a debugger? If so, maybe breakpoints could be set until we narrowed down the section of code causing the problem or maybe we could tell where it was from a core file. Just some thoughts.
Regards, Gerry
On 02/03/2011 02:37 PM, Gerry Reno wrote:
I just looked at all the various mouse/keyboard issues that we've seen w/X and window managers.
Multiple doodads... (had to restart X) Tried to focus the nofocus window (had to restart X) XID collision. Trouble ahead. (had to restart X) unknown keypress (translated set 2, code 0xd9 on SERIAL) ... mouse pointer disappears but still works (had to restart X) mouse pointer zooms offscreen (had to restart X) dropdown menues stop working on mouse click (gnome-terminal) (had to restart X) keystrokes fail in gnome-terminal - cursor turns to outlined block (had to restart X)
These occurred on both debian-based and redhat-based distros.
So there is plenty of room for discovery for these X issues. And some of them might ultimately be tied to the same solution. I found that some of these issues have been reported for years to Xorg and are still not solved. Of course some might be window manager issues.
Regards, Gerry
Am 03.02.2011 20:26, schrieb John A. Sullivan III:
Ok, I'll try to make this changes next week (x2goclient using vcxsrv or custom Xserver). But I can't promise it, I have a lot of work to do.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Fri, 2011-02-04 at 07:52 +0100, Oleksandr Shneyder wrote:
<snip> Fabulous. And just to make sure they are included in these changes:
Adding the clipboard parameter
Reading the session settings in Windows thus enabling fullscreen (-fullscreen) and available area (-rootless) which implies:
Moving the X Server start to after we have the session information.
Thanks very much - John
John, Did you ever try using the Cygwin/X server?
Been quite a while since I've used it but I think there was a way to
reconnect a lost mouse pointer from the menu.
Regards, Gerry
On Fri, 2011-02-04 at 11:09 -0500, Gerry Reno wrote: traffic on its own IP stack which then talks to the Windows network stack and thus introduces considerable latency. This is why Xming performs better; it directly uses the native Windows network stack.
In fact, we are eagerly anticipating better performance in general using libssh rather than ssh via Cygwin for the same reason - John
On 02/04/2011 11:46 AM, John A. Sullivan III wrote:
I just loaded Cygwin/X and now there is no menu option to reconnect mouse.
Agree on the network stack issue. If it's not using the native windows network stack then performance will not be good.
Regards, Gerry
----- Original Message -----
Alex,
I have spoken to the VcxSrv developer (Marc) today and it would appear the multiwindow issue has been resolved :) I have tested the latest build, which is available on Sourceforge, and have had no issues; well I did have a crash but I believe that is due to running XP under a VM. Have rebooted everything and I can resize very happily.
regards,
Phil
Am 10.02.2011 21:25, schrieb --[ UxBoD ]--:
Hello Phil,
It's a great news! Unfortunately I've caught a flew and wasn't able to do something this weak, as I have promised. I'll try to make changes in x2goclient code next week.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
----- Original Message -----
Alex, I found another issue with re-sizing in multiwindow and the developer of VcxSrv has resolved it. I believe we are pretty much there now as I have tried every screen size combination I could think off. The developer sent me a single binary to test, and hope to have the latest full build up on SF by the end of the week.
I also installed 3.01-14 on a clients home computer, that is ancient and very slow, using VcxSrv and the lady is jumping with joy! The combination of libssh and VcxSrv has resolved all her connection and performance issues.
Very exciting news indeed.
Thanks,
Phil
Hi Phil,
Am Mittwoch, 16. Februar 2011, 17:33:48 schrieb --[ UxBoD ]--:
All your work around VcXsrv is exciting indeed!!! Thanks a lot!!! Once the VcXsrv with your fixes inside is released, I will test it with PyHoca-GUI. Maybe you could announce its appearence on SF on this list?
Thanks a lot (again)!!! Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0x1943CA5B mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
----- Original Message -----
New version is available for download http://sourceforge.net/projects/vcxsrv/files/vcxsrv/ with the following fixes:
Am 16.02.2011 17:33, schrieb --[ UxBoD ]--:
Hello Phil,
I've made some tests with latest VcXsrv today. It's look much better as last time. Multiwindow mode and resizing are working now. Embedding x-application not working correctly yet, but not crashing any more. I've build a new version of x2goclient, download it here:
installer: http://www.x2go.org/~x2go/deb/windows/x2goclient-3.01-18-setup.exe
src: http://www.x2go.org/~x2go/deb/windows/x2goclient_3.01-18.tar.gz
With this version you can run custom X-server (see options in settings dialog). You can specify if you want to start X-Server on client or on sessions start. If you choose to start X-Server on sessions start, you can specify command line options for every session mode (windowed, fullscreen or single application). It should make much easier to testing vcxsrv with x2goclient.
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
----- Original Message -----
Oooooh :) Busily running to my desk to download it and give it a whirl :):) Thanks Alex.
I should add all the core VcxSrv work is being performed by the developer Marc. I really believe yourself and Heinz should contact him. Please feel free to email John or myself for his private email.
Oh, one other item which would be good to get added to the x2go code Alex is when the software is initially installed libssh requires a .ssh directory to be created at the same level as .x2go. This is for storing the known_hosts entries. Without it an error is thrown and client side printing and shares fail.
Thanks,
Phil
----- Original Message -----
Awesome Alex, but not quite there yet unfortunately. I am seeing huge screen corruption when in multiwindow mode, which I was not seeing with the previous version of x2go (3.01-14libssh). I will download the source and see how the xserver is being called. Minification of the x2go screen once the xserver starts is fantastic! :D I do not think we are far off; just need to polish some of the edges.
I doff my cap to you; superb work as normal.
Thanks,
Phil
----- Original Message -----
Alex,
I have enabled the logfile in x2goclientconfig.h but when I compile I receive the following error:
onmainwindow.cpp: In member function 'void ONMainWindow::slotStartSshAgent(QString)': onmainwindow.cpp:7664: error: no match for 'operator<<' in 'X2goLogDebug().X2goLogDebug::<anonymous>.QTextStream::operator<<(((const char*)"sshenv:")) << ((ONMainWindow*)this)->ONMainWindow::sshEnv'
Thanks,
Phil
Hello List,
Am 25.01.2011 13:01, schrieb Oleksandr Shneyder:
Alex has spend a lot of time to get the new version of x2goserver released (avoiding sudo commands). It'll not possible to release the changes today. Please understand that this means really a lot of work which will be made accessible as soon as possible (during the next days) using our projects "heuler" repository (tar.gz and deb).
Regards,
Heinz
----- Original Message -----
Thanks, Phil
Hi,
On Wed, Jan 26, 2011 at 11:58:41AM -0500, John A. Sullivan III wrote:
The x2go client needs to work for users added after installing x2go as well, so the client needs to create the directory. As the client needs this functionality, it is not needed in the installer.
Dipl.-Inform. Erik Auerswald http://www.fg-networking.de/ auerswald@fg-networking.de Tel: +49-631-4149988-0 Fax: +49-631-4149988-9
Gesellschaft für Fundamental Generic Networking mbH Geschäftsführung: Volker Bauer, Jörg Mayer Gerichtsstand: Amtsgericht Kaiserslautern - HRB: 3630
HI Phil,
On Mi 19 Jan 2011 12:55:00 CET "--[ UxBoD ]--" wrote:
I have tried PyHoca-GUI (which is a pure nxproxy call, actually) on
Windows together with VcXsrv and did not get any nxproxy/x2goagent
screen at all. Could you post the command line that you start VcXsrv
with from within x2goclient?
Thanks!!! Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...