-
Notifications
You must be signed in to change notification settings - Fork 341
P2: Add file picker to DevTools #2149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
In terms of Desktop support - even if we were able to just do Mac, that would be helpful for us. |
@kenzieschmoll there's currently no support for desktop at all in the plugin (and I've never done any Mac development! :P) As a backup, have you considered using https://pub.dev/packages/file_picker ? That one seems to support more platforms, and the only thing that you need to consider when dealing on native vs web is that native returns File objects from (I'm saying this because I don't know if I'll be able to merge my changes to the plugin fast enough for your project!) |
Maybe @stuartmorgan can add desktop support to the current image_picker with https://github.com/google/flutter-desktop-embedding/tree/master/plugins/file_chooser? OR MAYBE we can add web to the file_chooser plugin? |
It doesn't support any of the Fluter desktop embeddings, so would only help you for web.
I'm confused. The bug is talking about opening json and zip files; what does that have to do with image_picker? (Image picker functionality could be approximated on macOS using file_chooser, but there are better ways to pick images. file_chooser is poorly suited to implementing image_picker as is, and it would be much better to add an actual macOS implementation to image_picker.)
The goal is to eliminate FDE; I am strongly opposed to expanding its scope to web. I think the first step here is to back up and have a Flutter-level discussion about how file picking should work:
If the answer to both is no, then the question for this issue becomes: which existing 3P plugin should be used for dev tools, and what's involved. (E.g., if you want to use file_picker, should we contribute desktop implementations assuming they would be accepted, or host federated implementations somewhere if not?) Once we have answers to those two questions, we can figure out what should happen to the desktop functionality that's currently in FDE's file_chooser prototype. |
@stuartmorgan who do we need to loop in to answer 1) and 2)? |
Probably @Hixie as a starting point. |
I'd probably start with a plugin. It sounds similar to things like links on web, where we're starting with a plugin also. On the long term we'll probably fold some of these in but in the meantime having them in a plugin forces us to think about layering it correctly. |
@stuartmorgan The issue is that DevTools needs picking files both in Web and Desktop, and there's no picker plugin (1p nor 3p) that covers that need. |
I think the next step is to put together a quick proposal doc for a new 1P plugin and send it around for sign-off (from eco-system leads, web and desktop folks, probably API review for feedback on the Dart side, etc.) @ditman Do you want to drive that? I don't know when I would be able to get to it, and I also don't know anything about the web vs. desktop file API considerations so would be a poor choice to design an API proposal. ( Once there's a plugin framework in place I can move functionality from |
@stuartmorgan yes, let's write a quick doc with a couple of options about this. I still think that the image_picker is the best starting point (other than the now-outdated name containing |
(/cc @tugorez this is the tracking issue for the file picker in the DevTools app) |
P1 target is the web - but we would like the picker to work for desktop too since that is where we develop.
This picker is needed for the Code Size page under development. The picker will also be used to load snapshots into DevTools for the pages that currently support it (timeline, performance).
The current need is to pick .json files, but we may need to support more file types in the future (likely .zip).
The text was updated successfully, but these errors were encountered: