Skip to content
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

Keep track if open files are in sync with physical device #332

Open
elmot opened this issue Nov 5, 2024 · 0 comments
Open

Keep track if open files are in sync with physical device #332

elmot opened this issue Nov 5, 2024 · 0 comments
Labels
NOVA New UI and communication approach

Comments

@elmot
Copy link
Contributor

elmot commented Nov 5, 2024

If one opens a file that is on the File system, modify the one on my computer, flash it again while keeping the file on the file system open, right click the file on the File system and click "Refresh" the open file will continue showing what it contained before flashing (tested with a ".md" file.

Honestly I have no idea how to manage this situation properly. For now, a copy of the file from the device is downloaded and open. The relationship to the original file is lost. If the relationship is kept back, there may be a lot of situations when there is "undefined behaviour". For example:

  • a file is open, and then some Python program on the device changes the file, and then the editor and the file are out-of-sync
  • a file is open, original device is disconnected, then another device is connected. The editor is out-of-sync again.

From quickly thinking about it, maybe a different approach could be taken. I understand the drawbacks of keeping a direct relationship, but maybe doing something like this could work:

  • The plugin keeps a note of files that were open from the connected device for as long as they are open - it could keep track of them by name or most ideally by their paths in the device's file system.
  • A purely path and name based option could be taken, if a file is open and another file with the same name and in the same path is successfully flashed onto the device it could trigger the action to update the open file, download it again and switch to displaying it. Then other events such as the "Refresh" action or establishing a new connection might trigger this same update behavior.

This behavior would mean that if a new device is connected and its file directory contains an open file with this relative path, then the open file will switch to showing the file that is on the newly connected device. Whether this is correct behavior or not - I am not sure there is a concrete answer for this.

This would leave three options:

  1. Once you open the file the plugin will make no effort to keep it up to date (this seems to also be the approach of Thonny currently)
  2. The plugin will attempt to search for the open files by their relative path in the connected device's file directory and it will update the open file if it finds it. The update would happen on events such as (right click -> refresh, successfully flashing a file with the same relative path or connecting to a new device)
  3. Point numer 2 but - upon the device disconnecting the open files would be kept open and closed only if a new device is connected and a file with the same relative path isn't found in the new device's file directory.

Perhaps keeping point 1 as the default behavior and giving advanced users an option to switch to behavior somehow similar to point 3?

And for keeping the open file up to date should it be modified outside of the plugin - In my opinion if a MicroPython dev is creating code that modifies files in the File System using your plugin, he will be capable of figuring out he needs to right click the open file and click "Refresh" to see the changes his program made.

This certainly might have its own problems, but perhaps at least giving this behavior to the refresh button, so that we wouldn't need to close and reopen the file could suffice.

And on a side note - stubs are still complaining about me importing the "esp32" library in my code although it is completely valid on runtime - is that a limitation of the used stubs? I believe there are stubs out there, decent ones actually, that are made specifically for ESP32s, maybe it would be worth it to add a separate ESP32 device type in the settings if it meant ESP32 specific stubs could work?

Originally posted by @lukaskremla in #330 (reply in thread)

@elmot elmot added the NOVA New UI and communication approach label Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NOVA New UI and communication approach
Projects
None yet
Development

No branches or pull requests

1 participant