General todo list for official release

[SquidDev]

General experience

• Document everything
• Readonly mode: the remote viewer cannot interact with the computer at all, only the screen is forwarded.
• Share mode: only the first viewer can interact with the computer. Any later viewers will be in read-only mode.

File transfer

• Compress + base64 encode files Compression extension support added to CC:T instead (cc-tweaked/CC-Tweaked@4c2e97b). We can probably up the packet size and investigate better methods of abuse prevention.
• Provide feedback for files when:
  • File is too large to be transferred
  • File saving was rejected or we got no response
  • The file was modified elsewhere. Also provide option to refresh from disk.
• Add support for force/overwrite-saving.
• Prompt for confirmation when closing a modified file.

Viewer

• Add button for termination. Sadly we can't add keyboard shortcuts for this, so we'll have to find another solution.
• Settings interface, including:
  • Keybinding mode (normal, Emacs, Vim)
  • Alternative styles for a "dark mode".
  • Wrap terminal in a border.
• An actual 404 page

Host

• The buffer does not handle writes which go off the edge of the screen.
• Exit gracefully if an error occurs within the script.
• Add flag for http

[dmarcuse]

• Use something other than make for a build system

[Lupus590]

• add a file viewer
  • can open files for editing
  • file upload button
    • upload zips for deployment on CC computer's FS
  • file download button
    • download CC computer's FS as zip
  • can create new files
  • can delete files
  • github cloner
    • can make commits
      • can push commits (Probably dreaming a bit far at this point, also probably should have said that ages ago)
  • pastebin/url downloads

[dmarcuse]

I feel like aside from uploading/downloading files, a good chunk of those are excessive: You can already download from pastebin, github, URLs, etc using existing CC programs.

[Lupus590]

@apemanzilla better?

[SquidDev]

I've deliberately left off having a whole file tree as it introduces the whole problem of keeping the tree in sync. You'd have to walk the whole tree every x seconds, compute a diff, etc...

I personally think the edit command strikes a nice balance between ease of use and ease of implementation, but I'm not opposed to adding some dowload command.

My current priority is polishing up what's here already (computer interaction, basic file editing) before trying to flesh this out with all the bells and whistles.

[dmarcuse]

@Lupus590 yeah, that's exactly what I was thinking and still fits @SquidDev's motivation.

[hugeblank]

Would it be worth considering having some sort of way to get the items inside a turtles inventory, or would that be overboard? I suppose it could be done manually with a little script, but some way to actually interact with the items outside of the computer screen would be pretty nice.

[SquidDev]

Would it be worth considering having some sort of way to get the items inside a turtles inventory, or would that be overboard?

It's probably a little overboard, or at least for the first iteration. It would be an interesting feature and, as we have turtle_inventory events, could be implemented rather efficiently. However, it's not something I currently have a use for - I have Minecraft open at the same time as using CC, so it's not any easier to do it in-browser.

---

I'm definitely going back on some of the things I said a couple of weeks ago. Having got a lot of use out of this the last couple of days, I can definitely see the use of fleshing this out into a more full dev-environment. However, I still need to think about how to do file-tree syncing in an efficient manner - one can't exactly rescan the tree every 'n' seconds.

My current priority is getting the editing experience as smooth as possible, as that's mostly what I've been using this for and so that's where I've identified the most issues. If people find other friction points, do bring them up ^{_{(or even better, submit a PR!)}}.

---

An alternative take on all this would be ship this as a desktop program or editor plugin, which only syncs the local files to the remote computer (with some terminal display too).

This has the advantage that we don't need to faff around with cloud edit and whatever - you've got the "true" filesystem on your machine already. I've definitely found myself making lots of edits and then just copying the complete files onto my local machine. It also means people can work in an environment they're used to (editor, plugins, etc...).

[hugeblank]

It's probably a little overboard, or at least for the first iteration. It would be an interesting feature and, as we have turtle_inventory events, could be implemented rather efficiently. However, it's not something I currently have a use for - I have Minecraft open at the same time as using CC, so it's not any easier to do it in-browser.

Just a thought, maybe worth taking a look at it after 1.0 release :)

---

I still need to think about how to do file-tree syncing in an efficient manner - one can't exactly rescan the tree every 'n' seconds.

Why not modify the FS/IO API to queue an event of some sort (file_modify?). From there send that event to the cloud and update the tree like that.

[ghost]

File uploading?

[ghost]

If the change is too big, split the contents, then create/edit the file. (this will help alot)

[Akxe]

Possible upgrades?

• reload program on file save
  • see error in a console if any
    • highlight error place in editor