Che: Request: for better UI on IDE especially for terminal

[thyeun]

Possible to provide a better UI on IDE.

1. For UI terminal, request for a UI that will roll-up while mouse pointer over it, and set a small "lock" icon, as a permanent stay at the IDE if the "lock" is activated.
   Reason : to provide a better wide IDE editor.
2. For UI explorer, request same like the UI terminal, but in-additional the side bar can be flexible move from left side to right side.
   Reason : to have a better user friendly interface.
3. For "About" content at the menu bar, request to add-in a "upgrade" button, the button will automatically activated once there is a new stable release from codenvy/che.
   Reason : to provide a better upgrade for the new release.
4. For UI preview for HTML/markdown, request for a preview on the file extension HTML/markdown, so that it will be easily see the outcome result.
   Reason : easily to provide a better preview while modification are make

[ghost]

@thyeun have you tried the latest master? We have got brand new terminal split view there.

[thyeun]

@eivantsov if version 4.6.2, yes, but the split terminal take some of the space of the IDE editor, it will make the IDE editor look smaller, it will be look good if it can be enlarge out .... :p

[ghost]

@thyeun I'll let @slemeur and @TylerJewell comment

[slemeur]

@thyeun : Thanks for your feature requests.

_UX Aspects:_
There are various aspects behind the needs you are expressing. As I understand it, the main point is to be able to use more space for the editor itself by collapsing the other panels.
Today, you have the ability to maximize the editor by clicking on the following icon (top right corner).

We are going to improve that behaviour and make it generic for any kind of panels, the UX will be rethink for those kind of use cases.

Your proposal is interesting and we will consider it as well. I think in certain cases, it would be a great idea to explore.

_Upgrade mecanisms:_
We are considering to add a message in the dashboard in to notify the developer that a new version of Che is available.
But having said that, if you are using the default Che Launcher, when you start Che it automatically pulls the latest published released of Che.

_HTML/markdown:_
+1
Our roadmap is flat out for the upcoming month on this kind of requests. To get a solution quickly, that would be wonderful to see the community building them. Would you be interested to do that?

[thyeun]

@slemeur, cant join the community, due to that i'm busy with AOI on using openCV (company work), Che launcher are superb, but why not let the syntax married to the UI, so that UI can have a upgrade button :p.

an example, if i'm already at the IDE editor, i wont need to out of the IDE editor to notice the upgrade are ready, meaning that upgrade can be running at the background from the "upgrade button", and it wont interrupt my work on IDE editor.

[TylerJewell]

Maybe we'll consider it in the future. It's an extremely difficult engineering challenge. If the browser loses connections to che server or any of its workspaces, there is no auto-reconnect. Also, the che server is not aware that it was launched by the che-launcher, or various other tactics (such as vagrant), so to honor the same settings, the reboot cycle has to happen with the same utility that started the server in the first place. This may be something we look at in a few quarters.

[thyeun]

@TylerJewell, can it be like this

new upgrade ready ---> compare checksum -----> if checksum different -----> upgrade start! ("upgrade button" visible for user press)

**checksum will checking out (with a time triggering)

Time triggering - 14 days trigger one time (can be shorter or longer time)
Once Checksum different - "upgrade button" will become visible (meaning that a new release are out) and if checksum remain the same "upgrade button" will remain invisible

for different OS and different platform, possible to have a standardize syntax, an example, "Che upgrade" and it can be use for all different OS (linux/win/macOS) and different platform (VboxVM/Hyper-V/Vagrant)

for the losing cloud connection, will it be possible to have an "internal refresh" (meaning that 30sec the "internal process" will refresh (only happen if disconnected) but only for some particular model will be refresh and it running at the background)

1. Have particular ID for model/container/internal process, so that once the "internal refresh" it will reconnect each particular ID that will be call-up to reconnect
   an example : if i disconnect, "resolving host" message will be trigger, once it trigger, it will done the "internal refresh" and do the reconnect of the particular ID.
2. Once the reconnected are make, a message will appear "workspaces are reconnected".

[TylerJewell]

It's easy for us to detect a new version is available. It's not possible with the current architecture to automate the update cycle easily. The user needs to stop che, update the che image, and then restart it for those changes to be activated. Che servers are running inside of containers. So are workspaces. All of these containers need to be cycled down and back up, and cannot be initiated from inside the container. It has to be initiated from outside the servers / containers to have a proper cycle so that there is total fidelity of the data.

We have ideas on how we can improve this - but maybe we'll just add a little notification in the dashboard to indicate that a new version is available, but we will still require users to stop and start Che on the command line.

[thyeun]

@TylerJewell, sorry for given out a bad ideal.

i been trying it out just now, and notice that it wont make the change. it will make the change only if i stop che and restart che, than only i can see the change that i try (try on a small plug-in).

[TylerJewell]

We do all sorts of complicated logic to manage this workflow inside of Codenvy. It's why Codenvy is a distributed system with multiple services. One of those services is just responsible for managing the environmental configuration, installing new versions, and then updating the system when certain configuration changes - all in a way that minimizes disruption to end users.

Because we run Che in a single server with distributed workspaces, it makes it super super simple to start / stop che, but the only way to support these upgrade scenarios is to start to layer in external servers that can manage the upgrade / downgrade cycle.

[JamesDrummond]

Should this issue be labelled enhancement or is there a question that still needs answering?

@thyeun
Looking at the original items in this post I see 3 possible enhancement requests:

1. If you are talking about a collapsed process area, it may need a better indication on how to bring it back up.
2. You want to be able to adjust the far left pane UI explorer.
3. I think Tyler explained why this is not possible.
4. HTML/Markdown preview.

Below is a quick screen capture of what I think item 1 and 2 entail. Let me know if they are accurate.

[thyeun]

@JamesDrummond, 1 and 2 are not prefer like that

1 - the gif you show are need to be drag it up using mouse (for the terminal UI), what i request are something like, when your mouse pointer, on point/click, the UI will auto roll-up to the original "area"

2 - i request to have a possibility to move the left side explorer to the right side, meaning that i can switch left/right according user need.

3 - @TylerJewell already mention for the current state, it is not possible

4 - i think it is needed because i'm sure alot of users are deal with html and markdown.

[TylerJewell]

We need issues to be separated into different issues. We cannot manage different issues in a single issue statement. There is no way to manage the lifecycle completely.

For 1, we are adding a maximize and minimize capability for each panel coming soon.

For 2, this a nice request but this is not something that I think we will add. There are many formatting issues that it poses. I appreciate that for cultures that have languages that read right to left that it may be desirable.

[TylerJewell]

@thyeun - going to close this issue because it's really many issues in a single one. We can keep this in the records, but we need each item to be tracked as a single item. The latest version has a new max / min widget in the IDE, which solves one of your issues.