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.
We would very much welcome your thoughts on this matter before we spend to much time attempting to make the code changes.
Thanks, Phil
On Wed, 2011-01-19 at 11:55 +0000, --[ UxBoD ]-- wrote:
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.
We would very much welcome your thoughts on this matter before we spend to much time attempting to make the code changes.
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:
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.
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
On Wed, 2011-01-19 at 13:54 +0100, Moritz Struebe wrote:
Am 19.01.2011 13:41, schrieb John A. Sullivan III:
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.
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. <snp> Thanks very much. I hadn't noticed the -keyhook option. Phil, is that available in vcxsrv? - John
Hello John, Phil, Moritz, list,
I'll tray in this short mail to give answers on all your questions.
- Xming working correct with nxproxy only in "multiwindow" mode.
- Xming need some time to start and it started by parallel thread to reduce delay. It make not sense to start it by x2goconnections, this will only enlarge connection time on 3-5 sec and bring no effort
- Xming just ignoring "keyhook" option (I think because of multiwindow mode)
- "right top click" is a feature of x2goagent, not X11. It will be possible to make changes in x2goagent to disable it or make configurable,
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.
Regards,
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:
Hello John, Phil, Moritz, list,
I'll tray in this short mail to give answers on all your questions.
- Xming working correct with nxproxy only in "multiwindow" mode.
- Xming need some time to start and it started by parallel thread to reduce delay. It make not sense to start it by x2goconnections, this will only enlarge connection time on 3-5 sec and bring no effort
- Xming just ignoring "keyhook" option (I think because of multiwindow mode)
- "right top click" is a feature of x2goagent, not X11. It will be possible to make changes in x2goagent to disable it or make configurable,
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.
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
On 01/19/2011 11:03 AM, John A. Sullivan III wrote:
- 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
I have some requests for both types of use cases, fullscreen and a combination of virtual/physical. So some way to configure for choice would be great.
Regards, Gerry
Am 19.01.2011 17:03, schrieb John A. Sullivan III:
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
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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.
Regards,
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-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III:
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
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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. <snip> Thanks, Oleksandr. We just wanted to make sure we weren't overlooking something before we set about changing the start sequence. We'll get working on our proposed changes to incorporate vcxsrv right away - John
Hi John, hi Alex, hi list,
On Do 20 Jan 2011 04:57:48 CET "John A. Sullivan III" wrote:
On Thu, 2011-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III:
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
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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. <snip> Thanks, Oleksandr. We just wanted to make sure we weren't overlooking something before we set about changing the start sequence. We'll get working on our proposed changes to incorporate vcxsrv right away - John
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).
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-22 at 19:32 +0100, Mike Gabriel wrote:
Hi John, hi Alex, hi list,
<snip>
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).Greets, Mike Hi, Mike. In discussing this with Phil, we decided on three. The explicit rootless gives us <ALT><TAB> capability while we suspect multi-window does not. I'm guessing we will move the entire X launch until later in the process - once we have the session data. We could start multi-window early and then only start a new session if it is rootless or fullscreen but that seems to be a waste. I'd imagine we will start a new X for each session even if they are all multi-window. At least initially. I'm not sure how complex it would be to check for an existing multi-window instance before launching a new multi-window instance. Thanks - John
On Thu, 2011-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III: <snip>
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.
Regards,
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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:
On Thu, 2011-01-20 at 02:09 +0100, Oleksandr Shneyder wrote:
Am 19.01.2011 17:03, schrieb John A. Sullivan III: <snip>
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.
Regards,
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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
Hello John, As you know, I must spend all my free time now to rewrite x2goserver. I am almost ready, so I think, I can upload new x2goserver in GIT today. After that, I'll check vcxsrv. Sorry, but security issue must be solved asap. I hope, that I can give you an answer tomorrow or day after tomorrow. alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
On Tue, 2011-01-25 at 13:01 +0100, Oleksandr Shneyder wrote:
Am 24.01.2011 19:32, schrieb John A. Sullivan III: <snip> Hello John, As you know, I must spend all my free time now to rewrite x2goserver. I am almost ready, so I think, I can upload new x2goserver in GIT today. After that, I'll check vcxsrv. Sorry, but security issue must be solved asap. I hope, that I can give you an answer tomorrow or day after tomorrow. alex <snip> Entirely understood. Thanks, Alex - John
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:
- VcXsrv is based on actual Xorg (7) git sources.
- VcXsrv is licensed under GPL
- Xming seems to have some bugs and based on old Xorg (6) sources. Newer Xming versions are based on Xorg (7) but the license is not open.
The good news about our tests are:
- VcXsrv in window mode (fixed size window with decorations) is working.
- VcXsrv in rootless mode (fixed size window without decorations) is working too.
- VcXsrv in fullscreen mode is also working. This was only a short test so nothing can be said about the stability of VcXsrv yet.
The not so good news:
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
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:
- Wait until this issues will be fixed or
- We can provide x2goclient installer with VcXsrv (no resizing of DE and buggy resizing of single applications on windows xp), but x2goplugin with Xming or
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver. Please give us your opinion!
Regards, Alex
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:
What we can do now:
- Wait until this issues will be fixed or
- We can provide x2goclient installer with VcXsrv (no resizing of DE and buggy resizing of single applications on windows xp), but x2goplugin with Xming or
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver. Please give us your opinion!
-- 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 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.
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.
regards, alex
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:
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.
-- 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:
What we can do now:
- Wait until this issues will be fixed or
- We can provide x2goclient installer with VcXsrv (no resizing of DE and buggy resizing of single applications on windows xp), but x2goplugin with Xming or
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver. Please give us your opinion!
Regards, Alex
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 achoice 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 bywebserver. 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:
For plugin, there should be choice of plugins that can be offered bywebserver. One built w/Xming, the other w/VcXsrv. That way either one, or both could be offered to users.
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 01/28/2011 02:35 PM, Heinz-M. Graesing wrote:
Hi Gerry,
Am 28.01.2011 16:48, schrieb Gerry Reno:
For plugin, there should be choice of plugins that can be offered bywebserver. One built w/Xming, the other w/VcXsrv. That way either one, or both could be offered to users.
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
Understand.
Maybe John's suggestion of involving VcXsrv devs into looking at this could bear some fruit in a reasonable timeframe.
John, have you made any contacts w/VcXsrv?
Regards, Gerry
On Fri, 2011-01-28 at 14:40 -0500, Gerry Reno wrote:
On 01/28/2011 02:35 PM, Heinz-M. Graesing wrote:
Hi Gerry,
Am 28.01.2011 16:48, schrieb Gerry Reno:
For plugin, there should be choice of plugins that can be offered bywebserver. One built w/Xming, the other w/VcXsrv. That way either one, or both could be offered to users.
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
Understand.
Maybe John's suggestion of involving VcXsrv devs into looking at this could bear some fruit in a reasonable timeframe.
John, have you made any contacts w/VcXsrv? <snip> Nope, awaiting Phil's response as he has done almost all of our vcxsrv testing - John
On Fri, 2011-01-28 at 13:47 +0100, Oleksandr Shneyder wrote:
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:
- VcXsrv is based on actual Xorg (7) git sources.
- VcXsrv is licensed under GPL
- Xming seems to have some bugs and based on old Xorg (6) sources. Newer Xming versions are based on Xorg (7) but the license is not open.
The good news about our tests are:
- VcXsrv in window mode (fixed size window with decorations) is working.
- VcXsrv in rootless mode (fixed size window without decorations) is working too.
- VcXsrv in fullscreen mode is also working. This was only a short test so nothing can be said about the stability of VcXsrv yet.
The not so good news:
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
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:
- Wait until this issues will be fixed or
- We can provide x2goclient installer with VcXsrv (no resizing of DE and buggy resizing of single applications on windows xp), but x2goplugin with Xming or
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver. Please give us your opinion! <snip> Hi, Alex. Delighted to hear of the progress. I'll defer to Phil for sharing his testing results regarding stability and resizing. We'd be very happy to communicate with the vcxsrv devs about what we have
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:
<snip> Hi, Alex. Delighted to hear of the progress. I'll defer to Phil for sharing his testing results regarding stability and resizing. We'd be very happy to communicate with the vcxsrv devs about what we have collectively found.
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.
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?
We'd like to see the VcXsrv option for the plugin as well.
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).
+1
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.
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:
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
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:
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
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
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
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:
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.
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 01/28/2011 03:04 PM, Heinz-M. Graesing wrote:
Hi Gerry,
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!
Yes, of course. I've got Linux on the brain lately working w/Ubuntu at the moment.
I should have said .msi file or equivalent.
Regards, Gerry
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
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
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. <snip> Hmm . . . I suppose we could install both by default and then leave it to the client configuration but I hate that kind of bloat. I would
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:
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
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
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.
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")
Regards,
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:
Am 28.01.2011 20:44, schrieb Heinz-M. Graesing:
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
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
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.
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")
<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:
Am 28.01.2011 20:44, schrieb Heinz-M. Graesing:
Hi John,
Am 28.01.2011 17:55, schrieb John A. Sullivan III:
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
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.
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")
Regards,
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 ofthese packages on their webpage.
The reason that I think the installer should include at least oneXserver 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:
I've made some tests on Windows XP and Windows 7 to see if Xming can be replaced with VcXsrv.
[... test results ...]
Your test results fully match my experiences with PyHoca-GUI.
What we can do now:
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver.
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:
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.
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...
On Sat, 2011-01-29 at 21:09 +0100, Mike Gabriel wrote:
Hi Alex,
On Fr 28 Jan 2011 13:47:23 CET Oleksandr Shneyder wrote:
I've made some tests on Windows XP and Windows 7 to see if Xming can be replaced with VcXsrv.
[... test results ...]
Your test results fully match my experiences with PyHoca-GUI.
What we can do now:
- We can provide x2goclient with Xming, but make it configurable to launch other Xserver.
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> <snip> Just as a reminder, we probably want to move this code to after the session parameters are chosen and allow passing the -fullscreen and -rootless (available area) parameters. Thanks - John
Hi John,
On Sa 29 Jan 2011 21:19:15 CET "John A. Sullivan III" wrote:
<snip> Just as a reminder, we probably want to move this code to after the session parameters are chosen and allow passing the -fullscreen and -rootless (available area) parameters. Thanks - John
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 John,
On Sa 29 Jan 2011 21:19:15 CET "John A. Sullivan III" wrote:
<snip> Just as a reminder, we probably want to move this code to after the session parameters are chosen and allow passing the -fullscreen and -rootless (available area) parameters. Thanks - John
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
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:
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
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:
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.
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...
On Sun, 2011-01-30 at 09:13 +0100, Mike Gabriel wrote:
Hi John,
On Sa 29 Jan 2011 21:50:43 CET "John A. Sullivan III" wrote:
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.
This would be my favourite approach... So we should find a way to
analyze the startup options of already running XServers...Greets, Mike
Hmm . . . I wonder if there is any Windows equivalent to ps aux | grep vcxsrv? I'm not a Windows person at all - been on a Linux desktop for almost 12 years. Thanks - John
Hi Dick,
On Mo 31 Jan 2011 11:59:52 CET "John A. Sullivan III" wrote:
On Sun, 2011-01-30 at 09:13 +0100, Mike Gabriel wrote:
Hi John,
On Sa 29 Jan 2011 21:50:43 CET "John A. Sullivan III" wrote:
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.
This would be my favourite approach... So we should find a way to analyze the startup options of already running XServers...
Greets, Mike
Hmm . . . I wonder if there is any Windows equivalent to ps aux | grep vcxsrv? I'm not a Windows person at all - been on a Linux desktop for almost 12 years. Thanks - John
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...
2011/1/31 John A. Sullivan III <jsullivan@opensourcedevel.com>:
Hmm . . . I wonder if there is any Windows equivalent to ps aux | grep vcxsrv? I'm not a Windows person at all - been on a Linux desktop for almost 12 years. Thanks - John
There are a few ways to do it, XP/2003 and later:
tasklist | findstr -i vcxsrv >NUL
Check errorlevel, 0=hit, 1=miss.
Cheers, Daniel
----- Original Message -----
2011/1/31 John A. Sullivan III <jsullivan@opensourcedevel.com>:
Hmm . . . I wonder if there is any Windows equivalent to ps aux | grep vcxsrv? I'm not a Windows person at all - been on a Linux desktop for almost 12 years. Thanks - John
There are a few ways to do it, XP/2003 and later:
tasklist | findstr -i vcxsrv >NUL
Check errorlevel, 0=hit, 1=miss.
Cheers, Daniel
I would very much imagine there is a Qt Windows API hook for querying the process stack. That would be far faster than making an external call.
Thanks, Phil
On Mon, 2011-01-31 at 12:18 +0000, --[ UxBoD ]-- wrote:
----- Original Message -----
2011/1/31 John A. Sullivan III <jsullivan@opensourcedevel.com>:
Hmm . . . I wonder if there is any Windows equivalent to ps aux | grep vcxsrv? I'm not a Windows person at all - been on a Linux desktop for almost 12 years. Thanks - John
There are a few ways to do it, XP/2003 and later:
tasklist | findstr -i vcxsrv >NUL
Check errorlevel, 0=hit, 1=miss.
Cheers, Daniel
I would very much imagine there is a Qt Windows API hook for querying the process stack. That would be far faster than making an external call. I'm not sure that there is although I haven't actively developed in Qt for many years - John
----- Original Message -----
<SNIP>
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
<SNIP>
Regards, Alex
Alex, I have performed some testing today and came to the same conclusion as yourself. I have even tried the *very* latest release (02/02/2011) and that exhibits the same issues. I have flagged it on the vcxsrv forum so hopefully the dev will be able to help us out; at least I can try and get some debug information for them :)
Thanks, Phil
Am 03.02.2011 16:56, schrieb --[ UxBoD ]--:
----- Original Message -----
<SNIP>
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
<SNIP>
Regards, Alex
Alex, I have performed some testing today and came to the same conclusion as yourself. I have even tried the *very* latest release (02/02/2011) and that exhibits the same issues. I have flagged it on the vcxsrv forum so hopefully the dev will be able to help us out; at least I can try and get some debug information for them :)
Thanks.
Unfortunately, I have no time to make this X stuff now. Please let us know if you have any informations from Vcxsrv developers.
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 03.02.2011 16:56, schrieb --[ UxBoD ]--:
----- Original Message -----
<SNIP>
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
<SNIP>
Regards, Alex
Alex, I have performed some testing today and came to the same conclusion as yourself. I have even tried the *very* latest release (02/02/2011) and that exhibits the same issues. I have flagged it on the vcxsrv forum so hopefully the dev will be able to help us out; at least I can try and get some debug information for them :)
Thanks.
Unfortunately, I have no time to make this X stuff now. Please let us know if you have any informations from Vcxsrv developers. <snip> We are happy to run with this as far as we can (in our non-developerness!). But it is an absolutely critical, highest priority
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:
On Thu, 2011-02-03 at 18:27 +0100, Oleksandr Shneyder wrote:
Am 03.02.2011 16:56, schrieb --[ UxBoD ]--:
----- Original Message -----
<SNIP>
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
<SNIP>
Regards, Alex
Alex, I have performed some testing today and came to the same conclusion as yourself. I have even tried the *very* latest release (02/02/2011) and that exhibits the same issues. I have flagged it on the vcxsrv forum so hopefully the dev will be able to help us out; at least I can try and get some debug information for them :)
Thanks.
Unfortunately, I have no time to make this X stuff now. Please let us know if you have any informations from Vcxsrv developers.
<snip> We are happy to run with this as far as we can (in our non-developerness!). But it is an absolutely critical, highest priority 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
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:
On 02/03/2011 01:38 PM, John A. Sullivan III wrote:
On Thu, 2011-02-03 at 18:27 +0100, Oleksandr Shneyder wrote:
Am 03.02.2011 16:56, schrieb --[ UxBoD ]--:
----- Original Message -----
<SNIP>
- VcXsrv crashes in multi-window mode during the start of x2goagent (it seems to work by resuming of x2goagent or in single-application mode).
- VcXsrv is crashing or working incorrectly by reparrenting of x2goagent window (embedding in other window) in multi-window mode.
- VcXsrv is working incorrectly when the user wants to resize a window in multi-window mode on Windows XP.
<SNIP> 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
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. <snip> That would be very appreciated. I think the next step is already in motion; Phil has contacted the vcxsrv devs with whom he seems to get on well. In the meantime, we can slot in the bits into the code to make it work with either X server and to call it when we have the session information as opposed to before like it is now. That will give us rootless and fullscreen capabilities. It will be even better if we can detect if there is an existing multiwindow. We need to do all that regardless of whom we ultimately use.
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:
On Thu, 2011-02-03 at 13:54 -0500, Gerry Reno wrote:
On 02/03/2011 01:38 PM, John A. Sullivan III wrote:
<snip> 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
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.
<snip> That would be very appreciated. I think the next step is already in motion; Phil has contacted the vcxsrv devs with whom he seems to get on well. In the meantime, we can slot in the bits into the code to make it work with either X server and to call it when we have the session information as opposed to before like it is now. That will give us rootless and fullscreen capabilities. It will be even better if we can detect if there is an existing multiwindow. We need to do all that regardless of whom we ultimately use.
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
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:
On 02/03/2011 02:26 PM, John A. Sullivan III wrote:
On Thu, 2011-02-03 at 13:54 -0500, Gerry Reno wrote:
On 02/03/2011 01:38 PM, John A. Sullivan III wrote:
<snip> 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
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.
<snip> That would be very appreciated. I think the next step is already in motion; Phil has contacted the vcxsrv devs with whom he seems to get on well. In the meantime, we can slot in the bits into the code to make it work with either X server and to call it when we have the session information as opposed to before like it is now. That will give us rootless and fullscreen capabilities. It will be even better if we can detect if there is an existing multiwindow. We need to do all that regardless of whom we ultimately use.
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
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
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:
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.
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.
regards,
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:
Am 03.02.2011 20:26, schrieb John A. Sullivan III:
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.
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.
<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 toreconnect a lost mouse pointer from the menu.
Regards, Gerry
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 toreconnect a lost mouse pointer from the menu. <snip> We did not for performance reasons. I gather that Cygwin places the X
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:
On Fri, 2011-02-04 at 11:09 -0500, Gerry Reno wrote:
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 toreconnect a lost mouse pointer from the menu.
<snip> We did not for performance reasons. I gather that Cygwin places the X 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
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 -----
Am 03.02.2011 20:26, schrieb John A. Sullivan III:
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.
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.
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
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 ]--:
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
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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.
regards, alex
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
Am 10.02.2011 21:25, schrieb --[ UxBoD ]--:
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.
<snip> 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. <snip> Yuch! Sorry to hear it but to add to the good news, the experimental client Phil has built with vcxsrv and libssh appears to have solved the
On Fri, 2011-02-11 at 00:04 +0100, Oleksandr Shneyder wrote: problem with those very old computers running XP. It has been several days and nary a call - John
----- Original Message -----
Am 10.02.2011 21:25, schrieb --[ UxBoD ]--:
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
X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev
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.
regards, alex
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 ]--:
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.
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 -----
Hi Phil,
Am Mittwoch, 16. Februar 2011, 17:33:48 schrieb --[ UxBoD ]--:
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.
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
New version is available for download http://sourceforge.net/projects/vcxsrv/files/vcxsrv/ with the following fixes:
Changes in 1.9.4.1
- Update the following packages: xkeyboard-config git update until 16/2/2011 pixman git update until 16/2/2011 xkbcomp git update until 16/2/2011 mesa git update until 16/2/2011
- Solved problem of wrongly generated error message in vcxsrv_dbg
- Solved problem of a window being created with an Y coordinate of 0x8000000.
- xdmcp: Solved display problem when multiple monitor setup changes
- When XDMCP -from is specified, only register the requested address
- Only call XSupportsLocale in one place. Switch to a known locale when it fails
- Type cast width to short to avoid type cast exception in debug version when width is negative.
- multiwindow; Solved possible crash because the pixmap buffer was not correct anymore after moving a window
Am 16.02.2011 17:33, schrieb --[ UxBoD ]--:
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
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.
regards,
Oleksandr Shneyder Dipl. Informatik X2go Core Developer Team
email: oleksandr.shneyder@obviously-nice.de web: www.obviously-nice.de
--> X2go - everywhere@home
----- Original Message -----
Am 16.02.2011 17:33, schrieb --[ UxBoD ]--:
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
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.
regards,
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 -----
----- Original Message -----
Am 16.02.2011 17:33, schrieb --[ UxBoD ]--:
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
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.
regards,
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
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 -----
Am 16.02.2011 17:33, schrieb --[ UxBoD ]--:
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
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.
regards,
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'
Have I done something wrong ? All I did was remove the // in the header file.
Thanks,
Phil
Hello List,
Am 25.01.2011 13:01, schrieb Oleksandr Shneyder:
Hello John, As you know, I must spend all my free time now to rewrite x2goserver. I am almost ready, so I think, I can upload new x2goserver in GIT today.
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 -----
Hello List,
Am 25.01.2011 13:01, schrieb Oleksandr Shneyder:
Hello John, As you know, I must spend all my free time now to rewrite x2goserver. I am almost ready, so I think, I can upload new x2goserver in GIT today.
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
Have noticed that in the libssh version of the x2goclient (3.01-14) under Windows if you fail to create the directory <USER_HOME>/.x2go/.ssh shared folders fail to mount and you always receive an error message that authorized_keys cannot be created. This, if not already done so, will need to be added into onmainwindow.cpp I think.
Thanks, Phil
On Wed, 2011-01-26 at 14:12 +0000, --[ UxBoD ]-- wrote:
----- Original Message -----
Hello List,
Am 25.01.2011 13:01, schrieb Oleksandr Shneyder:
Hello John, As you know, I must spend all my free time now to rewrite x2goserver. I am almost ready, so I think, I can upload new x2goserver in GIT today.
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
Have noticed that in the libssh version of the x2goclient (3.01-14) under Windows if you fail to create the directory <USER_HOME>/.x2go/.ssh shared folders fail to mount and you always receive an error message that authorized_keys cannot be created. This, if not already done so, will need to be added into onmainwindow.cpp I think. I wonder if that's not more a job for the installer - or perhaps both as a belt and suspenders approach - John
Hi,
On Wed, Jan 26, 2011 at 11:58:41AM -0500, John A. Sullivan III wrote:
On Wed, 2011-01-26 at 14:12 +0000, --[ UxBoD ]-- wrote:
Have noticed that in the libssh version of the x2goclient (3.01-14) under Windows if you fail to create the directory <USER_HOME>/.x2go/.ssh shared folders fail to mount and you always receive an error message that authorized_keys cannot be created. This, if not already done so, will need to be added into onmainwindow.cpp I think. I wonder if that's not more a job for the installer - or perhaps both as a belt and suspenders approach - John
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.
Thanks, Erik
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:
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.We would very much welcome your thoughts on this matter before we
spend to much time attempting to make the code changes.Thanks, Phil
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...
-
--[ UxBoD ]-- -
Daniel Lindgren -
Erik Auerswald -
Gerry Reno -
Heinz-M. Graesing -
Heinz-M. Graesing -
John A. Sullivan III -
Mike Gabriel -
Moritz Struebe -
Oleksandr Shneyder