This change adds a multi-tabbed file interface

[RobertBlackhart]

resolves #28

I also added the rollup-plugin-sourcemaps2 plugin for debug builds so that debugging/setting breakpoints is easier. Additionally, I made some minor changes so that the build would not spit out any warnings (like unused variables or empty blocks)

• [x] Allow opening multiple files
• [x] Highlight open files in File Manager
• [x] Reuse File Manager: Switch between file editors using by selecting files
• [x] Indicate unsaved files inf File Manager
• [x] If an open file is deleted, the editor should switch to any open file
• [x] Saving should be disabled for readonly and virtual files
• [x] Bonus: do not reload main file (any files) from device if it has unsaved changes

Brand new window:

After connecting to device:

After opening file from device:

Making edits to file:

Opening another file:

Closing the first file without saving:

After saving the first file:

[RobertBlackhart]

Added an indicator (italic text) in the file tree when a file is open (not present in above images due to it being added later):

[vshymanskyy]

Thanks for this contribution! Initially, I though completely skipping the "tabs on top" part, and just use the left panel for all the navigation. This will play nicely with the Mobile layout. WDYT?

[RobertBlackhart]

I had looked at what it would look like on a smaller screen and thought, it was acceptable, although it does take some space away from the editor box.

The only thing that comes to mind about not showing the "tabs on top" part for mobile is that closing a file is a bit more difficult. The "x" in the file tree currently is for deleting a file, so there would need to be some representation for close that's separate somehow.

Closing only really matters in two cases:

1. If some other process on the µC is going to update a file outside of the editor's knowledge
2. To save memory on the device running Viper-IDE

I'm not sure how much memory would be saved for 2, so the bigger use case would be 1. This is currently addressed by closing the file and reopening it as the only option (both before and after the tabs). Perhaps a little refresh button after the file is opened? That is, on mobile, you wouldn't ever close the file, but you could refresh its contents if something else changed it.

[vshymanskyy]

I have briefly reviewed the PR, and in general it looks ok. I'll pull it and run it locally for some time, just to make sure all is OK and maybe provide more feedback. @RobertBlackhart awesome job

[ma261065]

Thanks for this contribution! Initially, I though completely skipping the "tabs on top" part, and just use the left panel for all the navigation. This will play nicely with the Mobile layout. WDYT?

My vote would be to keep the tabs-on-top style of editing. It's a well understood UX that people will be used to, and completely separates the action of closing an editor (which should have no consequence except maybe asking for save) to doing something with the file (e.g. delete, rename) which happens in the left-hand pane.

I would also vote to change the "X" to delete a file into a rubbish bin icon, as X often just means "Close", not "Delete", and if we now go to a multi-tab editor with "X" meaning close the editor window there is scope for confusion.

[vshymanskyy]

The actions in the file manager can be (read: will be) moved into a separate dialog, so "x" in will no longer appear along the filenames

[vshymanskyy]

My main issue with the tabs on top, is the waste of space and complexities when many files are open.

[ma261065]

My main issue with the tabs on top, is the waste of space and complexities when many files are open.

The waste of space would only be for mobile - right? Would it be possible to have an adaptive UI that shows tabs-on-top when running in a full browser, but somehow simplifies it for mobile? (I know, that is probably a hell of a lot of extra work :-) )

In a full browser window I don't see that the editor tabs would be a waste of space. VSCode and many other code editors use this paradigm, and it works well. I think you would get pushback if this editor was "different" from some users...

I guess I am an example of that pushback, but if there is another paradigm that you are thinking of maybe share a mockup here for comment?

[vshymanskyy]

ViperIDE is different from other editors and i'm not opposed to it. You can also use VSCode

[RobertBlackhart]

The waste of space would only be for mobile - right? Would it be possible to have an adaptive UI that shows tabs-on-top when running in a full browser, but somehow simplifies it for mobile? (I know, that is probably a hell of a lot of extra work :-) )

It would not be much work to simply hide the top-tabs on mobile. Just 1 CSS rule could do it.

[vshymanskyy]

Yes that's what i'm thinking too. Anyway, the left panel navigation will need to be improved for that to work on Mobile

[RobertBlackhart]

I added the CSS rule to hide the tabs on slim screens. Here's a screen recording of what it looks like to interact with and switch files.

[ma261065]

I think that's the perfect solution. Tabs on a big screen where they work well, and space saving on a small screen.

This editor is amazing - can't wait for this feature to go live.

[vshymanskyy]

I'm not opposed to merge it. I just need a bit more time to actually evaluate it

[vshymanskyy]

Now available on https://viper-ide.org I'll be adding some adjustments later, but i see no point in holding back this amazing PR

[ma261065]

This looks great! The only issue I've noticed so far is that the changed indicator remains in the left panel after closing a file with changes, but selecting not to save. Similarly, if you do save the file, the changed indicator stays in the editor tab, when it should disappear.

I think you're planning to re-do the whole left panel anyway, but maybe this is a quick fix?