Hi,
Nathaniel Smith wrote:
On Sun, Mar 22, 2009 at 10:09 AM, Antoine Martin <[email protected]> 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] [u...@]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
_______________________________________________
Parti-discuss mailing list
[email protected]
http://lists.partiwm.org/cgi-bin/mailman/listinfo/parti-discuss
