add file_list to Set interface

[Gae24]

We should decide what type of input we accept.
On windows clipboard_win::raw::set_file_list is used which has as parameter &[impl AsRef<str>] and doesn't check if the input is actually a path; on linux and osx the parameter is of type &[impl AsRef<Path>] and canonicalize() is called so non existing paths get discarded

[complexspaces]

It seems like the best generic interface we could expose is impl Iterator<Item = impl AsRef<Path>>] because its the most typesafe, but that would require a re-collection (.collect<Vec<_>>) on Windows because of the interface clipboard-win gives us (despite internally just looping over the slice). I think its advantages are:

• Allows callers with well-typed libraries/crates using Path/PathBuf no friction/extra unwraps.
• Allows callers with borrowed data in their collections (&str) no friction.
• Allows callers with owned data in their collections (String) no friction.
• Allows arboard on non-Windows platforms to skip a collection allocation.

I was experimenting with the above in this playground link, for reference. Do you think its worth just dealing with the current limitation on Windows and seeing if it can be removed via either a PR to clipboard-win or re-implementing similar in arboard so that we can have a flexible interface for the future?

[Gae24]

It depends on which behavior we want. On Linux and MacOs the argument is &[impl AsRef<Path>] due to the use of canonicalize() since I thought we shouldn't write invalid paths.
If we want align Windows to the same behaviour, I say let's implement our own version.

[complexspaces]

That sounds reasonable to me; the Win32 code for this isn't super bad. We already have some primitives for clipboard memory allocation due to image support. I pretty heavily value cross-platform consistency in arboard where feasible.

One thought came to me over the weekend I'd like to ask about regarding invalid paths: Can you think of any use cases or needs for "dropping" a list of files on the clipboard that aren't proper file URIs, such as app-specific URIs (onepassword://, for example). It might be out of scope for this addition too, which is fine.

[Gae24]

Certainly, we can expand support for more uri types later on.

[Gae24]

Had to modify a bit Cargo.toml and move out of image_data a couple of functions.

For some reason, clipboard_win doesn't place the data in a STGMEDIUM, should we do it?

[complexspaces]

It doesn't look like Chromium does, so I don't think we need to. They create a STDMEDIUM structure here but then when actually writing the data only the hGlobal part is actually used.

[Gae24]

on Windows canonicalize will convert to a UNC path, do we want this behavior?

[complexspaces]

Sorry, missed your comment. I learn towards not wanting to introduce UNC paths because since we're very reliant on other applications reading the pasteboard to know how to handle them correctly.