From joakim at terminalmx.com Thu May 7 23:14:15 2020 From: joakim at terminalmx.com (Joakim Ziegler) Date: Thu, 7 May 2020 17:14:15 -0500 Subject: [winswitch] Chrome window can not be resized or moved Message-ID: Hello, I'm testing Xpra for internal use in our company, essentially we need to virtualize web browsers so they do not run on production machines, but rather on a server in a DMZ, because of client content security requirements. I've installed Xpra 3.0.6-r25177 on the server (Ubuntu Focal, with the distribution packages, since there don't seem to be official Xpra packages for 20.04 yet), and Xpra v3.0.9-r26132 from the official packages on the client, which is a CentOS 7.4 box (to be upgraded at some point in the future to latest CentOS 7). On the server, I've installed Chrome, which is the browser I'd prefer to use, and I'm starting it from the client machine with the following commandline: xpra start ssh:user at server --start google-chrome-stable This works fine, in that the Chrome window shows up on the client desktop and I can use the web browser normally. However, the Chrome window can not be moved or resized. Hovering the mouse pointer over the edges or corners of the window changes the pointer shape to the typical "resize" pointer for the corresponding edge/corner, but dragging does nothing. Trying to move the window by dragging on the title bar also does nothing. Minimize/maximize, however, works fine. I suspect this is due to the custom window decorations Chrome uses, since other applications (the canonical example is xterm, I guess) work fine and can be resized normally. Any ideas or pointers to why this happens, and how to fix or work around? Xpra seems perfect for my use case otherwise, so this is the only problem I think I need to solve... Thank you for any help. -- Joakim Ziegler - Supervisor de postproducci?n - Terminal joakim at terminalmx.com - 044 55 2971 8514 - 5264 0864 From antoine at nagafix.co.uk Fri May 8 03:11:07 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 8 May 2020 09:11:07 +0700 Subject: [winswitch] Chrome window can not be resized or moved In-Reply-To: References: Message-ID: On 08/05/2020 05:14, Joakim Ziegler via shifter-users wrote: > Hello, > > I'm testing Xpra for internal use in our company, essentially we need to > virtualize web browsers so they do not run on production machines, but > rather on a server in a DMZ, because of client content security > requirements. That's a very common usage scenario for Xpra. > I've installed Xpra 3.0.6-r25177 on the server (Ubuntu Focal, with the > distribution packages, since there don't seem to be official Xpra packages > for 20.04 yet), and Xpra v3.0.9-r26132 from the official packages on the > client, which is a CentOS 7.4 box (to be upgraded at some point in the > future to latest CentOS 7). > > On the server, I've installed Chrome, which is the browser I'd prefer to > use, and I'm starting it from the client machine with the following > commandline: > > xpra start ssh:user at server --start google-chrome-stable > > This works fine, in that the Chrome window shows up on the client desktop > and I can use the web browser normally. However, the Chrome window can not > be moved or resized. Hovering the mouse pointer over the edges or corners > of the window changes the pointer shape to the typical "resize" pointer for > the corresponding edge/corner, but dragging does nothing. Trying to move > the window by dragging on the title bar also does nothing. > Minimize/maximize, however, works fine. That's a bug in the Ubuntu packages, once again... Don't use those if you don't have to: https://xpra.org/trac/wiki/Packaging/DistributionPackages > I suspect this is due to the custom window decorations Chrome uses, since > other applications (the canonical example is xterm, I guess) work fine and > can be resized normally. Correct, this works fine in Xpra though, just not in the version packaged in Ubuntu. > Any ideas or pointers to why this happens, and how to fix or work around? > Xpra seems perfect for my use case otherwise, so this is the only problem I > think I need to solve... Xpra 4.0 was due to be released this week, but there's one final bug delaying it. Until then, you can install it from the beta repository: https://xpra.org/repos/focal/xpra-beta.list Cheers, Antoine > > Thank you for any help. > From antoine at devloop.org.uk Sun May 10 18:24:17 2020 From: antoine at devloop.org.uk (Antoine Martin) Date: Mon, 11 May 2020 00:24:17 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 Message-ID: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> Hi, This release cycle was one of the longest, and during that time a record 260+ tickets were dealt with. Many of those were fixes that have already made their way to the 3.0.x LTS branch. Big thanks go to those who contributed to this release by reporting bugs, providing feedback or patches, testing, etc. In particular, N.Stavros (everything) and "brief" (HTML5). The release notes with links to some of the tickets can be found here: https://xpra.org/trac/wiki/News#a4.0ImportantFeatures Next, development will start on version 4.1: https://xpra.org/trac/milestone/4.1 In parallel to that, some features are planned to be backported to a new 3.1 branch: https://xpra.org/trac/milestone/3.1 This 3.1 branch will eventually replace the 3.0 LTS branch. If there are fixes or features that you think should be available in the LTS branch, now is the time to nominate them. Cheers, Antoine From crl.langlois at gmail.com Wed May 13 11:48:26 2020 From: crl.langlois at gmail.com (carl langlois) Date: Wed, 13 May 2020 06:48:26 -0400 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 In-Reply-To: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> References: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> Message-ID: Hi, Great job guys. Can we expect build for Ubuntu 19.10? Thanks and regards Carl Le dim. 10 mai 2020 13 h 24, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> a ?crit : > Hi, > > This release cycle was one of the longest, and during that time a record > 260+ tickets were dealt with. Many of those were fixes that have already > made their way to the 3.0.x LTS branch. > > Big thanks go to those who contributed to this release by reporting > bugs, providing feedback or patches, testing, etc. > In particular, N.Stavros (everything) and "brief" (HTML5). > > The release notes with links to some of the tickets can be found here: > https://xpra.org/trac/wiki/News#a4.0ImportantFeatures > > Next, development will start on version 4.1: > https://xpra.org/trac/milestone/4.1 > In parallel to that, some features are planned to be backported to a new > 3.1 branch: > https://xpra.org/trac/milestone/3.1 > This 3.1 branch will eventually replace the 3.0 LTS branch. > If there are fixes or features that you think should be available in the > LTS branch, now is the time to nominate them. > > Cheers, > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From luca.manganelli at comune.trento.it Thu May 14 07:08:27 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 14 May 2020 08:08:27 +0200 Subject: [winswitch] Xpra 4.0: unable to start application Message-ID: Hello, I have two systems: 1) at work with Fedora 32 2) at home with Ubuntu 18.04 both do have Xpra 4.0. In Xpra 3.0 I had always executed this command successfully: xpra start ssh://SSH_HOST --start-child=pidgin (or whatever any application) but in 4.0 this throws this error: 2020-05-14 07:47:27,269 Authentication (password) successful! 2020-05-14 07:47:28,036 keyboard settings: rules=evdev, model=pc105, layout=it 2020-05-14 07:47:28,130 desktop size is 1920x1080 with 1 screen: 2020-05-14 07:47:28,130 :0.0 (508x285 mm - DPI: 96x96) workarea: 1920x1044 2020-05-14 07:47:28,130 DP-3 (520x320 mm - DPI: 93x85) 2020-05-14 07:47:57,860 connection timed out the remote logs don't tell anything particular. -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ? From antoine at nagafix.co.uk Thu May 14 09:56:46 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 14 May 2020 15:56:46 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 In-Reply-To: References: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> Message-ID: <5a7a79fb-1791-a895-d9e0-6ef4e7f77566@nagafix.co.uk> On 13/05/2020 17:48, carl langlois via shifter-users wrote: > Hi, > Great job guys. > Can we expect build for Ubuntu 19.10? Oops, thanks for the reminder. The Ubuntu 19.10 builds were failing and needed a couple of tweaks. The fixed 4.0 packages are in the Ubuntu Eoan repository now. Cheers, Antoine > Thanks and regards > > Carl From antoine at nagafix.co.uk Thu May 14 11:30:57 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 14 May 2020 17:30:57 +0700 Subject: [winswitch] Xpra 4.0: unable to start application In-Reply-To: References: Message-ID: On 14/05/2020 13:08, Luca Manganelli via shifter-users wrote: > Hello, > > I have two systems: > > 1) at work with Fedora 32 > 2) at home with Ubuntu 18.04 > > both do have Xpra 4.0. > > In Xpra 3.0 I had always executed this command successfully: > > xpra start ssh://SSH_HOST --start-child=pidgin (or whatever any application) > > but in 4.0 this throws this error: > > 2020-05-14 07:47:27,269 Authentication (password) successful! > 2020-05-14 07:47:28,036 keyboard settings: rules=evdev, model=pc105, > layout=it > 2020-05-14 07:47:28,130 desktop size is 1920x1080 with 1 screen: > 2020-05-14 07:47:28,130 :0.0 (508x285 mm - DPI: 96x96) workarea: 1920x1044 > 2020-05-14 07:47:28,130 DP-3 (520x320 mm - DPI: 93x85) > 2020-05-14 07:47:57,860 connection timed out > > the remote logs don't tell anything particular Thanks for reporting this bug. Yet again, one of the very last features to go in (MS Windows proxy support) has caused a regression elsewhere.. Sorry about that. We'll try to do better in the future. The fix is trivial: http://xpra.org/trac/changeset/26351 So you can just apply it by hand to your installation, wait for the 4.0.1 release, or start your sessions in two steps: xpra start ssh://SSH_HOST --start=whatever --attach=no xpra attach ssh://SSH_HOST Cheers, Antoine From luca.manganelli at comune.trento.it Thu May 14 11:40:00 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Thu, 14 May 2020 12:40:00 +0200 Subject: [winswitch] Xpra 4.0: unable to start application In-Reply-To: References: Message-ID: Il giorno gio 14 mag 2020 alle ore 12:31 Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> ha scritto: > Yet again, one of the very last features to go in (MS Windows proxy > support) has caused a regression elsewhere.. Sorry about that. > We'll try to do better in the future. Thank you for the fast reply! :-) -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ? From crl.langlois at gmail.com Thu May 14 13:06:42 2020 From: crl.langlois at gmail.com (carl langlois) Date: Thu, 14 May 2020 08:06:42 -0400 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 In-Reply-To: <5a7a79fb-1791-a895-d9e0-6ef4e7f77566@nagafix.co.uk> References: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> <5a7a79fb-1791-a895-d9e0-6ef4e7f77566@nagafix.co.uk> Message-ID: Hi, just try to upgrade and got this. Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help resolve the situation: The following packages have unmet dependencies: xpra : Conflicts: python3-xpra but 3.0.9-r26132-2 is to be installed E: Broken packages Regards Cerl On Thu, May 14, 2020 at 4:56 AM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 13/05/2020 17:48, carl langlois via shifter-users wrote: > > Hi, > > Great job guys. > > Can we expect build for Ubuntu 19.10? > Oops, thanks for the reminder. > The Ubuntu 19.10 builds were failing and needed a couple of tweaks. > The fixed 4.0 packages are in the Ubuntu Eoan repository now. > > Cheers, > Antoine > > > > Thanks and regards > > > > Carl > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Thu May 14 13:10:29 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 14 May 2020 19:10:29 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 In-Reply-To: References: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> <5a7a79fb-1791-a895-d9e0-6ef4e7f77566@nagafix.co.uk> Message-ID: <0f31a1a1-9601-7291-40c6-377ae7da4cb0@nagafix.co.uk> On 14/05/2020 19:06, carl langlois wrote: > Hi, > just try to upgrade and got this. > > Reading package lists... Done > Building dependency tree ? ? ? > Reading state information... Done > Calculating upgrade... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help resolve the situation: > > The following packages have unmet dependencies: > ?xpra : Conflicts: python3-xpra but 3.0.9-r26132-2 is to be installed That's weird, maybe you didn't have 3.0.9 installed and I did, because I didn't hit this issue when I tested upgrades. This should work: apt-get remove xpra python3-xpra python2-xpra apt-get install xpra (in v4 there is only one 'xpra' package, which is the python3 variant) Cheers, Antoine > E: Broken packages > Regards > Cerl > > On Thu, May 14, 2020 at 4:56 AM Antoine Martin via shifter-users > > wrote: > > On 13/05/2020 17:48, carl langlois via shifter-users wrote: > > Hi, > > Great job guys. > > Can we expect build for Ubuntu 19.10? > Oops, thanks for the reminder. > The Ubuntu 19.10 builds were failing and needed a couple of tweaks. > The fixed 4.0 packages are in the Ubuntu Eoan repository now. > > Cheers, > Antoine > > > > Thanks and regards > > > > Carl > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From crl.langlois at gmail.com Thu May 14 13:17:24 2020 From: crl.langlois at gmail.com (carl langlois) Date: Thu, 14 May 2020 08:17:24 -0400 Subject: [winswitch] [ANNOUNCE] Xpra 4.0 In-Reply-To: <0f31a1a1-9601-7291-40c6-377ae7da4cb0@nagafix.co.uk> References: <86ee3cfb-7e90-2e39-c199-213d45d9e8f7@devloop.org.uk> <5a7a79fb-1791-a895-d9e0-6ef4e7f77566@nagafix.co.uk> <0f31a1a1-9601-7291-40c6-377ae7da4cb0@nagafix.co.uk> Message-ID: Great it works. thanks. Carl On Thu, May 14, 2020 at 8:10 AM Antoine Martin wrote: > On 14/05/2020 19:06, carl langlois wrote: > > Hi, > > just try to upgrade and got this. > > > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Calculating upgrade... Done > > Some packages could not be installed. This may mean that you have > > requested an impossible situation or if you are using the unstable > > distribution that some required packages have not yet been created > > or been moved out of Incoming. > > The following information may help resolve the situation: > > > > The following packages have unmet dependencies: > > xpra : Conflicts: python3-xpra but 3.0.9-r26132-2 is to be installed > That's weird, maybe you didn't have 3.0.9 installed and I did, because I > didn't hit this issue when I tested upgrades. > > This should work: > apt-get remove xpra python3-xpra python2-xpra > apt-get install xpra > (in v4 there is only one 'xpra' package, which is the python3 variant) > > Cheers, > Antoine > > > E: Broken packages > > Regards > > Cerl > > > > On Thu, May 14, 2020 at 4:56 AM Antoine Martin via shifter-users > > > > wrote: > > > > On 13/05/2020 17:48, carl langlois via shifter-users wrote: > > > Hi, > > > Great job guys. > > > Can we expect build for Ubuntu 19.10? > > Oops, thanks for the reminder. > > The Ubuntu 19.10 builds were failing and needed a couple of tweaks. > > The fixed 4.0 packages are in the Ubuntu Eoan repository now. > > > > Cheers, > > Antoine > > > > > > > Thanks and regards > > > > > > Carl > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > From anto.trande at gmail.com Thu May 14 20:23:18 2020 From: anto.trande at gmail.com (Antonio Trande) Date: Thu, 14 May 2020 21:23:18 +0200 Subject: [winswitch] uglify-js dependence Message-ID: <2ec221c1-573f-a459-ecc6-478fcf2cb022@fedoraproject.org> Hi all. Currently, `xpra` rpm provided by Fedora repositories requires `uglify-js` during build time. Since `uglify-js` needs many missing JS modules to be used, i wish to drop `uglify-js` dependence but how does work `xpra` without `uglify-js` support? -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x7B30EE04E576AA84 GPG key server: https://keys.openpgp.org/ From antoine at nagafix.co.uk Fri May 15 03:47:01 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 15 May 2020 09:47:01 +0700 Subject: [winswitch] uglify-js dependence In-Reply-To: <2ec221c1-573f-a459-ecc6-478fcf2cb022@fedoraproject.org> References: <2ec221c1-573f-a459-ecc6-478fcf2cb022@fedoraproject.org> Message-ID: On 15/05/2020 02:23, Antonio Trande via shifter-users wrote: > Hi all. > > Currently, `xpra` rpm provided by Fedora repositories requires > `uglify-js` during build time. > Since `uglify-js` needs many missing JS modules to be used, i wish to > drop `uglify-js` dependence but how does work `xpra` without `uglify-js` > support? Uglify-js is only used to minify the html5 client, it is optional. Cheers, Antoine From antoine at devloop.org.uk Sun May 17 17:13:26 2020 From: antoine at devloop.org.uk (Antoine Martin) Date: Sun, 17 May 2020 23:13:26 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 4.0.1: a few fixes Message-ID: <4cf330e6-06ac-b57c-4eb2-952300ce55fc@devloop.org.uk> Hi, This minor update fixes just 8 bugs. There is no urgency to update if you were not affected by these bugs. Release notes: * fix missing content-type for some windows * fix GTK server crash on exit * fix compatibility with newer versions of uglifyjs * fix ssh session start and attach on Posix systems * fix missing avcodec encodings with Ubuntu 18.04 * fix 'xpra send-file' to use absolute file paths * fix MacOS shadow servers failing to accept connections * don't depend on gnome bits if plasma-desktop is installed (.deb) Cheers, Antoine From joakim at terminalmx.com Wed May 20 05:41:52 2020 From: joakim at terminalmx.com (Joakim Ziegler) Date: Tue, 19 May 2020 23:41:52 -0500 Subject: [winswitch] Xpra 4.0 packages for CentOS 7.x Message-ID: Hello, are Xpra 4.0 packages for CentOS 7.x (specifically, 7.8) planned any time soon? -- Joakim Ziegler - Supervisor de postproducci?n - Terminal joakim at terminalmx.com - 044 55 2971 8514 - 5264 0864 From antoine at nagafix.co.uk Wed May 20 05:54:44 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 20 May 2020 11:54:44 +0700 Subject: [winswitch] Xpra 4.0 packages for CentOS 7.x In-Reply-To: References: Message-ID: On 20/05/2020 11:41, Joakim Ziegler via shifter-users wrote: > Hello, are Xpra 4.0 packages for CentOS 7.x (specifically, 7.8) planned any > time soon?No, Xpra v4 requires Python 3. CentOS 7.x is missing too many python3 packages to build xpra at present: https://xpra.org/trac/ticket/2760#comment:2 Cheers, Antoine From joakim at terminalmx.com Wed May 20 06:47:34 2020 From: joakim at terminalmx.com (Joakim Ziegler) Date: Wed, 20 May 2020 00:47:34 -0500 Subject: [winswitch] Xpra 4.0 packages for CentOS 7.x In-Reply-To: References: Message-ID: On Tue, May 19, 2020 at 11:54 PM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 20/05/2020 11:41, Joakim Ziegler via shifter-users wrote: >> Hello, are Xpra 4.0 packages for CentOS 7.x (specifically, 7.8) planned any >> time soon?No, Xpra v4 requires Python 3. > CentOS 7.x is missing too many python3 packages to build xpra at present: > https://xpra.org/trac/ticket/2760#comment:2 I see that most of the problems seem to be solvable with EPEL, which I already use. Is there any way to make this work presently? All of our workstations are stuck on CentOS 7 because of various software compatibility issues. Alternatively, can I use Xpra 4.0 on the server and 3 on the clients? Or will I need to downgrade everything to 3? -- Joakim Ziegler - Supervisor de postproducci?n - Terminal joakim at terminalmx.com - 044 55 2971 8514 - 5264 0864 From antoine at nagafix.co.uk Wed May 20 08:34:02 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 20 May 2020 14:34:02 +0700 Subject: [winswitch] Xpra 4.0 packages for CentOS 7.x In-Reply-To: References: Message-ID: On 20/05/2020 12:47, Joakim Ziegler via shifter-users wrote: > On Tue, May 19, 2020 at 11:54 PM Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: >> On 20/05/2020 11:41, Joakim Ziegler via shifter-users wrote: > >>> Hello, are Xpra 4.0 packages for CentOS 7.x (specifically, 7.8) planned > any >>> time soon?No, Xpra v4 requires Python 3. > >> CentOS 7.x is missing too many python3 packages to build xpra at present: >> https://xpra.org/trac/ticket/2760#comment:2 > > I see that most of the problems seem to be solvable with EPEL, which I > already use. Is there any way to make this work presently? All of our > workstations are stuck on CentOS 7 because of various software > compatibility issues. Yes, you could build v4 from source after installing the packages required from the EPEL repository. > Alternatively, can I use Xpra 4.0 on the server and 3 on the clients? Yes. > Or will I need to downgrade everything to 3? No: https://xpra.org/trac/wiki/Versions#Compatibility Cheers, Antoine From luca.manganelli at comune.trento.it Wed May 20 10:31:11 2020 From: luca.manganelli at comune.trento.it (Luca Manganelli) Date: Wed, 20 May 2020 11:31:11 +0200 Subject: [winswitch] Fastest connection parameters over SSH? Message-ID: Hello, which are fastest connection parameters over SSH? I am running over fiber connection to work. But the SSH connection seems slower than RDP (through XRDP). Is there any way to get faster image repaint? Thank you :-) -- Comune di Trento? via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221 tel. +39 0461.884111 | www.comune.trento.it ? From antoine at nagafix.co.uk Wed May 20 11:50:29 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 20 May 2020 17:50:29 +0700 Subject: [winswitch] Fastest connection parameters over SSH? In-Reply-To: References: Message-ID: On 20/05/2020 16:31, Luca Manganelli via shifter-users wrote: > Hello, > > which are fastest connection parameters over SSH? The defaults should be fine. Tuning is hard and often unnecessary. > I am running over fiber connection to work. But the SSH connection seems > slower than RDP (through XRDP). You should be able to achieve similar or better performance. > Is there any way to get faster image repaint? Have you tried increasing the `--min-speed` setting? And if possible, enable NVENC (requires an NVidia GPU) Without knowing more about your environment, OS and applications, it's difficult to give you better advice. Since you are comparing with XRDP, perhaps you're using desktop or shadow modes? Those are nowhere near as efficient as seamless mode. Cheers, Antoine > > Thank you :-) > From tmesposito00 at gmail.com Thu May 21 22:02:23 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Thu, 21 May 2020 17:02:23 -0400 Subject: [winswitch] server only? Message-ID: I have been using using my Windows 10 laptop as a client to connect to an xpra server running on a virtual desktop instance (VDI) of RHEL6 at work. I don't have root access on my VDI (company security policy) in order to install the xpra packages, but I was able to work around this by extracting ALL of the required rpms manually and updating my ENV accordingly to point to my "installation". The company is very slow to upgrade to new versions of RHEL/CentOS because of EDA tool compatibility issues and a conservative "if it isn't broke, don't fix it" philosophy. Therefore, I anticipate being stuck on xpra version 1.x for a while. In the meantime, I imagine that there have been performance improvements and bug fixes in 2.x and beyond that are not being back-ported to 1.x. It is possible that we MIGHT move to CentOS 7.3 relatively soon, but even that has been YEARS in the making, and the latest version of xpra isn't supported on CentOS 7.3 anyway. As another workaround, I've been playing around with the idea of compiling xpra from the source. I do have a recent version of python installed (3.7.1), and have been able to install many of the dependencies by creating a virtual environment and installing packages with pip. However, the fact that RHEL3 does not support gtk3 is kind of a show stopper. I haven't yet attempted to build gtk3 from source. This has got me thinking about the fact that xpra is monolithic package with both client and server together, and I suspect that the gtk3 dependencies relate mostly (or maybe only) to the client. In my use case however, I'll NEVER be running the client directly on the VDI, but only from my remote Windows 10 laptop, on which I can install the latest xpra client version. Is there some way to build xpra with ONLY server support? I'm guessing not, but its something to think about. I'm sure there are other use cases out there like mine. From antoine at nagafix.co.uk Fri May 22 03:32:15 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 22 May 2020 09:32:15 +0700 Subject: [winswitch] server only? In-Reply-To: References: Message-ID: On 22/05/2020 04:02, Thomas Esposito via shifter-users wrote: > I have been using using my Windows 10 laptop as a client to connect to an > xpra server running on a virtual desktop instance (VDI) of RHEL6 at work. I > don't have root access on my VDI (company security policy) in order to > install the xpra packages, but I was able to work around this by extracting > ALL of the required rpms manually and updating my ENV accordingly to point > to my "installation". You may want to look into these projects that make it easier to manage prefixed installations: http://modules.sourceforge.net/ https://lmod.readthedocs.io/en/latest/ Whatever you do, make sure to set this environment variable to tell xpra to only use paths within your prefixed installation: XPRA_INSTALL_PREFIX=/path/to/v3.0.9/usr > The company is very slow to upgrade to new versions of RHEL/CentOS because > of EDA tool compatibility issues and a conservative "if it isn't broke, > don't fix it" philosophy. And rightly so. (though there are also security considerations with running systems that don't receive updates..) > Therefore, I anticipate being stuck on xpra > version 1.x for a while. In the meantime, I imagine that there have been > performance improvements and bug fixes in 2.x and beyond that are not being > back-ported to 1.x. Correct. There are many. > It is possible that we MIGHT move to CentOS 7.3 > relatively soon, but even that has been YEARS in the making, and the latest > version of xpra isn't supported on CentOS 7.3 anyway. Even the 3.0.x branch requires 7.4 or later now. Something broke on 7.3 builds a while back and I never bothered to fix it, it should be fixable but you may not get all the features (IIRC: no audio?). > As another workaround, I've been playing around with the idea of compiling > xpra from the source. I do have a recent version of python installed > (3.7.1), and have been able to install many of the dependencies by creating > a virtual environment and installing packages with pip. However, the fact > that RHEL3 does not support gtk3 is kind of a show stopper. I haven't yet > attempted to build gtk3 from source. That's very hard to do and maintain (we do that for MacOS). See: https://unix.stackexchange.com/questions/242074/ > This has got me thinking about the fact that xpra is monolithic package > with both client and server together, That's not true: in v3, you get split RPM packages that allow you to install the client and server separately, and even mix versions for python2 and python3 on the same system. The Debian packaging is still mostly monolithic: only the html5 client is split up in the DEBs. > and I suspect that the gtk3 > dependencies relate mostly (or maybe only) to the client. Unfortunately that's not the case: GTK3 is also used on the server. (though we would like to get rid of it eventually) > In my use case > however, I'll NEVER be running the client directly on the VDI, but only > from my remote Windows 10 laptop, on which I can install the latest xpra > client version. Is there some way to build xpra with ONLY server support? > I'm guessing not, but its something to think about. ./setup.py --without-client There are many other optional components, for more information: ./setup.py --help Cheers, Antoine > I'm sure there are other use cases out there like mine. From tmesposito00 at gmail.com Fri May 22 04:35:23 2020 From: tmesposito00 at gmail.com (Thomas Esposito) Date: Thu, 21 May 2020 23:35:23 -0400 Subject: [winswitch] server only? In-Reply-To: References: Message-ID: I only connect via tcp and don't use any kind of encryption. This is all going on inside the corporate VPN. I also don't need audio. On Thu, May 21, 2020, 10:32 PM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 22/05/2020 04:02, Thomas Esposito via shifter-users wrote: > > I have been using using my Windows 10 laptop as a client to connect to an > > xpra server running on a virtual desktop instance (VDI) of RHEL6 at > work. I > > don't have root access on my VDI (company security policy) in order to > > install the xpra packages, but I was able to work around this by > extracting > > ALL of the required rpms manually and updating my ENV accordingly to > point > > to my "installation". > You may want to look into these projects that make it easier to manage > prefixed installations: > http://modules.sourceforge.net/ > https://lmod.readthedocs.io/en/latest/ > > Whatever you do, make sure to set this environment variable to tell xpra > to only use paths within your prefixed installation: > XPRA_INSTALL_PREFIX=/path/to/v3.0.9/usr > > > The company is very slow to upgrade to new versions of RHEL/CentOS > because > > of EDA tool compatibility issues and a conservative "if it isn't broke, > > don't fix it" philosophy. > And rightly so. (though there are also security considerations with > running systems that don't receive updates..) > > > Therefore, I anticipate being stuck on xpra > > version 1.x for a while. In the meantime, I imagine that there have been > > performance improvements and bug fixes in 2.x and beyond that are not > being > > back-ported to 1.x. > Correct. There are many. > > > It is possible that we MIGHT move to CentOS 7.3 > > relatively soon, but even that has been YEARS in the making, and the > latest > > version of xpra isn't supported on CentOS 7.3 anyway. > Even the 3.0.x branch requires 7.4 or later now. > Something broke on 7.3 builds a while back and I never bothered to fix > it, it should be fixable but you may not get all the features (IIRC: no > audio?). > > > As another workaround, I've been playing around with the idea of > compiling > > xpra from the source. I do have a recent version of python installed > > (3.7.1), and have been able to install many of the dependencies by > creating > > a virtual environment and installing packages with pip. However, the fact > > that RHEL3 does not support gtk3 is kind of a show stopper. I haven't yet > > attempted to build gtk3 from source. > That's very hard to do and maintain (we do that for MacOS). See: > https://unix.stackexchange.com/questions/242074/ > > > This has got me thinking about the fact that xpra is monolithic package > > with both client and server together, > That's not true: in v3, you get split RPM packages that allow you to > install the client and server separately, and even mix versions for > python2 and python3 on the same system. > The Debian packaging is still mostly monolithic: only the html5 client > is split up in the DEBs. > > > and I suspect that the gtk3 > > dependencies relate mostly (or maybe only) to the client. > Unfortunately that's not the case: GTK3 is also used on the server. > (though we would like to get rid of it eventually) > > > In my use case > > however, I'll NEVER be running the client directly on the VDI, but only > > from my remote Windows 10 laptop, on which I can install the latest xpra > > client version. Is there some way to build xpra with ONLY server support? > > I'm guessing not, but its something to think about. > ./setup.py --without-client > There are many other optional components, for more information: > ./setup.py --help > > Cheers, > Antoine > > > I'm sure there are other use cases out there like mine. > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users > From joakim at terminalmx.com Sat May 23 01:35:24 2020 From: joakim at terminalmx.com (Joakim Ziegler) Date: Fri, 22 May 2020 19:35:24 -0500 Subject: [winswitch] Pressing alt sometimes generates space characters, and dragging window is unreliable Message-ID: I've installed Xpra 4.0.1 on the server (Ubuntu 20.04) and Xpra 3.0.9 on the client (Centos 7.7.1908), and I'm using it to run Chrome, we're currently in testing, and everything seems to be working fine, apart from two fairly minor problems: We use Chrome in large part for accessing Google Docs, and we noticed a strange problem. Sometimes when pressing Alt-Tab to switch windows, the current cell in Google Sheets would blank, that is, the contents would be replaced by one or more space characters. At first we thought this was something that happens when switching windows, but it turns out, it's something that happens irregularly when pressing Alt. If you open Google Docs and move around between cells with contents in them by clicking the mouse, and then press Alt, some times (one out of five, maybe), pressing Alt will generate space key presses, which blanks out the cells. This only happens after having used the mouse to click on the cells, and what's stranger, even if it doesn't happen every time, when it does happen, the number of space key presses generated seems to be proportional to the number of times you've pressed Alt before this happens, so if it happens after trying to provoke it three times, you'll get three space characters. Is this a known bug? Might it be a result of using 3.0.9 on the client and 4.0.1 on the server? I'm happy to generate a formal bug report, but I wanted to know if this was a known problem that might be solved by an upgrade first. Secondly, and this is less important, when dragging the Chrome window by the title bar, the first time you drag, it works fine, but if you release the mouse button and then immediately try to drag the window again, it won't move. It'll move again on the third attempt, then not on the fourth, and so on. I'm also wondering if this is a known problem, and/or related to using 3.0.9 on the client. -- Joakim Ziegler - Supervisor de postproducci?n - Terminal joakim at terminalmx.com - 044 55 2971 8514 - 5264 0864 From antoine at nagafix.co.uk Sat May 23 04:37:39 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 23 May 2020 10:37:39 +0700 Subject: [winswitch] Pressing alt sometimes generates space characters, and dragging window is unreliable In-Reply-To: References: Message-ID: <53421d53-3221-6985-b494-4f3852723da9@nagafix.co.uk> On 23/05/2020 07:35, Joakim Ziegler via shifter-users wrote: > I've installed Xpra 4.0.1 on the server (Ubuntu 20.04) and Xpra 3.0.9 on > the client (Centos 7.7.1908), and I'm using it to run Chrome, we're > currently in testing, and everything seems to be working fine, apart from > two fairly minor problems: > > We use Chrome in large part for accessing Google Docs, and we noticed a > strange problem. Sometimes when pressing Alt-Tab to switch windows, the > current cell in Google Sheets would blank, that is, the contents would be > replaced by one or more space characters. At first we thought this was > something that happens when switching windows, but it turns out, it's > something that happens irregularly when pressing Alt. Modifier keys are a pain to synchronize generally, Alt-Tabbing away brings its own set of problems: since the window is no longer in focus after Alt-Tab, the key release events go missing. > If you open Google Docs and move around between cells with contents in them > by clicking the mouse, and then press Alt, some times (one out of five, > maybe), pressing Alt will generate space key presses, which blanks out the > cells. This only happens after having used the mouse to click on the cells, > and what's stranger, even if it doesn't happen every time, when it does > happen, the number of space key presses generated seems to be proportional > to the number of times you've pressed Alt before this happens, so if it > happens after trying to provoke it three times, you'll get three space > characters. > > Is this a known bug? No. This one I was not aware of. > Might it be a result of using 3.0.9 on the client and > 4.0.1 on the server? No. > I'm happy to generate a formal bug report, but I > wanted to know if this was a known problem that might be solved by an > upgrade first. Please create a ticket. > Secondly, and this is less important, when dragging the Chrome window by > the title bar, the first time you drag, it works fine, but if you release > the mouse button and then immediately try to drag the window again, it > won't move. It'll move again on the third attempt, then not on the fourth, > and so on. I'm also wondering if this is a known problem, and/or related to > using 3.0.9 on the client. That's probably something to do with the button state not getting synchronized properly: the server or the application never sees the button being released, so the next button press doesn't do anything. I have seen this with the html5 client before, not so much with the X11 python client. Would you mind creating another ticket for this? Both bugs should be fixable given precise and preferably simple steps to reproduce them. Cheers, Antoine From joakim at terminalmx.com Tue May 26 02:21:41 2020 From: joakim at terminalmx.com (Joakim Ziegler) Date: Mon, 25 May 2020 20:21:41 -0500 Subject: [winswitch] Pressing alt sometimes generates space characters, and dragging window is unreliable In-Reply-To: <53421d53-3221-6985-b494-4f3852723da9@nagafix.co.uk> References: <53421d53-3221-6985-b494-4f3852723da9@nagafix.co.uk> Message-ID: Hello, I'm trying to register on Trac to create tickets for these two bugs, however, I'm getting the following error after filling out the registration form: Cannot find an implementation of the ICaptchaMethod interface named ImageCaptcha. Please check that the Component is enabled or update the option [spam-filter] captcha in trac.ini. -- Joakim Ziegler - Supervisor de postproducci?n - Terminal joakim at terminalmx.com - 044 55 2971 8514 - 5264 0864 From vuori at notcom.org Mon May 25 19:38:29 2020 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Mon, 25 May 2020 21:38:29 +0300 Subject: [winswitch] Unable to register on bugtracker + Win32 issues Message-ID: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> Hi, it doesn't seem to be possible to create an account on the bugtracker. After filling the register form, a "Configuration error" page with the following message is shown: "Cannot find an implementation of the ICaptchaMethod interface named ImageCaptcha. Please check that the Component is enabled or update the option [spam-filter] captcha in trac.ini." The issues I was going to report are simple so I'll just put them here for now (both Win32 with 4.0.1, using the zip version): 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: "The procedure entry point libintl_snprintf could not be located in the dynamic link library [...]\lib\libfontconfig-1.dll." Copying the libintl-8.dll in lib one level up works. 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. This is not very useful as generally X11 keycode = PC/AT scancode + 8. Client should probably add 8 to the scancode (event.keycode) when connecting from Win32 to X11. Please reply directly if needed, I'm not currently on the list. -Valtteri From antoine at nagafix.co.uk Tue May 26 11:21:15 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 26 May 2020 17:21:15 +0700 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> Message-ID: On 26/05/2020 01:38, Valtteri Vuorikoski via shifter-users wrote: > Hi, it doesn't seem to be possible to create an account on the > bugtracker. After filling the register form, a "Configuration error" > page with the following message is shown: "Cannot find an implementation > of the ICaptchaMethod interface named ImageCaptcha. Please check that > the Component is enabled or update the option [spam-filter] captcha in > trac.ini." Thank you for reporting this problem. A recent system update had broken the tracker registration page. This should be fixed now. > The issues I was going to report are simple so I'll just put them here > for now (both Win32 with 4.0.1, using the zip version): Which exact version? (32 or 64-bit, python2 or python3, client-only build? etc) Can you give us the MD5 sum of the ZIP file you used? > 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: > "The procedure entry point libintl_snprintf could not be located in the > dynamic link library [...]\lib\libfontconfig-1.dll." Copying the > libintl-8.dll in lib one level up works. That's odd, I've tested a few builds on a clean VM and I didn't see this error. Is this an alert box? Which shortcut do you run? > 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. > This is not very useful as generally X11 keycode = PC/AT scancode + 8. > Client should probably add 8 to the scancode (event.keycode) when > connecting from Win32 to X11. This is not enabled by default and it is not meant to be used across operating systems. This is only useful at present when the client and server OS are identical. (ie: Linux to Linux, or Windows to Windows) When a translation is going to be needed, don't use raw mode. > Please reply directly if needed, I'm not currently on the list. Done. (please make sure to keep the list CCed) Cheers, Antoine > > ?-Valtteri > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > https://lists.devloop.org.uk/mailman/listinfo/shifter-users From vuori at notcom.org Wed May 27 21:05:31 2020 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Wed, 27 May 2020 23:05:31 +0300 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> Message-ID: <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> On 2020-05-26 13:21, Antoine Martin wrote: > On 26/05/2020 01:38, Valtteri Vuorikoski via shifter-users wrote: > Thank you for reporting this problem. A recent system update had broken > the tracker registration page. This should be fixed now. Great, thanks. >> The issues I was going to report are simple so I'll just put them here >> for now (both Win32 with 4.0.1, using the zip version): > Which exact version? (32 or 64-bit, python2 or python3, client-only > build? etc) > Can you give us the MD5 sum of the ZIP file you used? The zip file available on the download page, which contains Xpra-Python3-x86_64_4.0.1-r26379. zip md5sum: ada76608e7b98d55d958f9820f6c0693 >> 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: >> "The procedure entry point libintl_snprintf could not be located in the >> dynamic link library [...]\lib\libfontconfig-1.dll." Copying the >> libintl-8.dll in lib one level up works. > That's odd, I've tested a few builds on a clean VM and I didn't see this > error. Is this an alert box? Which shortcut do you run? Yes, I uploaded screenshots to https://imgur.com/a/eD4NltE . The left dialog appears first and the right one immediately afterward. There are several other copies of libintl-8.dll on my system, since a lot of open source software ships it. One of those might be getting picked up from PATH instead of the one in lib. Xpra.exe, Xpra-Launcher.exe and Xpra_cmd.exe all fail. After copying the dll from lib one level up, everything works. >> 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. >> This is not very useful as generally X11 keycode = PC/AT scancode + 8. >> Client should probably add 8 to the scancode (event.keycode) when >> connecting from Win32 to X11. > This is not enabled by default and it is not meant to be used across > operating systems. > This is only useful at present when the client and server OS are > identical. (ie: Linux to Linux, or Windows to Windows) > When a translation is going to be needed, don't use raw mode. Is there any other way to _not_ have Xpra do keysym-based mapping though? Use case: I use a heavily customized multilingual layout on Windows. When connecting to X11 boxen, I generally only need standard US layout. I would prefer that keys are mapped using the server-side Xkb layout starting from keycodes (as happens with VNC, NoMachine and such) to avoid funkiness. Example of a problem: the [ key (scancode 0x1a) produces ? (adiaeresis) with my Windows layout. When I connect with Xpra, it sets Xkb layout "us" on the remote (my Windows layout has locale US so this is an acceptable guess). When I press the [ key, nothing happens because (as far as I can tell) Xpra server side doesn't know what to do with the keysym adiaeresis since it doesn't appear in the Xkb us layout. What would preferably happen is that the scancode/keycode gets passed to X as usual and eventually pops up as [. -Valtteri From wssddc at wssddc.com Wed May 27 21:38:00 2020 From: wssddc at wssddc.com (Bob Babcock) Date: Wed, 27 May 2020 16:38:00 -0400 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> Message-ID: Valtteri Vuorikoski via shifter-users wrote: > Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: My memory is vague, but I think I saw something like this some time ago.? I installed a new Xpra on top of an existing one and the new version had DLLs moved into a subdirectory which meant old equivalents didn't get overwritten.? A clean new install fixed it. From antoine at nagafix.co.uk Thu May 28 07:47:09 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2020 13:47:09 +0700 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> Message-ID: >>> 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: >>> "The procedure entry point libintl_snprintf could not be located in the >>> dynamic link library [...]\lib\libfontconfig-1.dll." Copying the >>> libintl-8.dll in lib one level up works. >> That's odd, I've tested a few builds on a clean VM and I didn't see this >> error. Is this an alert box? Which shortcut do you run? > > Yes, I uploaded screenshots to https://imgur.com/a/eD4NltE . The left > dialog appears first and the right one immediately afterward. > > There are several other copies of libintl-8.dll on my system, since a > lot of open source software ships it. One of those might be getting > picked up from PATH instead of the one in lib. Xpra.exe, > Xpra-Launcher.exe and Xpra_cmd.exe all fail. Yes, that must be it. That's a relief: I have verified and the ZIP file you are having problems with does work fine on a clean system. > After copying the dll from > lib one level up, everything works. Rather than moving the DLLs, I've changed the path search order: http://xpra.org/trac/changeset/26483 This should fix the problem on your system. There's a 4.1 beta build here: https://xpra.org/beta/windows/ >>> 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. >>> This is not very useful as generally X11 keycode = PC/AT scancode + 8. >>> Client should probably add 8 to the scancode (event.keycode) when >>> connecting from Win32 to X11. >> This is not enabled by default and it is not meant to be used across >> operating systems. >> This is only useful at present when the client and server OS are >> identical. (ie: Linux to Linux, or Windows to Windows) >> When a translation is going to be needed, don't use raw mode. > > Is there any other way to _not_ have Xpra do keysym-based mapping though? Whenever this approach has been attempted, there has always been problems. I've just tried it again with an MS Windows client connecting to a Linux seamless server, and it didn't go well. > Use case: I use a heavily customized multilingual layout on Windows. > When connecting to X11 boxen, I generally only need standard US layout. > I would prefer that keys are mapped using the server-side Xkb layout > starting from keycodes (as happens with VNC, NoMachine and such) to > avoid funkiness. > > Example of a problem: the [ key (scancode 0x1a) produces ? (adiaeresis) > with my Windows layout. When I connect with Xpra, it sets Xkb layout > "us" on the remote (my Windows layout has locale US so this is an > acceptable guess). When I press the [ key, nothing happens because (as > far as I can tell) Xpra server side doesn't know what to do with the > keysym adiaeresis since it doesn't appear in the Xkb us layout. What > would preferably happen is that the scancode/keycode gets passed to X as > usual and eventually pops up as [. You can try this server-side change (without --keyboard-raw): http://xpra.org/trac/changeset/26486 It will use the keyval for any key that it fails to locate. This should do what you want. If not, please create a ticket with more details. Cheers, Antoine > > ?-Valtteri From antoine at nagafix.co.uk Thu May 28 07:49:06 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 28 May 2020 13:49:06 +0700 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> Message-ID: <41c5fb32-0a26-e9a9-f497-8dcfb470449b@nagafix.co.uk> On 28/05/2020 03:38, Bob Babcock wrote: > Valtteri Vuorikoski via shifter-users wrote: >> Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: > > My memory is vague, but I think I saw something like this some time > ago.? I installed a new Xpra on top of an existing one and the new > version had DLLs moved into a subdirectory which meant old equivalents > didn't get overwritten.? A clean new install fixed it. A few years ago, yes, this used to be a problem - and a difficult one to diagnose too. Nowadays, xpra uninstalls the previous version before installing again: https://www.xpra.org/trac/changeset/15053 You can still have 32-bit and 64-bit versions installed in parallel: https://www.xpra.org/trac/changeset/21951 Antoine From vuori at notcom.org Thu May 28 18:28:30 2020 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Thu, 28 May 2020 20:28:30 +0300 Subject: [winswitch] Unable to register on bugtracker + Win32 issues In-Reply-To: References: <40c424ba-73ab-74a6-ee15-91659d618818@notcom.org> <6adbc7cd-a8db-6c62-346b-1e4c9ae159dd@notcom.org> Message-ID: <8aeca4b8-f960-d139-eba1-a45609868e0c@notcom.org> On 2020-05-28 09:47, Antoine Martin wrote: >>>> 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe: >>>> "The procedure entry point libintl_snprintf could not be located in the >>>> dynamic link library [...]\lib\libfontconfig-1.dll." Copying the >>>> libintl-8.dll in lib one level up works. > > This should fix the problem on your system. > There's a 4.1 beta build here: > https://xpra.org/beta/windows/ Yep, working fine out of the box now. >>>> 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode. >>>> This is not very useful as generally X11 keycode = PC/AT scancode + 8. >>>> Client should probably add 8 to the scancode (event.keycode) when >>>> connecting from Win32 to X11. > You can try this server-side change (without --keyboard-raw): > http://xpra.org/trac/changeset/26486 > It will use the keyval for any key that it fails to locate. > This should do what you want. Thanks! I'll give it a try. -Valtteri From alan at alanhoyle.com Fri May 29 00:11:09 2020 From: alan at alanhoyle.com (Alan Hoyle) Date: Thu, 28 May 2020 19:11:09 -0400 Subject: [winswitch] New to xpra: initialization error? Message-ID: I just installed xpra for the first time on my mac, and it doesn't seem to let me start applications on the server side. I installed it via homebrew/cask, but didn't do anything on the remote end. If I run "ssh -Y $LOGIN xterm" I get an xterm appearing after a few seconds (X apps run this way are not performant which is why I'm looking into xpra). If I run the following command, I get some warnings, it says the authentication passed, and then it errors out with: xpra initialization error: connection failed: all SSH remote proxy commands have failed See below (mildly edited to remove our 'welcome' message). $ xpra start ssh:$LOGIN --start=/usr/bin/xterm /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/gui.py:90: Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' osxapp.set_menu_bar(mh.rebuild()) (Xpra:29629): Gtk-CRITICAL **: 18:32:36.507: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed 2020-05-28 18:32:36,623 Xpra GTK3 client version 4.0.1-r26380 64-bit 2020-05-28 18:32:36,642 running on Mac OS X 10.15.5 2020-05-28 18:32:37,433 GStreamer version 1.16.2 for Python 3.8.2 64-bit 2020-05-28 18:32:37,550 OpenGL_accelerate module loaded 2020-05-28 18:32:37,566 Using accelerated ArrayDatatype /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: Warning: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: Warning: g_object_set_qdata_full: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed return GLContext().check_support(force_enable) #pylint: disable=not-callable 2020-05-28 18:32:38,178 OpenGL enabled with AMD Radeon Pro 5500M OpenGL Engine 2020-05-28 18:32:38,278 Connected (version 2.0, client OpenSSH_7.4) 2020-05-28 18:32:38,570 Auth banner: b'[...snip...]' 2020-05-28 18:32:38,878 Authentication (publickey) successful! xpra initialization error: connection failed: all SSH remote proxy commands have failed -- - Alan Hoyle - alan at alanhoyle.com - http://www.alanhoyle.com/ - From antoine at nagafix.co.uk Fri May 29 02:29:03 2020 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 29 May 2020 08:29:03 +0700 Subject: [winswitch] New to xpra: initialization error? In-Reply-To: References: Message-ID: <5459d676-b61c-5b91-c074-a2bbd61f7d91@nagafix.co.uk> On 29/05/2020 06:11, Alan Hoyle via shifter-users wrote: > I just installed xpra for the first time on my mac, and it doesn't seem to > let me start applications on the server side. I installed it via > homebrew/cask, but didn't do anything on the remote end. Be aware that this is not the recommended way of installing xpra, so it may or may not work properly, features may be missing, etc. > If I run "ssh -Y $LOGIN xterm" I get an xterm appearing after a few seconds > (X apps run this way are not performant which is why I'm looking into xpra). > > If I run the following command, I get some warnings, it says the > authentication passed, and then it errors out with: > xpra initialization error: > connection failed: all SSH remote proxy commands have failed My guess is that you have not installed xpra on your server. Cheers Antoine > > See below (mildly edited to remove our 'welcome' message). > > $ xpra start ssh:$LOGIN --start=/usr/bin/xterm > /Applications/Xpra.app/Contents/Resources/lib/python/xpra/platform/darwin/gui.py:90: > Warning: invalid cast from 'GtkMenuBar' to 'GtkWindow' > osxapp.set_menu_bar(mh.rebuild()) > > (Xpra:29629): Gtk-CRITICAL **: 18:32:36.507: gtk_window_add_accel_group: > assertion 'GTK_IS_WINDOW (window)' failed > 2020-05-28 18:32:36,623 Xpra GTK3 client version 4.0.1-r26380 64-bit > 2020-05-28 18:32:36,642 running on Mac OS X 10.15.5 > 2020-05-28 18:32:37,433 GStreamer version 1.16.2 for Python 3.8.2 64-bit > 2020-05-28 18:32:37,550 OpenGL_accelerate module loaded > 2020-05-28 18:32:37,566 Using accelerated ArrayDatatype > /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: > Warning: g_object_get_qdata: assertion 'G_IS_OBJECT (object)' failed > return GLContext().check_support(force_enable) #pylint: > disable=not-callable > /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: > Warning: g_object_set_qdata_full: assertion 'G_IS_OBJECT (object)' failed > return GLContext().check_support(force_enable) #pylint: > disable=not-callable > /Applications/Xpra.app/Contents/Resources/lib/python/xpra/client/gl/gtk3/nativegl_client_window.py:12: > Warning: g_object_unref: assertion 'G_IS_OBJECT (object)' failed > return GLContext().check_support(force_enable) #pylint: > disable=not-callable > 2020-05-28 18:32:38,178 OpenGL enabled with AMD Radeon Pro 5500M OpenGL > Engine > 2020-05-28 18:32:38,278 Connected (version 2.0, client OpenSSH_7.4) > 2020-05-28 18:32:38,570 Auth banner: b'[...snip...]' > 2020-05-28 18:32:38,878 Authentication (publickey) successful! > xpra initialization error: > connection failed: all SSH remote proxy commands have failed > > > -- > - Alan Hoyle - alan at alanhoyle.com - http://www.alanhoyle.com/ - From alan at alanhoyle.com Fri May 29 02:56:09 2020 From: alan at alanhoyle.com (Alan Hoyle) Date: Thu, 28 May 2020 21:56:09 -0400 Subject: [winswitch] New to xpra: initialization error? In-Reply-To: <5459d676-b61c-5b91-c074-a2bbd61f7d91@nagafix.co.uk> References: <5459d676-b61c-5b91-c074-a2bbd61f7d91@nagafix.co.uk> Message-ID: On Thu, May 28, 2020 at 9:29 PM Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > > My guess is that you have not installed xpra on your server. > Ugh. That is indeed the case. Somehow it is unclear (at least to me) from the documentation on xpra.org that one must have xpra installed on both the client and the server in order for it to work. -- - Alan Hoyle - alan at alanhoyle.com - http://www.alanhoyle.com/ -