From titusiforum at gmail.com Wed May 3 06:32:47 2017 From: titusiforum at gmail.com (Titusi Forum) Date: Tue, 2 May 2017 22:32:47 -0700 Subject: [winswitch] XPRA HTML5 Message-ID: I got a quick question: If I try to open xpra html5 client inside a modal window/iframe or a frame ... do you foresee any issues? Thanks in advance! From antoine at nagafix.co.uk Wed May 3 07:25:13 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 3 May 2017 13:25:13 +0700 Subject: [winswitch] XPRA HTML5 In-Reply-To: References: Message-ID: On 03/05/17 12:32, Titusi Forum via shifter-users wrote: > I got a quick question: > > If I try to open xpra html5 client inside a modal window/iframe or a frame > ... do you foresee any issues? The window attributes should only affect how the client's window manager handles it, not the contents of the window itself. (i)frames are also no different from regular windows, as far as the HTML and Javascript code running within them is concerned. (by design) It should be trivial to try it out. But maybe I am misunderstanding your question? Cheers Antoine > > Thanks in advance! From rob at calypsoblue.org Wed May 3 16:51:08 2017 From: rob at calypsoblue.org (Rob Lemley) Date: Wed, 3 May 2017 11:51:08 -0400 Subject: [winswitch] XPRA HTML5 In-Reply-To: References: Message-ID: I had no problems getting the html client to run in an iframe. I preferred that method over trying to get it in a modal because I didn't want the different javascript libraries to interfere with each other by accident. Antoine, One thing I have been meaning to ask, I'd like the ability to pass the websocket URL in as an option to the Client() constructor. Is that something you'd be willing to add? My use case is getting an Xpra client to run in another web application that uses its own websockets on other URLs and it would be nice to have Xpra follow the same pattern. Thanks! -Rob On Wed, May 3, 2017 at 2:25 AM, Antoine Martin via shifter-users wrote: > On 03/05/17 12:32, Titusi Forum via shifter-users wrote: >> I got a quick question: >> >> If I try to open xpra html5 client inside a modal window/iframe or a frame >> ... do you foresee any issues? > The window attributes should only affect how the client's window manager > handles it, not the contents of the window itself. > (i)frames are also no different from regular windows, as far as the HTML > and Javascript code running within them is concerned. (by design) > > It should be trivial to try it out. > But maybe I am misunderstanding your question? > > Cheers > Antoine > >> >> Thanks in advance! > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Wed May 3 16:56:04 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 3 May 2017 22:56:04 +0700 Subject: [winswitch] XPRA HTML5 In-Reply-To: References: Message-ID: On 03/05/17 22:51, Rob Lemley wrote: > I had no problems getting the html client to run in an iframe. I > preferred that method over trying to get it in a modal because I > didn't want the different javascript libraries to interfere with each > other by accident. Ah, right. You're talking about a modal browser window. (and I was thinking of modal native windows..) > Antoine, One thing I have been meaning to ask, I'd like the ability to > pass the websocket URL in as an option to the Client() constructor. Is > that something you'd be willing to add? My use case is getting an Xpra > client to run in another web application that uses its own websockets > on other URLs and it would be nice to have Xpra follow the same > pattern. The client takes many options, including "host", "port" and the "ssl" flag. A path could easily be added to that. Feel free to make a ticket for it, it really shouldn't take long to implement. Cheers Antoine > > Thanks! > > -Rob > > On Wed, May 3, 2017 at 2:25 AM, Antoine Martin via shifter-users > wrote: >> On 03/05/17 12:32, Titusi Forum via shifter-users wrote: >>> I got a quick question: >>> >>> If I try to open xpra html5 client inside a modal window/iframe or a frame >>> ... do you foresee any issues? >> The window attributes should only affect how the client's window manager >> handles it, not the contents of the window itself. >> (i)frames are also no different from regular windows, as far as the HTML >> and Javascript code running within them is concerned. (by design) >> >> It should be trivial to try it out. >> But maybe I am misunderstanding your question? >> >> Cheers >> Antoine >> >>> >>> Thanks in advance! >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users From yunxiang at iscas.ac.cn Tue May 9 06:50:08 2017 From: yunxiang at iscas.ac.cn (=?GBK?B?wt7Uxs/o?=) Date: Tue, 9 May 2017 13:50:08 +0800 (GMT+08:00) Subject: [winswitch] help: xpra client with chinese input Message-ID: hello, I want to use xpra for writing document on gedit with Chinese input. I ran the command like ?xpra start --bind-tcp=0.0.0.0:10000 --html=on --start-child=gedit --sharing=on?, but I can not switch input to Chinese, right now I can only use english as input. Thank you a lot for your help! From jiang.qian at gmail.com Tue May 9 07:30:06 2017 From: jiang.qian at gmail.com (Jiang Qian) Date: Tue, 9 May 2017 02:30:06 -0400 Subject: [winswitch] help: xpra client with chinese input In-Reply-To: References: Message-ID: I have tried also to use international input for xpra, either using the input software (e.g. scim) in the server side or in the client side, without success. I filed a bug a while back but at the time it seemed to difficult to solve and the linux/xorg input stack was too confusing for the developer. The only solution I came up with is to use the input that comes with the software itself, usually via extension. I don't use gedit, but for gvim, there is this internal extension to input cjk http://www.vim.org/scripts/script.php?script_id=2506 For web browser, google chrome has th google input tools, which works just fine over xpra https://chrome.google.com/webstore/detail/google-input-tools/mclkkofklkfljcocdinagocijmpgbhab?utm_source=chrome-app-launcher-info-dialog I haven't used this in firefox but it may work for firefox: https://addons.mozilla.org/en-US/firefox/addon/fireinput/ Of course, if you enable clipboard support, and your writing is not extensive, you could just quickly write in local windows and then paste to the xpra window. I hope this helps. Qian Jiang On Tue, May 9, 2017 at 1:50 AM, ??? via shifter-users wrote: > hello, > > I want to use xpra for writing document on gedit with Chinese input. I ran the command like ?xpra start --bind-tcp=0.0.0.0:10000 --html=on --start-child=gedit --sharing=on?, but I can not switch input to Chinese, right now I can only use english as input. Thank you a lot for your help! > > > > > > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Sun May 14 15:36:41 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 14 May 2017 21:36:41 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0.6 LTS : many minor fixes Message-ID: <63c1897f-9c00-3d45-d135-50c430c6a354@nagafix.co.uk> Hi, This update contains an large number of fixes but none of them are critical. Most of the fixes are in the HTML5 client, SSL socket support and various other subsystems: clipboard, audio, shadow servers, etc. The only noteworthy change is for the packaging of the media codecs: those are now loading the correct version of the library when multiple versions are installed - this should prevent some warnings and maybe even fix some performance and stability issues as well. There is no urgency to update if your were not affected by those issues. Release notes: * fix SSL connection failures * fix SSL servers on MS Windows * fix SSL-upgradable sockets not exposed via mDNS * fix server startup failures when running without stdout or stderr * fix loss of clipboard synchronization with direction restrictions * fix library versions used when multiple versions are installed * fix inconsistent desktop state after using the screenshot feature on MS Windows * fix raising of windows when connecting from Mac OS * fix exit code of helper commands on Mac OS * fix X11 ICC profile version format, continue if missing * fix X11 extensions checks, prevent event code mismatch * fix window model leak when we fail to manage a window * fix server errors with locked batch delays * fix window opacity forwarding * fix missing system tray with Ubuntu Zesty * fix audio stream duplicated header * fix errors in scrolling detection error handler * fix nvenc codec name shown in config file example * fix nvenc encoding reported (wrongly hardcoded to H264) * fix vp8 codec maximum picture size (8kx4k on posix platforms) * fix picture stride errors with some shadow servers * fix missed characters in HTML5 client disconnection message * fix HTML5 password field wrongly greyed out * fix HTML5 window title bar wrapping * fix HTML5 handling of Unicode window titles * fix HTML5 exception in audio error handler * fix HTML5 using the wrong audio codec * fix HTML5 audio codec fallback * fix HTML5 audio not closed on end-of-stream * fix HTML5 MediaSource API availability detection * fix HTML5 spurious paint error messages * fix connection to IPv6 addresses * fix handling of unsupported connection types * fix backwards compatibility for hmac authentication * fix handling of desktop window resizing, prevent it from moving off-screen * fix error handling of screenshot feature from the bug report tool * fix missing error exit code from test-connect and remote-start subcommands * fix lost window icons with some window managers * fix python-lz4 library version detection * fix audio forwarding with MS Windows clients in GUI mode * disable "legacy mp3" audio decoding in the HTML5 client * avoid warnings when running with newer versions of the config files * blacklist Mesa Intel Ivybridge GPU * more helpful warning message when dbus bindings are missing * improve error handling when native Mac OS bindings are missing * support relative file paths in authentication modules * Mac OS library updates: Pillow 4.1, ffmpeg 3.3, python-lz4 0.9.1 The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine From shanew at shanew.net Wed May 31 23:22:34 2017 From: shanew at shanew.net (Shane Williams) Date: Wed, 31 May 2017 17:22:34 -0500 (CDT) Subject: [winswitch] xpra 2.0 security questions Message-ID: After using it personally over the yeears, I've suggested my work install xpra for our users (particularly to replace VNC) and during our internal staff evaluation everyone has been impressed. We did come up with a few (mostly security-related) questions. If any of these would be better addressed as tickets via trac, just let me know. 1. We like that xpra defaults to SSH when you start it on linux and we'd like to make it impossible or at least harder for users to start up a server using non-secure protocols. Is there a way to disable these (or even enable SSH only) via system-wide configs or in some other way? Even if users could over-ride settings individually, creating that extra burden would discourage use of non-secure connections 2. When saving a "profile" via the launcher, passwords are stored in plaintext. At the very least, could the launcher GUI make it clear that saved passwords will be stored in this way? Or is there a way to disable that, maybe even by default (not that we have much control over users' launcher configs)? 3. We also notice that when SSH is selected as the mode, launchers on some platforms remove the password field from the GUI, but others do not (MacOS, in particular doesn't seem to). Is this a built in difference, or is it dependent on the existence of some "ask-pass" binary? 3.5 As a feature request, it seems like the list of "modes" are in least-secure to most-secure order, with plain TCP as the default. It seems like reversing this would make it a little harder for users to unknowingly use the non-secure mode. 4. One non-security related issue we ran into (on MacOS ad Linux) is that if you save a SSH profile with the Display Number ("port" in the config file) field blank, then restart xpra and load that profile, it properly selects SSH as the mode, but it fills in the Display number field with 14500. I suspect this might trip up some less-savvy users. 5. Is there a way to turn off or disable some of the "extra" features system-wide? For example, we blacklist a lot of external device drivers, including webcams, on our managed linux systems, so rather than have users try to make use of that feature and get frustrated, we'd rather disable it on those systems. Thanks for any help or suggestions you might have. -- Public key #7BBC68D9 at | Shane Williams http://pgp.mit.edu/ | System Admin - UT CompSci =----------------------------------+------------------------------- All syllogisms contain three lines | shanew at shanew.net Therefore this is not a syllogism | www.ischool.utexas.edu/~shanew