Open Z-E-D opened 2 years ago
This one will be trickier to do since each area shows different states (views, editors, panels, etc.)
cc @bpasero @sbatten for ideas
I think we only have the concept of an "active thing" for editors, not elsewhere. I.e. there is always an active editor even when focus is in the explorer.
Are you referring to keyboard focus, or active view? We do have the latter concept already. Note the orange outline on the explorer view here. Any view should have that behavior even if moved to a different area.
Based on the other discussion in the other issue, it seems like this is more about the HC theme having specific issues surrounding the contrastBorder
's usage since elements appear to be focused even in a resting state. E.g. the tab and terminal view tab here:
We have active and focused views. In the GH theme, we use orange for an active tab in the panel or activity bar, but we have blue for keyboard focus. In high contrast we use orange for both with different shapes, but that doesn't always translate to obvious differentiation.
Guys, thank you very much for your responses.
@daviddossett I am talking about keyboard focus. I am sorry for my ignorance, I am relatively new to VBCode. Would you please explain what do you mean by "active view"? When I open e.g. two or more editors in one group, only one of them could be "active". If I open several groups, each one of them will have one "active" editor. Is that what you call as "active view"?
No matter how many editor groups you have opened, and no matter if you have displayed the bottom panel or not, only one of them could have keyboard focus. But looking at these orange border lines in Dark High Contrast theme, it is hard to tell which one of them has keyboard focus. As you know, all high contrast themes have these border lines around tabs. If you ask me I would use them in non-high contrast themes as well, but that is just my opinion.
By the way, on that screenshot, the Search panel has keyboard focus, although both tab editors and tab in Terminal panel has solid border line.
Maybe it is problem because VSCode is using the same "focusBorder" color setting in themes for all these elements: active item in the Search panel, border line for tabs and even active matched item in the editor after search. Maybe it could help if you introduce some more color settings available for themes.
@sbatten What do you mean by GH theme? Is that GitHub? GitHub Dark High Contrast has blue border line both around tabs and around focused item in the Files/Search panels. GitHub Dark (non-high contrast) doesn't have border line around tabs; it has orange line above active tab, but that line could be defined by theme even in high-contrast themes with "tab.activeBorderTop" (that I am using in my own high-contrast theme to differentiate which group has focus).
@bpasero I am not sure that you have only "active thing" in editors. If you open e.g. Files and Search panels at the same time, next to each other, they both could have one item selected as "active", but only one of them will be focused. Or none of them, if you give focus to editor, in which case they both will have dotted line around the active item, as I mentioned in #145563.
What I am trying to tell, if I wasn't clear initially: I think that you should treat the active/focused tabs of editors/bottom panel as you already treat the files in Folders/Search/Open Editors. I.e. only the focused tab should have the solid border line, the active tab that is not focused should have the dotted border line, as is the case with the items in the Explorer. Which means, if none editor has focus, then none of editor groups should have the solid border line around active tab, but the dotted line.
I hacked together a quick fix that I believe mirrors the list behavior as described. Thoughts?
Active editor group, active tab:
Inactive editor group, active tab:
There are still some minor differences compared the list, which has some additional behavior where we are going from a dotted
to dashed
outline style when hovering on an active, unfocused element. E.g.
Thank you very much! Yes, that's it, but I cannot see from these screenshots what happens to the border line when all editors lose focus. And what about border line of the tab in bottom panel? I want to say, if you just implemented my suggestion in #145563, that would be great, but if you implement this suggestion, I think it would be even better.
I don't understand about the mentioned issue with the hovered elements. It seems to me that hovering over the tabs works fine with dashed lines and maybe that thing with drag&drop would be just nitpicking.
Do you implemented my suggestion in #145563 where one active tab always has solid border line even if none editor has focus?
Yeah, this is basically that. It's only scoped to the editor groups at the moment and doesn't implement anything new for other areas like the panels.
Just so I make sure I'm understanding correctly, is this what you're looking for? I.e. the active states in each area use a dotted border if selected. Selected states for focused areas use a solid border:
That screenshot would be fine if your left group has focus and right group has hovered tab since it has dashed border.
Here is one detailed example, if you don't mind. Let say that I have two groups with editors, one bottom panel and three panels in side bars, as is the case on my screenshot.
That screenshot would be fine if your left group has focus and right group has hovered tab since it has dashed border.
Ah, that was my mistake. It should be dotted, not dashed. Your examples make sense to me and align with my thinking. Updating the screenshot for reference:
I'll wait for any other input here. As pointed out earlier I think we'll need some universal way for each area to know if it's in focus or not. I'm not sure if that's the case today but others can chime in.
My answer on StackOverflow might be relevant to this discussion. It is relevant to #84773, although that issue has been locked.
TLDR: You might be able to use custom CSS to achieve your desired effect? It is not a perfect solution, but might be a good workaround until this issue is addressed.
:is(
.editor-group-container,
#workbench\.parts\.sidebar,
#workbench\.parts\.activitybar,
):has(:focus):before {
content: "";
position: absolute;
z-index: 10;
box-sizing: border-box;
width: 100%;
height: 100%;
border: 1px solid red;
pointer-events: none;
}
@scottwillmoore Your suggestion is not relevant to this issue. I am not asking to highlight borders of the whole active editor, otherwise it would be duplicate of the other issue that you mentioned.
It was my fault that I didn't explain better what I am calling an "active item". If you look on my screenshot in the first post you will see several window parts and four of them have the active item that you see surrounded by the orange solid border lines in Dark High Contrast theme: two editor tabs in two editor groups, one bottom panel tab and one item in the list of Search panel. I asked that only one of them that is with the keyboard focus actually would have the solid border lines, and others to have the dotted border lines.
This is an expansion for my previously reported issue (#145563). Sometimes it is really hard to determine which part of the program has focus. Let say that we have opened the primary side bar with Open Editors and Folders, two editors in two groups, the secondary side bar with Search and the bottom panel, like this:
There are several parts of the program in this screenshot that have solid border line for the active item: two editor tabs, one bottom panel tab and one item in the Search panel. Guess which one of them has focus?
I suggest that only focused one has solid border line, and for the others to have dotted border line.