vscode-ibmi
vscode-ibmi copied to clipboard
Dynamic Color Theme'ing based on current IBM i Connection
Is your feature request related to a problem? Please describe. I connect to multiple machines a day simultaneously by opening a new VS Code Window and connecting to the different machine. Sometimes I forget to check the icon on the bottom row that says which IBM i that I am connected to and I end up changing files on the wrong machine.
Describe the solution you'd like I would like to be able to configure the connections by the window's editor colors. There is an extension out there called Window Colors (https://marketplace.visualstudio.com/items?itemName=stuart.unique-window-colors) that has this ability to change the titleBar's colors based on the root folder name of the current project you are working on. It would be awesome if in the connection's Advanced Settings we could change the same settings that extension uses to make sure that connection always consistently has the same distinctive color.
Describe alternatives you've considered Other ideas on on manging multiple connections simultanesouly are welcomed. Maybe making it possible to connect to multiple machines at the same time and then click on the "IBM i:" icon at the bottom to switch environments.
Additional context
A very cute idea indeed. I will look into this and post further information if I see it as viable.
So I took a look at this and I think it's such a cool idea! With that being said.. it's not going to be an easy task. It's something that I will look into adding when I can spare some hours to do it! Of course, someone else is welcome to pick it up.
This is what I had in mind:
- A new option in the connection settings
- That option will be a select box with many colors:
- Default
- Light blue
- Dark blue
- Light red
- Dark red
- Light green
- Dark green
- Light purple
- Dark purple
- Light yellow
- Dark yellow
We could also let users provide their own hex colour... but I mostly want to keep this as simple as possible.
Would love to hear what you think about this.
I think that sounds perfect. Allowing users to do their own Hex colours could be a future enhancement beyond this one.
After some further investigation into how the colors work.. it will be a bit tricky.
We can have only two types of settings:\
- global settings, which affects all VS Code instances
- If we update this, it will change all VS Code instances
- workspace settings, which affects all VS Code instances using the current workspace.
- if we update this it will only usually affect one window or so. The issue here is that we can't guarantee the user would be in a workspace.. and I wouldn't want to make the user go through the effort of making sure they're in one first before making a connection.
Here's another idea:
When you make a connection, we could give the option to tie it to the current workspace (if there is one).. then whenever the user launches VS Code in that workspace.. we could try and automatically connect you. Then that workspace can have its own configuration for that connection and then you could have the colors you wanted for that workspace/connection.
@mahoneyl Please let me know what you think of this based on PR #182:
https://user-images.githubusercontent.com/3708366/121780934-869ace00-cb70-11eb-8f5b-b66d7f4a7c1c.mp4
I like that a lot. I think this adds value in saving your configs and allows people to quickly load up a "daily driver" workspace or associate different colors with different projects/connections.
I think functionally this will also work well because it seems like after you have connected to an IBM i and then go back to "normal VS Code" on the explorer and change the root folder/directory you are working in then it will automatically disconnect you from your current IBM i session. I think that is good because it kind of enforces the mental note that "this color" = "this workspace/connection" and if the color changes it indicates your connected machine might have been changed.
@mahoneyl Glad you think so!
The issue here is that I won't be able to merge it in unless it is tested by others.
Do you think you'd be able to build the extension and have a go yourself? I am happy to write some instructions if you needed!
@worksofliam I could help test it! Shoot me the instructions and step by step, and I will try to get it tested this weekend!
@worksofliam What's the current status on this? When will it find its way into the production build?
@szsascha there is a PR for this. It needs to be tested more before I would consider merging it.
@worksofliam thank you for your reply.
I've just tried to test it. I did the following:
- Fetch upstream into my private fork
- Switching into feature/181_connection_workspace in my GitHub Desktop client
- Open VS Code in git working dir and running
npm i
- Starting new VS Code instance in debug view by clicking "Run Extension"
- A new VS Code window shows up (like for debugging extensions)
- Creating a new workspace
- Switching into the new workspace
- Clicking on the current connection in the left side of the footer. A "Additional settings" tab shows up.
- Can't find color settings
But maybe I'm blind or stupid or both. This happens sometimes :D Maybe @edshaw42 got the same issue?
@worksofliam What am I doing wrong?
During my (unsuccessful tests) I noticed, that you can click the connection in the footer bar as often as you want and everytime a new tab opens up. That's not so nice in my opinion. Would prefer to show the "Additional settings" tab just one time.
@worksofliam What am I doing wrong?
It's been a while, but I believe to test this you need to create a build of the extension and install it (npm run package
). Then try and debug it through there - running the debugger and switching workspaces seems a bit dodgy at times.
During my (unsuccessful tests) I noticed, that you can click the connection in the footer bar as often as you want and everytime a new tab opens up. That's not so nice in my opinion. Would prefer to show the "Additional settings" tab just one time.
I don't see much of an issue here. There also isn't an easy way to detect what web views are open I believe. You could make a PR for this, though.