search

symless / synergy-core

Open source core of Synergy, the cross-platform keyboard and mouse sharing tool (Windows, macOS, Linux)
https://symless.com/synergy
Other
10.13k stars 3.6k forks source link

Drag and drop between computers (Windows and Mac) #37

Closed nbolton closed 9 years ago

nbolton commented 9 years ago

Imported issue:

This is an enhancement request.

Just as text copy/paste between the client and server is supported today,
it would be great to have file copy/paste supported.

As a possible implementation, perhaps the server could run an FTP server
and copy/paste would send files via FTP. Although a direct byte stream
might fit better with the current design.

nbolton commented 9 years ago

The key difference I see here is that text copy/paste is likely to be very small, and
transfers almost instantaneously. For that reason, we do this synchronously when the
user pans from screen to screen, since they probably won't notice the slight lag anyway.

For a file copy/paste, it can be much harder. I can imagine a few possible solutions
to this, none of which are particularly attractive:

  1. The file being copied would have to be immediately redistributed to all of the
    attached boxen, which would burn a considerable amount of bandwidth. And we'd have to
    decide to transfer synchronously or asynchronously. The latter would be annoying for
    larger files; the former would require some indication for when the file has arrived,
    handler logic for when it hasn't yet, dealing with odd edge cases where the user
    provokes two file copies from different machines, etc.
  2. Do like 1, but in a just-in-time fashion to each box as we pan. We still have to
    elect between synchronous and asynchronous transfer, and the nits that go along with
    each.

The FTP solution would buy us a tangible file on the destination machine, but that is
about it. We would still need a representation of the file in the
clipboard/pasteboard/etc, so that pasting the file doesn't have odd edge cases. And
we'd need to have the FTP server either allow anonymous uploads (security problem,
especially with a client that might act on them implicitly on behalf of the user), or
we would need to deal with having credentials setup.

Maybe there are other possibilities, but being that there is a computer network
between each machine, becomes incredibly hard to "fake" that they are all really the
same machine with the same clipboard, window manager, etc, when dealing with
increasingly large sets of data. The abstraction works with mice and keyboards
because the data they send is relatively minimal.

We could restrict this to relatively small files, but where would we draw the line of
what is "too big", and how would we notify the user of such and not be obnoxious at
the same time.

I dunno, this seems like a much larger collection of worms than the size of the can
suggest.

nbolton commented 9 years ago

Hmmm. I didn't realize that clipboard text is synchronized when you cross machine
boundaries. It make sense now that I think about it. I'll have to test that out with
a really large text copy and see if I can see the lag. Guess I should have packet
sniffed this.

I'm not clear how copy/paste operations for files are stored on each OS. For example,
when I ctrl-c on a file in windows, does windows place the entire file contents on
the clipboard, or does it just place a URI? Same question for Linux or Mac. I'm
guessing it's a URI, but I could be wrong.

If it's a URI, then when crossing screen boundaries, the URI could be synced instead
of the entire file contents. I'm sure that's a whole other set of problems though.
The URI would have to be translated to match the OS, and a URI pointing off machine
would imply some sort of protocol-based network file transfer.

You're right, this is definitely a can of worms.

nbolton commented 9 years ago

just drop files in a public share and grab them on the other machine. I know it's a
pain and file drag/drop/copy/paste would be amazing... but it's a LOT to implement
and I'd much rather see that effort going into making synergy more elegant and stable
rather than bells and whistles

nbolton commented 9 years ago

Take the Machine/User for each client and passit to the server. When Drag&Drop a file
between screens, just copy the file to Machine/User/Desktop via SMB. Then redirect
for each OS the Desktop paramaters.

nbolton commented 9 years ago

This is a good feature request, thanks Doug.Gaff. I agree with azanar though; this
may be a can of worms. I almost suggested that this may be outside of our scope, but,
most popular virtualization applications do it, so why shouldn't we? Personally I'd
love to drag and drop files between my computers.

However, I have experience with transmitting simple binary data (i.e. a file) over
TCP, and I can say that this approach would actually be more simple than using FTP or
SMB. To use either protocol would be a bit like using a professional drawing package
to draw a smiley face; sure it's designed for drawing things (much like those
protocols are designed for transferring data), but, there's no point in using a
sledgehammer to crack a walnut. The potential issues we could run into with finding
the right application, ensuring its supported on all the platforms we support,
ensuring configurations don't conflict, etc, would outweigh the benefits.

In short, if we were to do this, we should create a simple binary data transfer
mechanism; I've done it before using C++, and, its [relatively] easy.

nbolton commented 9 years ago

Thanks for considering it. I agree that a simple binary transfer is probably the
simplest.

nbolton commented 9 years ago

nick.bolton.uk I agree with your comment. Simple binary data transfer mechanism sound
good and easy, and clean source code.

nbolton commented 9 years ago

mcordoba, azanar: I just read my comment and I realize that sounds a little terse;
using an existing protocol does have it's own merits. But, my point was, that since I
am fortunate enough to have experience with TCP sockets, we may as well make use of it.

douglasgaff: Thanks, I have decided to bump this up to milestone 2, since I have a
personal interest in it.

nbolton commented 9 years ago

Thanks nick!!!

nbolton commented 9 years ago

I think it would be more feasible to integrate this function into context menus on
each client's shell rather than a drag & drop style interface.
For example, right click on a file in windows explorer or mac finder or linux
whatever, and there is a "Synergy" main menu that branches off into submenus that
say "Send to [hostname]" with a menu entry for each client.
In each synergy client, in the configuration file, we could have a variable for a
default path for received files. I think this method would be alot easier to
implement, and a LOT easier than using samba\ftp to transfer files.

nbolton commented 9 years ago

I have a simpler suggestion for implementing this. Given that most OSes implement
file dragging and dropping differently, and setting up FTP servers running inside
Synergy would be a security nightmare, we could interface directly with each
platform's drag and drop mechanism and pass remote references (shortcuts) around
instead, just like they do themselves for local drag and drop between network shares.

Looking at Windows for the moment, when you drag and drop a file you're actually just
dragging a kind of shortcut to the file, which when dropped in say a folder, tells
Windows to copy the file there. If you drop it in an application instead, it opens
the file in-place (even if you dragged a file from a network share.) This means that
if you had an internal FTP server or the like, you'd have to FTP the file over to the
destination PC and monitor it, so that every time it was saved you'd FTP it back over
the top of the original! Very messy.

However if, on the Windows machine, you open \other\c$\path\to\file\ and drag the
file from there, Windows apps will open the remote file in place (without copying it
to the local machine) and Explorer will copy it or whatever as you'd expect.

So the solution to me seems to be to fake a drag event, so that when you drag
C:\FILE.TXT from PC1 to PC2, PC2 sees it not as if you're dragging C:\FILE.TXT, but
rather you're dragging \PC1\C$\FILE.TXT

Then whatever app you drop it into will open it directly off the remote PC without
making unnecessary copies of the file (unless you drop it onto Explorer, which will
happily copy the file for you as intended.)

This will of course mean that it will only work best under Windows, but if you run
Samba under Linux you could configure your "remote root" path in Synergy's config
file to be \LinuxPC\rootshare, and then because Synergy has a Windows-compatible
network path to any file on the system, dragging and dropping files will just use
Samba. It could be possible to implement with other filesystems (e.g. NFS), but I
think most people would be happy, initially, with having to run Samba on any
non-Windows platform they want to involve with dragging files.

It would certainly make this much easier to implement, if all you have to do is catch
the drag event when it crosses screens and just alter the filename!

nbolton commented 9 years ago

malvineous, thanks for taking the time to write.

I believe you have a good point when you say that the different operating systems
have different ways of dragging and dropping, this is certainly something we must
bare in mind.

However, I have to stress my personal opinion on the method of transferring files.
Using an existing 3rd party application would not catch on, as setting up those
services requires a certain amount of technical ability on the users behalf (in terms
of trouble shooting, configuraiton, etc). We also can't assume Synergy+ will
configure these applications automatically, as this may conflict with existing user
configurations.

The best way is to have Synergy+ send the file to another Synergy+ instance it's
self. Again, I have to say that setting up a custom TCP stream is extremely easy, and
is our most practical option for this. There are plenty of libraries out there
designed exactly for this sort of thing.

nbolton commented 9 years ago

Agreed 100%% w/ nick.
As for security concerns, the easiest way to handle that is to now allow any
hostnames except the ones in the synergy cluster to use the file transfer
service...even with that as a baseline there are still other security issues, and I
am not saying to use something rediculous like 256bit AES encryption, but
nevertheless security can be handled appropriately.

nbolton commented 9 years ago

I agree that using Synergy itself to transfer the files would make it easier "out of
the box" to start dragging and dropping, but I still think it could pose just as many
issues. What happens if you drag a one gigabyte file from one PC to another? How
long will that take before the mouse cursor switches screens? What happens if you're
dragging a 100MB log file (which would take about 10 seconds to switch screens on a
100Mbps network), but you accidentally move to the wrong screen first - is it going
to take 10 seconds to switch to the wrong screen, 10 seconds to switch back, then 10
seconds to switch to the correct screen?

I realise that transferring files over TCP/IP is quite easy, but I think it would be
a good idea to think through exactly how it's going to work before deciding to
implement it just because it's simple. Remember that active FTP also uses a second
TCP connection to transfer the file (in exactly the same way as proposed, raw data
over a TCP port) but that protocol causes a lot of issues with NAT and firewalls.
Anyone running a firewall on their machines will need to open at least one port for
Synergy file transfers, and hopefully nobody will ever want to use Synergy on two PCs
that are connected via NAT...!

While I admit it's been a while since I did any Windows programming, I do recall that
you had to set up your file before starting the drag operation - so if you have to
transfer the file, you can't wait until the user has dropped it, you'll need to
transfer it over the network whenever the cursor switches screens (unless newer
versions of Windows have changed this behaviour.) So there could be large delays
dragging files between PCs.

At any rate, I'm sure it's clear what my preferred option is :-) Perhaps there's
room for both methods? TCP transfers for out-of-the-box dragging and dropping for
small files, and an extra config option for those wanting full drag and drop via
Samba? I'm certainly interested in how you'd go about implementing the Samba-based
drag and drop, so if you're open to accepting patches...

nbolton commented 9 years ago

Actually now that I think about it, dragging and dropping is (IIRC) very closely
related to the clipboard. A simplification would be that dragging some data (which
could be a file, but not necessarily, it might be a hyperlink from a web page for
example) between two programs sort of acts like a copy and paste between the two
programs, using clipboard structures and datatypes but without affecting the actual
clipboard contents.

We could use this to our advantage by taking the existing clipboard-sharing code in
Synergy and expanding it for use with drag and drop. This would mean that dragging
something between PCs would share the same code as copying and pasting that data
between the PCs, but again without affecting the contents of the clipboard.

This would mean dragging text between word processors on different PCs would work
straight away (since you can already copy and paste that data between PCs), and
dragging files would work exactly the same as copying and pasting a file - which
doesn't work at the moment, but once implemented (via TCP or Samba as discussed
above), then you'd be able to copy and paste files as well as dragging and dropping them.

This would have two big advantages - you could drag and drop anything supported by
an application (not just files), and the code that handles that would only exist
once, for both clipboard and drag/drop.

(granted this doesn't solve the main issue, but hopefully it provides some helpful
ideas as to how the solution could be implemented!)

nbolton commented 9 years ago

All,

Please could we keep lengthy discussion to the mailing list. Issue trackers are not a
good place to have lengthy debates.

"http://groups.google.com/group/synergy-plus/browse_thread/thread/01bc017158c18b55":http://groups.google.com/group/synergy-plus/browse_thread/thread/01bc017158c18b55

Thanks,
Nick

nbolton commented 9 years ago

As in other issues I think the direct transfer will be the elegant way working anywhere.
Why not serving a quick (and dirty) solution like another KM does?
With a global network share both computer have access to.
Dragging the file off the screen copies the file to the share and on the other screen
a dragging operation with the just copied file is started...
The share can be secured so noone else can acces your data only your two comps and so
on...

nbolton commented 9 years ago

Hmm, it depends how popular the issue gets. If people absolutely must have it, we may
end up implementing a hacky solution for the short term. Eventually though, I'd like to
not have to rely on global shares.

nbolton commented 9 years ago

For users looking for a simple solution while this is being considered. What I did
was create a shortcut on PC1's desktop to PC2's desktop and vice-versa. Now on PC1 I
can just drag a file onto the shortcut and it will be copied to PC2's desktop.

nbolton commented 9 years ago

Have you tried a combination of synergy with somthing like <a
href="http://www.softpedia.com/downloadTag/share+clipboard">shared clipboard tools
already implemented for example <a
href=""http://code.google.com/p/net-clipboard/">http://code.google.com/p/net-clipboard/": Network clipboard who has a Java
implementation?

nbolton commented 9 years ago

I'm proving synergy + Simidude ("http://www.agynamix.de/products/simidude/":http://www.agynamix.de/products/simidude/ ) with
Windows and Mac os X and its run very well.

Maybe can be better if support drag & drop, but multi-copy-paste between computers is
a good solution.

nbolton commented 9 years ago

Have you guys looked at giver ("http://code.google.com/p/giver/":http://code.google.com/p/giver/ )

nbolton commented 9 years ago

Hi Nick,

I've taken a quick look into this topic before and this is something that may be of
use to you.

Rather than copying the whole file across when you switch screens, which is
undesireable for large files, you could do the following:
a) User copies file into clipboard
b) User switches screens
c) Synergy detects that files are copied into the clipboard and changes it to a
custom clipboard type (that only Synergy can handle)
d) When the user tries to paste it, Synergy can perform its copying action across via
the client somehow (method of choice is yours here) to the specified location

Some references that are of great use for codebase or understanding:

nbolton commented 9 years ago

Please remember that the beauty of Synergy is that it is cross-platform, so please DO
NOT USE PROPRIETARY TECHNOLOGY like OLE/COM, .NET or other crap like that. :-(
If ppl want a more complete implementation that runs ONLY on M$ systems, look at
Input Director ("http://www.inputdirector.com/":http://www.inputdirector.com/ ).

nbolton commented 9 years ago

Yeah, I took a look around but I dont know enough about Linux/MacOS to suggest any
coding possibilities there.

ps. Input Director seems to be Windows only (although somehow its still usable
through that UAC popup!)

nbolton commented 9 years ago

Me too. Just kidding. A cheap and dirty solution for files is to use dropbox or sugarsync on each box, dropbox with local lan detect is especially nice. Takes away from the beauty of the app i agree... A serious issue with file copy paste as well as moving windows from one screen to anothe (which wuld be some kind of crazy xserver type thing on box) is the danger of mistaking where you are copying and pasting this that or or the other file... I could tell you nightmare stories involving lab production servers and terminal windows back in the day....

nbolton commented 9 years ago

Just a thought. Back in the old day, we use uuencode/uudecode to transfer binary files.
Can we simply uuencode the binary file (i.e. JPEG) and put it in clipboard and uudecode on the other end of client?

Let me know what you think?

nbolton commented 9 years ago

the main issue is large files.

nbolton commented 9 years ago

First, let me say this is a great feature request and the notion has crossed my mind over the years of using this program.

Adding this functionality is not cut and dry, but the file sizes should not be too concerning. Worst case, you can put in a textbox that defines the maximum file size.

Actually, I think the best approach may be to have two categories of copy paste operations, consider:

First, files that are small enough to be copied directly to clipboard of the client(s). Second we have "large" (by some user defined size) files that require user accepting the transfer via the byte stream of synergy. This second category should be controlled by the synergy client displaying a dialog before transferring a large file warning them of the time it will take to make the transfer.

I guess the other method (to be used in conjunction with the byte stream method) might be global hooks on the menu items to add a "synergy copy" option, at least for windows.

Just my 2 cents, hope it helps.

nbolton commented 9 years ago

I have written a python script that makes transferring files between computers very easy. It uses pyftpdlib to set up a FTP server, and a client script transfers the files. It contains a configuration file in which the target folder, users (name, password, optional subdir), and limits are defined. Integrating it with synergy should not be too complex: I was able to make it transfer a file whenever I would switch screen. Where it gets tricky is getting to know what is being dragged during the screen switch.

Here is a challenge to all of you, developers out there. Provide us with working source code (cross-platform or not) of a program able to detect what is currently being dragged. If it turns out on some systems it is impossible to obtain this data unless the item is dropped, then we will simply have to build a box where we can drop the file to transfer it.

Now, if that box is really needed, it would be best if it could be a tray icon that lets us choose to which screen to send it. Kinda like drag and drop to the icon, then click a button to say where to send it.

Technically, using my script you could drag and drop to a script predefined to transfer to a certain machine. It works like a charm, but it would be much nicer if it would integrate with synergy.

nbolton commented 9 years ago

The way I personally see this working best is to use SMB/CIFS as it is already supported in Windows, OS X and many graphical file tools on Linux. Essentially what I believe should happen upon a file copy operation is for the local computer to retain the usual file operation in its clipboard while all remote machines have a file operation placed in theirs which is transformed to appear to be on a samba server running locally on each remote machine.

This approach means that no data is transferred until the point that the file paste operation occurs, and at this point synergy simply shovels it across, and the OS itself does what it usually does for the transfer of a remote file.

The advantage to having the samba server appear local is the actual transport mechanism can use any protocol the developers desire, across a single connection between machines, carrying the file data through whatever encryption scheme they plan to implement in 2.0, while the OS just sees a plain old samba service.

A similar approach could be done for drag and drop by having synergy generate a drag/drop event that looks to the OS like a file from a samba server just got dragged, thus it should again do the right thing itself with respect to dialogues, and synergy can concentrate on shovelling the data across when asked for it. If you have applications that know how to react to pasting or dropping a file copy operation, then provided they support files on a samba source, they would react as expected. To see an example of this in action, drag an image file on a samba server from the Gnome file browser to the Gimp; The Gimp doesn't support pasting a file, but this applies equally to local ones as well.

nbolton commented 9 years ago

This implies that the machines establish a Samba connection beforehand for the transfer to occur. The clipboard copy/drag and drop event simply contains the path to the file, not the contents which needs to be transferred. Thus the copy operation would indeed put the path of the file in the clipboard, but when pasting, the application could be unable to locate the file, or might even copy the wrong file. The paste operation therefore needs to be intercepted, which means we need to intercept not only the keyboard shortcut, but also any API call to the clipboard, and we can't be sure of how applications will handle it, as they simply read the data then do their own operations.

However, I like the idea of having a link between the two machines, which could be either until the end of the file transfers (end of queue plus a few seconds) or for the whole Synergy session, to allow for easy file transfer. Synergy could have an interface to facilitate this, just think of how TeamViewer does it. This could be handled in band, which would increase the complexity of the Synergy protocol, or out of band by using external tools, such as a small FTP server, like the Python script I made. To catch the copy/paste event, there could be a hotkey/combination registered with Synergy that would make sure the path to the file is in the clipboard, but there is still the problem of where to create the file. There could be a folder dedicated to receiving files, but trying to obtain the path of the application in the foreground is not reliable. One could very well get the proper folder in say Windows Explorer, but someone using a different program (replacement) would be unable to use this feature.

nbolton commented 9 years ago

I really don't think it needs to be that "complicated" (relative). Pre-syncing file(s) would be disastrous. Big files, more than one file, etc... Trying to intercept a paste action is also trouble because each OS does this differently, and each application may have its own way of hooking into the clipboard.

All that needs to be done is a simple virtual file system to provide a fully qualified path. This can be done with Fuse/MacFuse/WinFuse, or at the very least borrow from these projects. Synergy itself would power that file system and copy the files on demand. The OS clipboard for files, at least for network shares, should contain a path anyway. I really think that would be the most efficient way to handle things.

nbolton commented 9 years ago

An alternate to WinFuse, which from what I understand uses FIPS, is Dokan, which uses a kernel driver.

nbolton commented 9 years ago

The idea of including a torrent system in synergy has been lingering in the back of my head for years now. Might be overkill for small files and/or low-powered systems, but big file transfers might work out well, right? That way one computer could be the original source and as another computer gets more pieces of the original file(s), the load would be distributed a bit better. The only nodes allowed to participate in the transfer would have to be connected with synergy, and the transfer would have to be encrypted.

Downloads wouldn't have to happen automagically, but only as requested (some magic keybinding?). Some nice "Copying files" interface would be nice for this, but that might be better left up to platform-specific tools.

Just a thought.

nbolton commented 9 years ago

Maybe I should take this feature more seriously. This seems to be the most popular feature of the new kid on the block ("Mouse without Borders" by Microsoft), and it's relatively simple to implement, and popular.

I'm assigning this to the 1.4 track.

nbolton commented 9 years ago

Oh wow, I'm disappointed they stole the whole "Synergy" idea without even referring to it at all.

nbolton commented 9 years ago

Nick Bolton wrote:

Maybe I should take this feature more seriously. This seems to be the most popular feature of the new kid on the block ("Mouse without Borders" by Microsoft), and it's relatively simple to implement, and popular.

I'm assigning this to the 1.4 track.

Hi, I am beginning work on a fix for this feature as my final year project at university. I have a few ideas of what I'd do but if anyone has any ideas that they think are serious, effective and efficient ways to do it then please do contact me. Remember that it has to be fast, cross-platform and secure.

Nick, you said "...and it's relatively simple to implement..." above, I would like to hear your ideas on how you think it would be best implemented, after all I'm sure you know the source code and general concepts the best out of anyone and I'd love to make a really good contribution that will be accepted and help out all the users, not least myself.

nbolton commented 9 years ago

Any update on this?

nbolton commented 9 years ago

Sorry for the re-post, I put this in the wrong ticket. It's been a while since I've taken a look at the tracker and lost track of this thread when it moved over from Google Code.

Today I received an email from StarDock and one of their new products is Multiplicity: http://www.stardock.com/products/multiplicity/download.asp

Although it's Windows only, it's got file transfer capabilities built in.

nbolton commented 9 years ago

Teleport on the Mac supports this, and it's a great feature: http://www.abyssoft.com/software/teleport/

nbolton commented 9 years ago

Whatever method you choose to support, consider using scp as well. For machines with an ssh server installed (all new Mac and nearly all Linux machines, fewer Windows machines, but easy in any case) it would automatically mean secure file transport. My text editor (SlickEdit) allows me to remotely edit files via either ftp or ssh; this might be a good model for Synergy as well. And by the way, thanks a lot for a terrific product; I use it daily, don't know how I could do without it.

nbolton commented 9 years ago

Hi Andrew,

I have started implementation of DnD (Drag and Drop) by dragging text between XWindows based systems (Arch and Ubuntu Linux to be precise).

What I did so far:

For now I am trying to hide the mouse cursor on the server side: I failed to hide or change mouse cursor when mouse pointer is actively grabbed by some other client. Neither XDefineCursor can change the cursor nor XChangeActivePointerGrab (since my application is not the client that has grabbed the pointer). Do you have any idea how it can be done?

Next step would be sending actual data via a couple of events; like what is done during copy/paste.

nbolton commented 9 years ago

A plug-in model for UI actions might be a good first/intermediate step. Define a plug-in model for UI actions such as clipboard cut/paste and drag/drop. Upon an action the client and server plugins could be notified with parameters that included each other's hostname (or IP address) and then the plugins could do whatever they wanted - talk to each other, one would do an scp to the other machine, they could fork bittorrent clients, whatever. It would provide flexibility for people to experiment with multiple approaches.

Then, of course, YOU could provide a plug in for drag/drop according to whatever model pleased you best!

nbolton commented 9 years ago

Hey, I have been using Synergy heavily recently and I think it would benefit tremendously from having the ability to do this.

nbolton commented 9 years ago

voting...

nbolton commented 9 years ago

This usb connection has drag and drop between mac and windows: http://www.j5create.com/our-products/wormhole-switches/juc100.html

nbolton commented 9 years ago

I think this could be accomplished using the TCP sockets transfer Nick Bolton was describing. Upon click-drag of a file, the client would notify the server (and thus all other clients) of the size of the file to be copied. Each client could then reserve that much disk space on their disk's temporary storage area as a zeroed file, so that when the cursor is dragged into the next screen, the OS can use that file handle to perform the drag-drop request. Synergy could then intercept the mouse released destination and copy the file over the network, before moving it from Temp Files or /tmp to the final location. This way there is nothing copied to a clipboard and so moving mouse between screens is lag free, with file copying performed in the background without dependence on another software service. This approach requires perhaps a little more developer work in the form of hooking into each platform's file explorer/drag-drop architecture at a lower level to intercept and create dummy events, in the Finder, Windows Explorer, and the Open Desktop.

nbolton commented 9 years ago

Why does it have to integrate with each OS' file manager?

The user experience could be as easy as 'drag file to side of the screen that is configured for that device'. Have a small bit of UI pop up (a vortex or something similarly spiffy) and drop the file on the initiating machine. Transfer via TCP socket to the recipient machine, have it 'pop' out of a vortex onto the desktop when it arrives, and the user can drag it from there.

It seems like a lot of effort to try and make this process "seamless", so I say acknowledge the constraints and make a great experience within them.

nbolton commented 9 years ago

I don't know how much help this would be but there is an open source file sharing program called nitroshare that you could possibly incorporate into synergy.

https://launchpad.net/nitroshare

It works on windows and linux systems, not quite sure if it supports mac.
One of the nicer things about this software is that it automatically finds other computers with nitroshare on it. Then it configures itself to share files across them.

It has a little bubble that you can drag files onto, and it will send it to a computer that you specify. On the receiving computer a popup asks you if you want the file. and if so, automatically downloads it for you.