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

Improve vscode che plugins UX and flow in my workspace view #14565

Closed
3 tasks
sunix opened this issue Sep 17, 2019 · 2 comments
Closed
3 tasks

Improve vscode che plugins UX and flow in my workspace view #14565

sunix opened this issue Sep 17, 2019 · 2 comments
Labels
kind/enhancement A feature request - must adhere to the feature request template. kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach

Comments

@sunix
Copy link
Contributor

sunix commented Sep 17, 2019

Is your enhancement related to a problem? Please describe.

In this issue I would like to start a discussion on how we should use and present my workspace view. One of the main problem of the view is that we consider that the user would rarely have access to the sidecar container of a plugin which is in my opinion a wrong assumption.
The author of a devfile should be able to tell if a sidecar container should be accessible to the user.
It really makes sense for language plugins: containers usually come with a sidecar container and the user may not want to create/access another container to use the same tools when using the terminal or a che-command.
User may want to access to the sidecar container to use exactly the same version of the compilers and so on from the terminal or a che-command

Describe the solution you'd like

  • We could keep the default behavior as it is by default, but have a flag in the devfile that tell if a plugin has to be visible for the end user when accessing the terminal or using a task.
  • Nicely display the label of a plugin container: for instance a plugin 'vscode-ansible' would be displayed 'vscode-ansiblez20'

Describe alternatives you've considered

@sunix sunix added the kind/enhancement A feature request - must adhere to the feature request template. label Sep 17, 2019
@che-bot che-bot added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Sep 17, 2019
@l0rd l0rd added kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach and removed status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. labels Sep 17, 2019
@gorkem
Copy link
Contributor

gorkem commented Sep 18, 2019

I am not bothered by the my workspace view behaviour. It just affects the initial state of the tree. However open terminal behaviour is the one that I do not like.

I am -1 for the flags on devfile. It should be the user's choice what is displayed on the UI. How about a user preference for showing all containers or not?

+1 on the labels for the plugin container.

@che-bot che-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Mar 18, 2020
@che-bot
Copy link
Contributor

che-bot commented Mar 18, 2020

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

@che-bot che-bot closed this as completed Mar 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A feature request - must adhere to the feature request template. kind/epic A long-lived, PM-driven feature request. Must include a checklist of items that must be completed. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. status/analyzing An issue has been proposed and it is currently being analyzed for effort and implementation approach
Projects
None yet
Development

No branches or pull requests

4 participants