[Parti-discuss] [PATCH] client support for M$ Windows!

[Antoine Martin]

Hi,

Nathaniel Smith wrote:
> On Sun, Mar 22, 2009 at 10:09 AM, Antoine Martin <antoine at nagafix.co.uk> wrote:
>> Hi,
>>
>> I've successfully used xpra 0.0.5 (and now 0.0.6 on which these patches
>> are based) on that other OS using the new TCP mode.
>> (it may be possible to use ssh mode with plink - I haven't tried that)
>> You will obviously need to install python, pygtk, etc...
> 
> Dude, awesome.
> 
> I'd be curious whether plink works
It works as a transport for TCP mode, but I can't see any options that 
would allow us to use plain sockets over ssh. (not all that surprising)
Here are the plink options:

plink
PuTTY Link: command-line connection utility
Release 0.53
Usage: plink [options] [user@]host [command]
        ("host" can also be a PuTTY saved session name)
Options:
   -v        show verbose messages
   -load sessname  Load settings from saved session
   -ssh -telnet -rlogin -raw
             force use of a particular protocol (default SSH)
   -P port   connect to specified port
   -l user   connect with specified username
   -m file   read remote command(s) from file
   -batch    disable all interactive prompts
The following options only apply to SSH connections:
   -pw passw login with specified password
   -L listen-port:host:port   Forward local port to remote address
   -R listen-port:host:port   Forward remote port to local address
   -X -x     enable / disable X11 forwarding
   -A -a     enable / disable agent forwarding
   -t -T     enable / disable pty allocation
   -1 -2     force use of particular protocol version
   -C        enable compression
   -i key    private key file for authentication


> -- subprocess interaction is a real
> pain on windows, but maybe the gtk folks made it work already...
Well, it's not exactly stable yet, but just getting simple apps to work 
was a real surprise. I just didn't think it was going to work at all!

There seems to be many unresolved threading issues with pygtk on win32, 
which means we may have to add platform conditional locking in some 
places... I don't know yet, this will need some research.
I have had crashes moving windows off-screen and some apps just don't 
display, crash or fail to refresh...

>> First patch moves some common stuff out of lowlevel (should be pretty
>> uncontroversial)
> 
> Fair enough; lowlevel has been begging to get split up for ages
> anyway. I want to think a little about the best way to do it.
> 
> Some of it wasn't necessary here, though -- it turns out that the
> client wasn't actually using that lowlevel event listener stuff, that
> was just dead leftover code, so I went ahead and killed that.
Cool.

>> The second one is just annoying: "Due to limitations in the winsock
>> API..." , see:
>> http://faq.pygtk.org/index.py?req=all#20.20
>> so this patch re-creates a new listener (for both read and write) when
>> there are pending writes and re-creates the read-only listener when
>> not... it's not pretty, but it works and it only does anything when
>> running on Windows, on Linux the behaviour should be completely unchanged.
> 
> I just committed a change that unconditionally uses only one IO
> watcher,
Even better option. I didn't do that because I thought this might have 
unacceptable overheads for non win32 clients.

> and therefore should be win32 compatible (and also adds a
> watch for IO_HUP as noted in that faq entry)... but I haven't tested
> it on win32 :-). Does it work?
I can't test this at the moment, as I won't have access to a test win32 
platform for a while.

> (In general, I want to avoid having different code paths for different
> platforms when possible; it's just more chances for bugs to creep in,
> and makes testing harder.)

Indeed, I am more used to writing server side Java code. So writing code 
that knows and even cares and branches based on what platform it is 
running on is a new and completely alien concept to me... and it makes 
me cringe!

>> Next, we can't import some of the keyboard related stuff from lowlevel
>> into wimpiggy/keys.py so we load it (and use it) only on non "win*"
>> platforms. We probably need to do something to replace its
>> functionality, but since I don't really understand this part... maybe
>> later. Or maybe when this whole area gets revamped?
> 
> Do modifier keys work for you over xpra+win32 with this patch? (I mean
> things like alt+<something>, control+<something>)
I can't test at the moment...

>> We currently ignore sendClientMessage from lowlevel on windows.
> 
> Why is this necessary? I don't see the client calling sendClientMessage...
Anything that imports lowlevel/__init__.py will trigger and import of 
sendClientMessage.
I didn't check if it was used, I just worked around it.

>> We remove an unused import from client.py and disable the new clipboard
>> (bummer!) as it uses some lowlevel X calls... (will try a better
>> approach for that later)
> 
> I killed the unused import as well.
> 
>> Finally, we obviously can't compile the pyrex/X stuff, so we need to
>> take this out when building on windows (building on windows will need
>> some more work so just build it on Linux and copy over for now)
> 
> You probably can if you install win32 X libraries, but that's perhaps
> a bit much to ask of people.
The vast majority of win32 users would be ok with installing python + 
gtk + xpra, but installing a C compiler and X libs is just too much.

Maybe we could have a switch to compile just the client?

> ----
> 
> Anyway, so I've committed the easy parts. I (we) need to think a bit
> more about how to fit the rest in right -- because sprinkling 'if
> sys.platform.startswith("win")' everywhere is great for
> experimentation, but just not maintainable in the long run :-).
Agreed.

> It'd
> also be good to know how plink works out -- I'm somewhat reluctant to
> release an official win32 port with only insecure tcp support. ("With
> great user laziness comes great developer responsibility.")
It can always be scripted as a wrapper to start plink beforehand and use 
TCP over it: xpra.bat, a bit like /usr/bin/xpra calls the python class?

Cheers
Antoine