Open Tyriar opened 8 years ago
@Tyriar Thanks a lot for bringing up the issues with colors and providing some suggestions. I agree that we have many color contrubutions and they get mix and matched. Please see Editor Decorations & Colors wiki which me and @alexandrudima came up with.
Most of them define new colors and some reuse already defined. They should be defined such a way that they look good when applied individually with the given background. Otherwise, we have to go and fix them. As they are dependent on the theme (background etc), its hard to fix them for all themes. Hence, as a first step we fix them in our defaults and extract them as custom TM settings (just like Sublime) which fixes this problem.
I tried to map the new settings as much with Sublime defined ones, but we differ a lot in usage. For eg: Sublime uses color value of findHighlight
setting for highlighting find match, but we use that color for highlighting the line of find match, go to line (as range highlight). So using those settings will give us un expected and un wanted results. Hence, we defined our own settings which is also good IMO. Users having issues with some colors in themes can always create an issue against the theme.
When more than one functionalities overlap, we have unexpected colors. For eg: Find + Select or Select + Wordhighlight. We do not have a proper solution for this and may be I think we need UX assistance to tackle this.
Why don't we try to align more with how Sublime behaves considering that's what the majority of the themes were designed for? findHighlight
seems like a prime example of something we should align with, this is something that my theme defines but it isn't used.
I don't think the suggestion that users can just create an issue against the theme is realistic. To give an example, of the 10 top themes in the marketplace:
@Tyriar I like the idea of making Sublime themes compatible with our product out of the box. It's less hassle for users and theme-makers.
@Tyriar @sandy081 Let's talk about this at UX sync tomorrow morning, if you can attend.
My 2 cents:
findHighlight
color to render a border around find matches, we can't render borders on our decorations because we render multiline decorations by rendering a patch for each line because we don't do the text layout, etc. We cannot take a border color and use it as a background, it will look bad.Hi I would like to share my point of view.
Thanks, and keep the great work!
@Tyriar @bgashler1 As I mentioned in my (previous comment)[https://github.com/Microsoft/vscode/issues/11354#issuecomment-244065261] that I tried to match our keys/colors/behavior with those of Sublime. But they are not one-to-one. Refer here for Sublime color settings
To be aligned with Sublime specific keys, we have to change our UI representations. Also we have new concepts which I think Sublime does not have. Hence, I am not in favor of this.
Also note that, we aligned with some settings with Sublime which are in sync with VS Code.
I agree with @alexandrudima to have VS Code specific color settings.
+1 on @alexandrudima comment. While we have a easy way to start authoring a theme by importing an existing one from sublime or text mate, adaptation is required as there are feature differences between the products. Some of these feature differences are intended, some are given by the underlying architecture. Therefore also themes will not be interchangeable by products. This never was a goal, and should not become one. It's the same with Sublime customizing TextMate themes, or Atom customizing TextMate and Sublime themes.
What I think would be great if the UX team could document and maybe simplify the different colors we use in our UI and the concept behind them (selection color, input border color, focus border color....). Not just in the editor and its contributions, but also in the workbench. I think there is a lot of potential of unifying the colors of the various widgets. The goal of this would be a more consistent UI as well as making it possible to theme the workbench (not just the editor).
I think the Sublime theme compatibility topic is largely closed which is fine, let's commit to these new properties and document them to increase visibility to theme authors. So there are still a few more actions that should be taken/discussed:
I've started making a few PRs to themes (MS and external) to make them more presentable in the marketplace (repo links, screenshots, preview, etc.) to tackle a related problem with themes.
Thanks all for having this discussion, this will help a lot with the issues I've been experiencing trying to build my own theme.
After all, as a text editor rather than a neon displayer. I think we just need fewer kind of highlight such as selection, current line and find match. Then it is just enough, isn't it
I'm commenting here (as a daily VS Code user only, not a developer) because I found an earlier closed issue (Selection and selection matches highlight color #1636) - i.e. if you actually select some text, it's indistinguishable from the highlight used for matched code pairs, or matches to the current word at the cursor position.
If the system-wide highlight colour (when selecting any text system-wide) isn't portable to VS Code, I need a way to edit it in a user-generated 'override css' file or something (like user settings), which appears to be impossible without creating a new theme. I'm using 'Dark'.
Just to make sure I'm not missing something, I posted this as a question on StackOverflow
Is there a way for disabling selection matches for the time being? I started using VS code today and it's possible to distinguish my selections. In this screenshot the first this
is selected while the others are highlighted. It's just impossible for me to know when I selected something
@FabioAntunes
in user settings :
"editor.selectionHighlight": false
any update? How about use border with match select like atom?
@iulo have you looked at the screenshot? That's what's on my configs on the right
Follow up from #1636
I think we need to take a step back and take a good look at editor selection colors. Currently there are so many states, it's very confusing as to what find match, selection match is what and even what the actual selection is.
Here are some of the states using my theme Glacier:
Selection Find match Symbol match Selection match (lighter than word match) Selection + selection match Selection + find match + symbol match Symbol highlight "Strong" symbol highlight for cursor word "Strong" symbol highlight for words away from cursor Selection + "Strong" symbol highlight for cursor word Selection + "Strong" symbol highlight for cursor word (when selecting via ctrl+d) Selection + "Strong" symbol highlight for cursor word (when selecting via ctrl+d) + Find match
This is in no way an exhaustive list of states but I think it gets the point across. Here are some of my initial thoughts:
Is strong symbol highlight useful? We already have a color to indicate symbols and they can't both show at once.
Why are both
userEnv
variables highlighted with the strong symbol highlight below but not above?.tmTheme
files and not adjusted to work better with vscode, we should make an effort to have the defaults work and only add additional tmTheme properties if they are absolutely necessary.findHighlight
is defined in many themes, why don't we adopt that since Sublime uses it?Personally I think something like below would be more usable despite being so simple (this is to illustrate my point, I'm not proposing this):
selection
color from themeselection
color at 50% opacity