From: Bob B. <bb...@us...> - 2003-06-06 12:14:05
|
Erik, Good work! Is this just for the RDP5 work you've been doing, on does this work with RDP4 sessions as well? Bob On Fri, Jun 06, 2003 at 01:49:40PM +0200, Erik Forsberg <for...@ce...> wrote: > DOH! Sent the mail before it was completed by accident! *ARGL!* > > Ah, anyway.. here's the whole mail again: > > Hi! > > To celebrate the Swedish national day (which by odd reasons isn't a > holiday), I've now committed basic clipboard support to CVS :-). Those > of you following the CVS-announce list might have noticed this... > > Mini-FAQ: > > Q: Can I cut from an X application and paste into Windows? > A: Yes, but only text. Also, there might be character conversion > trouble. > > Q: Can I cut from Windows, and paste into an X application? > A: Yes, but only text. Also, there might be character conversion > trouble. > > Q: If I have two rdesktops, can I cut in one of them, and paste into > the other? > A: Yes, and in this case the two rdesktops communicate with > eachother, allowing for other formats than text to be > transferred. However, for really large clipboard transfers, there > might be problems. > > The implementation is somewhat limited. As mentioned above, there are > probably character conversion problems. I'm asking X applications for > the TEXT targets, which means they are free to convert to whatever > character set they find appropriate. This might not always be the same > character set as the one on the Windows server. A safer way would be > to see if the X applications have a UTF8_STRING, and then convert that > into the UCS-2 that you are supposed to send to Windows. There are > also some other format conversion issues still left to solve. > > Also, for large transfers, the problem is that I don't support the > INCR protocol yet, meaning we can only transfer as much data as you > can set on a X property. On my X server, this is about 200Kbyte, but > other X servers might have lower limits on this. If I have time for > it, I will implement this during the coming month. > > A bit side-related is that I've also implemented and committed some > general channel handling code. See channels.c. Please note that the > dummy channels is there for a reason. It seems Microsoft didn't think > of the case where there is only one channel active when they designed > the mapping between the channels in the RDP layer, and the channels in > the MCS layer. This channel handling code should be useful for > implementation of other channels (such as sound, COM port mapping and > other channels). The basic idea is that you register a channel with > name, flags and a callback in channels.c:channels_init, and then the > callback is called each time data arrives on that channel. > > The secure and MCS layer can now send to specific channels, which is > also of use for other channels. > > Another mechanism I had to implement was some simple interprocess > communication between different rdesktops. This was neccesary because > of the differences in how clipboards work in Microsoft Windows and in > the X Window System. Basically, in MS Windows, there is a push model - > all clients get information about availability of clipboard data. X > has the opposite - if the program detects a gesture that indicates the > user wants to paste something, it checks if there is some clipboard > data available. In order to bridge this, and get good functionality > between different Windows applications (something that's important in > our product), I communicate between the different rdesktop instances > using X properties on the root window. See ipc.c and some of the > functions in xwin.c. > > There are bugs/limitations in this as well. The rdesktop with the > application that are about to receive clipboard data must be running > when the cut/copy is done in the sending windows application. Also, > the sending rdesktop must be running when the receiving wants the > data. The latter, however, is a general rule for all X clipboard > operations, unless you have a clipboard server running. > > I'll try to document some of this stuff in a file or something since > it's quite complicated. > > As a related note, there are problems accessing sourceforge right > now. They're having performance problems and especially pserver > connections tend not to work from time to time. > > Have fun! > \EF -- Bob Bell <bb...@us...> |