Allow customizing the color of the sticky scroll for tree elements in the workbench

[jvcmarcenes]

I enabled the workbench.tree.enableStickyScroll setting, but the background of the stickied items is the same as the non-stickied items, which is confusing to me because it's hard to see whether the top items are stickied or not.

I could change the background color for the editor sticky scroll, but I can't do the same for the tree sticky scroll. I want the option to customize the colors of the stickied item.

Alternatively, I would like more ways to separate the sticky items from their contents, such as borders.

[FyeCobain]

bump

[chiefdeals]

bUmP

[benibenj]

It won't be possible to solve this with a single color. Sticky scroll appears in every tree and the tree adopts the background color from it's container, which could be the color of sidebar, panel, quickpick, editor widget, ... As these could all have a different background color, it won't be possible for us to just add a treeStickyScroll.background color.

I'm looking into this and it looks like we would have to add the colors:

• sideBarTreeStickyScroll.background
• panelTreeStickyScroll.background
• quickPickTreeStickyScroll.background
  (might be more, don't know yet)

For each of these entries you probably would also like to set the border, shadow and hover background colors, right?

[cdllc]

Woo alright, my first opportunity to actually contribute with my normal day to day hat. Alright, so, a disclaimer first, decade+ long corporate UX guy learning to code (pun intended) over last 2 years, I make a living on asking clarifying questions that (hopefully) produce insight.

I hear you on the complexity where a potential solution impacts a global set of tree components.

It sounds like (just reiterating) the concern is that a color chosen for one area, to address one need, could be a negative influence on another area since they would be changing due to the same variable. To me, I agree, difficult approach to take and one that would probably introduce more problems than it'd solve (not to mention start to challenge whatever level of accessibility standards you guys are trying to adopt)... so I turn now to spit balling a bit---

Without addressing the colors you've listed directly (since not a comprehensive list anyway) I think the primary problem we're dealing with is a lack of contrast between the two. That leads me to think that for this global component (or even individually if it were ever possible to get to that level of specificity) perhaps exposing a color setting for user choice is less than ideal. If the primary issue is indeed contrast (thoughts?) then would there be a way to programmatically offset the background adoption by some subtle number representing a grayscale? Whether HEX or RGBA or whatever, they compute down to a number that we can mathematically alter for some desired impact.

This would be an example:

This would likely trigger some theme-based OCD, but that comes down to user preference that can be addressed by altering the theme to a liking of their own -- rather than to allow that preference to influence non-action on a glaring accessibility issue. Anyway, this offset, should be able to be toggled on or off, so the user has even more choice:

• It allows the user to address the accessibility issue because it's a legitimate burden on their working style/process & can adjust their theme accordingly, to their liking.
• They keep stickyScroll on their trees, with this toggled off, working with the existing solution with no impact to their theme.
• Or, perhaps, they just dont have stickyScroll enabled on trees.

edit: I forgot to address your last question before hitting submit because I wanted to get to work on other things...

For each of these entries you probably would also like to set the border, shadow and hover background colors, right?

Those might be legitimate desires (I question "needs" - maybe hover, I dont know functionality well enough) at a later time, but for now, to address the glaring problem (which, reiterating is equipping the user with a visual language that differentiates the body of the tree from the stickyScroll of the tree) then contrast could help on its own and perhaps there is no additional work to be done...

(also if tracking my edits, apologies, I'm sleep deprived at the moment)

[jvcmarcenes]

For each of these entries you probably would also like to set the border, shadow and hover background colors, right?

That would be great, yes

If the primary issue is indeed contrast (thoughts?) then would there be a way to programmatically offset the background adoption by some subtle number representing a grayscale?

I like this, but I don't think VSCode has any settings similar to it. In some themes when I want to have some "offset" of a background color I usually just set a white/black with transparency

[benibenj]

We added the following colors for sticky scroll:

• sideBarStickyScroll.background
• sideBarStickyScroll.border
• sideBarStickyScroll.shadow
• panelStickyScroll.background
• panelStickyScroll.border
• panelStickyScroll.shadow

If a tree is in the primary or secondary side bar it will use the sideBarStickyScroll colors. If a tree is located in the panel, the panelStickyScroll colors will be applied. This will cover most trees.

Thanks @cdllc for your input. We did consider it as an option, however, we didn't decide to go with this approach as VSCode does not have a similar offset driven theme concept/color already.