File open (hex, py) via UI action and drag and drop #21
Description
Description
Hex and python file support, matching v2 (or discussing if there is good reason not to).
A hex-only open action already exists.
Todo
- v2 supports drag and drop to open a Python or hex file (recognised by file extension), we should add this
- revisit the open action to ensure alignment (see notes below)
- consider file system size errors for module additions
- We just give an error on download at the moment, more work in WP4.
- e2e tests for key scenarios including those covered in v2
Implemented actions
- Open a project (files view, though I don't really the idea it wouldn't be visible by default)
- Download a hex (bottom bar)
- Drag and drop (behaves as per open project)
- Delete file
- Upload file
- Download file
- Create (Python) file
- Missing for now: switching the editor to new files, tracked by Sort out editor focus for new files #45.
Adding file size information to be looked at separately. For the moment you just get errors when downloading the hex.
Questions discussion
0. General feedback.
Multiple file support has been requested by accessory vendors for v2.
1. The open button and drop action has a special case for Python modules as per v2, but I think I'd like to remove it in favour of requiring the user to use the upload action. I think that the post-condition of successfully opening a project should always be having a new project open, not modifying the existing one.
Carlos strongly in favour of maintaining it as a route to open modules. Noted that it wasn't called "Open" in v2 so I've switched to "Load files" here and kept the v2 behaviour.
2. What should opening a Python file do? On v2 it leaves uploaded modules alone. I think if you've used the open action or DnD then it should replace the project entirely.
Kept v2 behaviour.
3. When do we want to confirm user actions?
- In v2, overwriting a file shows a confirmation prompt. But replacing the whole project via open or drag and drop does not. This feels inconsistent to me.
Added confirmation. For now we do it always, even if files are unmodified.
4. Given that we have support for multiple files, how do we feel about labelling main.py with the project name? Applies to the file view, and download / upload project name setting.
Dropped this for now on the basis that the existence of main.py is a bit more obvious with the Files view. Previously it hadn't been clear what "main.py" was. Might change this based on feedback.
5. Should there be a way to download your project as a whole (e.g. ZIP, or our own JSON format) that doesn't include two copies of MicroPython? We'll need some kind of package format for classroom, though it could be specific to the iframe integration.
Strong push back against this idea:
- Other file formats would cause confusion
- Might be blocked / have different difficulties working in school environments
6. Should we have an action to create a new file? A new module?
- Leaving current action for feedback.
7. Should modules be editable? What's the point in module metadata if they're just "other files" ?
- Module metadata lets us map at most one Python file without the metadata to main.py and load modules alongside it. That's its only current role.
- Leave as-is for not for feedback, but I think we should revisit before MVP. Perhaps the should be "soft read-only" so some additional action was required before you could change them.
Conclusion
Based on the feedback we made the following changes:
- Stop naming main.py as per the project. We might reinstate this depending on user feedback.
- Support loading/uploading/dropping multiple files.
- Add confirmation for all file replacements. For the moment we always do this, we could perhaps skip if files aren’t modified.
- Reorder Files area actions to match other apps (we didn’t discuss this, but I think it’s better)
- Renamed button to “Load files” as it’s only the hex case now where it actually loads a project.
So other than the main.py naming, I think it’s now as per v2 but with multiple file support and confirmation for destructive actions.
I’ve not stressed over the text in confirmation dialogs etc. as I think we can review that all at once at some point for tone/consistency.