From 'filemanager' to 'fileeditor' to 'lightweight-ide'

[eine]

@hacdias, first of all I'd like to congratulate you. This is a very interesting piece of software.

Indeed, some months ago I was about to write a file explorer with a vue.js frontend and a golang backend, in order to make it easier to tinker in play-with-docker, and I found your project. Had a quick look and left it to be checked later. The next time, I thought about adding codemirror to enhance the editor, but I didn't start with it because I thought I had to dive into the codebase. Today I had a longer try with it and I am really pleased to know that it is already included. Awesome!

However, I found some issues. I'll put some of them here, and I'll split those you 'accept' to separate issues:

• Already merged/closed/solved: A single command line argument overrides all the defaults #309, Commands: requirements #310, Commands: response for non-existing commands #311, Commands: parser #312.
• To be tested: Edit files without extension #314.
• Open: filebrowser/frontend#55.

---

Tabs

Proposed in #240 for commands. However, I mean it for the main view in the explorer. I.e., keep a common header and sidebar and have multiple main views. I think there is enough space in the header to put the controls corresponding to the tabs, where the active one is marked and it can be changed.

Indeed, I think that tabs should be agnostic to the content, so that three possible contents are shown in each tab:

• Folder, file explorer.
• Editor.
• Command output.

xterm.js

Related to #240, the command functionality can be removed from the search box and handled on its own. I think that an interesting approach would be to use xterm.js, which is almost as straigthforward as codemirror. Actually, when I proposed the tabs above, I was thinking that the 'Command output' tab type would be, in fact, an xterm.js terminal. E.g. xtermjs/xterm.js#573 (note the tabs).

However, on the one hand the image should be reverted to alpine, in order to have a shell available. On the other hand, I don't know how much flexibility you want to let the users have. If you are ok with them being quite free inside the container, I think that integrating xterm is seamless. If not, I am not sure of which steps would be required to limit the functionality.

An interesting feature of xterm.js is changing to full screen with Alt+Return. Thus, if used, the quick access list suggested above would need to use a different shortcut.

Tiling

If tiling is added, such as https://l0rn.github.io/vue-tile-panels/, I think I might drop Atom and use filemanager instead :D (maybe renamed to fileeditor/lightweight-ide XD).

Note that this tiling can be an addition to each tab. That is, inside each tab you can have:

• Folder, file explorer.
• Editor.
• Terminal.
• Tile container.

Then, each block in the tile container can take any of the above, ad infinitum.

Last, replicating the Alt+Return functionality, any container at any level would be allowed to be shown in full page.

---

Let me know what you think about these proposals. Do you find it interesting to push filemanager to this path or do you prefer to keep it more lightweight from the library dependencies point of view?

[hacdias]

Hello @1138-4eb!

A single command line argument overrides all the defaults

I have to check this to see what's going on. Not sure if it's caused by Viper or something I've done wrong but I don't remember having any issues with that.

Commands: requirements

Yes, Hugo (or any other static website generator) must be installed separately. This way we reduce the File Manager binary size and give the users more flexibility about the version they want to use.

I'll add it to the docs.

Commands: response for non-existing commands

It's strange that you receive an empty object. I'll check that and show a better message.

Commands: parser

A prefix sounds good and makes sense.

Commands: quick access list

It would be interesting. Wouldn't you like to develop it?

Edit files without extension

What if we try to open a binary file without extension?

Tabs

This would be interesting indeed.

xterm.js

Personally, I really like this idea. Although, I think it is outside of the scope of File Manager. I only let some commands to be executed to give the user some flexibility.

If someone wants to have full access to a server, they can use SSH.

Tiling

Hmm... Interesting idea, but maybe trying to develop File Manager too much.

---

In a nutshell: I like your ideas, but I find that some are a bit outside of the scope of this project. I'll check the errors and the problems you had and try to figure out the solutions.

[eine]

I split the first six bugs/enhancement proposals to separate issues, in order to track them better. I think we agree that all of them fit in the scope of this project.

However, I stopped with Tabs, xterm.js and Tiling. As you point out, having all of these combined might be out of the scope of this project. Therefore, I'll like to discuss whether it'd be possible to have two main variants selectable at build time. The 'lightweight' one with a single tab, no tiling and no terminal. The 'full featured' with all of them enabled.

Indeed, related to the option proposed in #310, I think it'd be interesting to have a list of checkboxes to select which features to build. Note that I am not expecting you to actually implement all of these features. Nor do I want to push you to accept any. Yet, I'd like to know how close/far do you think the codebase is from allowing such an approach.

If someone wants to have full access to a server, they can use SSH.

The main objective is not to have full access to a server, but to i) have colorized output and ii) execute interactive (not batch) commands. I am not thinking about running it natively, but inside a container.

See #315 where I explain a use cases that would benefit from minimal interactivity. Note that for this specific use case a single button that kills the process would suffice. No need for xterm.js at all.

Why do I want to execute filemanager or any other app inside the container? Because, how do I test the binary out of the container? I can use docker cp or the frontend to take it out of the container. Yet, my host must have all the runtime dependencies, and it might be a different os (say Windows or macOS). Therefore, I might need to crosscompile. In this context, the docker container does not help much. Hence, the proposed "inception".

---

I think that adding SSH makes filemanager's user and access control redundant and introduces a possible source of conflict. Users are required to handle two separate credentials in order to use the same service.

Moreover, this is directly related to the cmd: label I proposed in #312. Allowing arbitrary values, either absolute or relative, makes filemanager behave as some kind of SSH. However, it is difficult to filter allowed and not allowed resources.

Note that I am ok with removing access control from filemanager when used in a container (--no-auth is used in the example above), and letting admins know that they should use an additional layer. Indeed, in container mode I think that the most 'elegant' approach would be:

• Split user access and database handlers to a 'entrypoint' package.
• Have a single or a set of alpine-based containers (lightweight, full-featured, custom).
• Let admins create derived images:
  • Create system users with fine-grained access control.
  • Add complementary tools/dependencies.
• Make the filemanager entrypoint support 2-3 types of setups for each user:
  • Single directory access with a highly filtered command list in a shared container (equivalent to the current behaviour).
  • Access to a shared or exclusive container with the privileges of a user which is already defined in the image (might or might not be root). Note that in this case filemanager can retrieve credentials from the images, so the login of a user can be just forwarded.

Once again I'd like to know how close/far is the architecture of the program from allowing such a scheme. Of course, the first approach would be minor refactorization in order to support a single image and only a shared container with a highly filtered command list. Indeed, I think that any further additions should be developed as a wrapper around filemanager, so that filemanager itself does not change much from the features and UX point of view. In the end this is an enhancement to the UAC, not to the program itself.

[hacdias]

I'm closing this since this repository will be archived. Please read the information on the README for more information. Thanks for all your contributions!