There is a ‘ports view’ that you can open from the ‘views’ menu or by clicking on the ‘ports’ entry in the blue status bar on the bottom. We should definitely improve the discoverability of that, as you are not the first to ask this question. Thanks!
Thanks for the kind words. We are releasing the self-hosting version in a couple of weeks together with GitLab support (and GitHub Enterprise). Please drop me a mail (sven.efftinge at typefox.io) if you are interested in early access or want to discuss further things.
The team is working on making existing VS Code extensions work. During this we align some of the internals with VS Code. Once the first Vs Code extensions work better than the equivalent Theia extensions we will stop working on the latter but contribute to the Vs Code extensions instead. Does that make sense?
You have workspace preferences which are shared among the team and user preferences which can overrule them. In gitpod.io the user preferences are stored with the user and reused across workspaces but per user.
:-) I hope my post doesn’t emphasize the ‘standardization’ bit too much. I hate uniform and stubborn processes. What I am talking about is putting the knowledge of dev team together to create a really awesome project setup that everyone will love to work on (and will eventually be even more productive with than her own)
Yes, that is one of the main arguments against such an approach. I am at all not after unification here, it is just that sharing dev setups has so many advantages that I am fine trading some of my individualism for that. That said, for configuration, user specific settings should be used. For tools, I think adding ‘optional’ tools that are not used…
That is exactly how it works. You can put a gitpod configuration file into the root of your repository. In those cases where you don’t have write permissions you can make a pull request to our definitely-gp repository.