Consider merging with file_selector_windows?

[stuartmorgan]

flutter/plugins has a relatively new file_selector plugin, which currently has an endorsed web version, and unendorsed (since we have no automated testing solution yet) desktop implementations in the FDE repository, which will move to flutter/plugins once we have test harness for them. The current file_selector_windows is a standard C++ Windows plugin (largely the same code as the older file_chooser FDE plugin it replaced), which is presumably mostly the same code as what this package is doing via FFI.

Long term, maintaining both versions doesn't seem ideal, so we should consider merging them. file_selector_windows would need to maintain a bit of traditional plugin code in order to get the HWND, but all of the rest could be Dart+FFI. Some options:

• Discontinue this package, and replace most of file_selector_windows with code from this implementation.
  • Downside: no longer usable in a non-Flutter Dart application
• Move this to flutter/packages, and tweak its API surface as necessary to allow it to be used as the implementation of most of file_selector_windows, so that the plugin just contains an adapter from the file_selector_platform_interface to this package, plus the small amount of glue code to get the HWND via method channel.
  • Downside: somewhat more complexity long term (two packages, two API surfaces)

/cc @cbracken

[timsneath]

Totally up for that. I'd be more than happy to discontinue this package or migrate it. I suspect 99% of the value of this package is within a Flutter app, and I can migrate a version of this into the win32 examples folder for those who want to use it outside of Flutter.

I've upgraded the code to FFI 1.0, at least -- let me know what you'd like to do and I'm happy to transfer the package and/or the repo.

[stuartmorgan]

I'll leave the final call to @cbracken since he'll ultimately be maintaining file_selector_windows. What's easier to maintain may also depend on what the UWP implementation looks like.