• @isidorn as author of SelectBox widget.

@cleidigh this is pretty cool because it fixes also #25700

I think we should probably not use this on macOS though where the dropdown looks very native and good imho:

Can we have a flag on which OS to enable this?

Some general feedack:

• pressing Space should also trigger the dropdown
• clicking outside the dropdown does not seem to close it
• the dropdown flows outside of the window if the space is little
  
  you should maybe look into ContextView which is a reusable widget for showing something within the window on top of other controls. I think that widget would save you quite a bit of layout code to write. You can see it in action for example for the feedback widget:

@cleidigh thanks for your work. Once you address @bpasero feedback I can also look into this and provide additional feedback.

@bpasero
Excellent! Glad you like it.
Have to admit I've really learned a lot since April starting this,
all good!

@isidorn - Sounds good, I will flush this out per comments...

• good to take care of another issue Windows: dropdown selector empty after reload of window #25700 - bonus points ;-)
• Will look into contextView
• Question : Does a workbench relayout event exists somewhere?
• I used a null animation rule with callback to recalculate and reposition select box
• Question : Since OS X is presumably the only platform that has a different approach to the select box
  Should there just be a switch for that? Since the other OS' already use a partially themed
  SelectBox. Perhaps: workbench.themes.useNativeOSXDropDown (default === true)
• Question : Should I make the outline colors configurable, they mapped to active contrast selectOptionCheckedOutline
  right now.

Regarding the hover issue I mentioned:

If you opened three or four terminals and hover over the drop-down list,
every once in a while option two eg Cmd 2/Bash2 would not highlight
Very odd, does not appear to happen on Debug drop-down. I believe
this may be an odd select issue.

Do you see this?

I will start working on the punch list, take advantage of ContextView
and look at a simple list if select issues really exist.

@bpasero

Scratch Question 1
I got my head around ContextView and got all the clients to pass the dependency
and I think I have the basics working. I see layout gets called with screen changes
so that answers question number one.

I'm working on the rest and converting the native select to a simple list.
I think I have found the select has some really odd quirks that would otherwise bite us.

I am having some trouble with applying styles through the CSS file, not sure If
there are some limitations or tricks to this when using context view?

@cleidigh good point, using our ListWidget is probably a good idea for the dropdown because that takes away a lot of extra work and it already comes with the proper theming of list widgets as done in other places in the UI.

The styling of context view is a bit special because as far as I remember it is rooted as direct child of the body element and not within the workbench bounds. Maybe take a look at how we style the feedback widget that is using the context view.

@bpasero

Before I go too much further I want to make sure we are on the same page
so I can do this right.

• General goal: extend SelectBox to include two modes:
  1. existing, native select, all current limitations colors/oddities
  2. extended theme colors , non-select , ContextView
• Functionality/Appearance essentially as my current implementation
• Provide settings option to allow user to choose mode (switch type/defaults TBD)
  Comments on my prior thoughts on this?
  Perhaps caller should also be able to choose mode
• Any reason to use Tree instead of the base list? Scrollbar?
• Provide color overrides to allow select different from list if desired
• List navigation needs to deal with 'disabled' entries (assume not a problem)
• ARIA labels (another improvement?)
• Minimal interface changes (had to pass ContextView from all clients)

I now have a working drop-down utilizing ContextView, CSS file based styling, anchored
to the select box with focus/blur and show and hide. I am assuming
adding the list should not be too much trouble. After some more experiments
I will make sure my implementation for the contextView is correct.

Thanks/Cheers

@cleidigh yes being able to flip between native and custom solution seems desirable to me. We can still think about using this solution on all OS, but the macOS behaviour imho is not so bad but rather what you would get with a native application too. I do not think this should be a user facing setting though, rather something we decide per platform.

For the custom dropdown I would go with the context-view + list widget approach. I am not sure how to best deal with disabled list options though. One challenge for the list widget is how to model disabled options. The notion of disabled items is not provided from the widget. The styling could obviously be done, but the keyboard navigation is probably something that would have to be done on top (so that e.g. when you arrow up or down you jump over the disabled element).

I do not think we should use the tree widget because we are trying to model a list.

I think the list widget has all the ARIA support we need.

@bpasero
Thanks, sounds good.
Already have the list working with keyboard support at the client level. Disabled options no problem. May have some styling questions.
I will crank away until I have some intelligent questions or something decent to review...

@bpasero
@isidorn

Re-factoring for contextview and the list widget required more learning and experiments. Hopefully it will make the next contribution faster !

I've already done a lot of cleanup, but I still have a bit of potential renaming and simplification to do. It is in pretty good shape for review. Besides addressing prior comments I also
took care of a lot of small details and edge conditions.

Linking to a new branch, will merge or post new PR depending on your preference when done. I wanted to keep selectbox-2/add separate and alone until done.
https://github.com/cleidigh/vscode/tree/selectbox-3/add

Issues/Status:

NativeSelectSwitch:
Currently forces OS X to use native select.
I put an override line if you want to see the OS X with full theming.

Vertical overflow/Margin:
Used margin constant above statusbar (had to use status bar ID)
Horizontal - thinking/in progress.

List container width:
Had to use a hidden flexbox container to control width
Possible better solution ?

Contextview tracking problem:
I found instances where the contextview container/drop-down did not follow a shifted anchor. This appears to happen with the terminal drop-down when it shifts in an overflow situation
I have some deep up tracking the positions and can see the differences but doing a correction affects other situations that work fine.

I am going to continue to test/experiment.
@Tyriar : I would like to understand how the terminal menus get shifted
when there is a horizontal overflow condition and the terminal
drop down gets focus.

Cheers/Thanks

@cleidigh keep in mind that we have adopted the composite bar in master - which basically takes care of overflow behavior for top level panel actions. Due to this the whole overflow behavior in the panel will change. You can check it out in latest insiders

@isidorn
Thanks for the heads up. I see you Just did stuff on this yesterday. I will sink and test
to see if this corrects the problem.

@cleidigh I think @isidorn did the control used for the terminal dropdown. I just picked up an available component for that.

@bpasero
@isidorn
Re-synced with master this morning to check out the vertical panel mode with a select box utilizing
a context view drop-down. The tracking issue still persists you can see an example in the screenshot below. The offset does not go away even if you close the drop-down and reopen it.

I have not seen a similar issue with the debug drop-down, but this does not have the same title adjustments that the panel does. So far this is the only 'identified' problem I have found no answer to.

I think I fixed the tracking issue. There is a situation when the panel dropdown gets partially hidden.
This is a panel overflow issue. I'll capture what I'm talking about.

Tweaking some lipstick ;-)
Will push to my repository after pig gets lipstick.

@bpasero
@isidorn
I know it's endgame... just posting for the November Q.

I have fixed all the issues I have found as well as addressing a lot of aesthetic issues.

• Vertical margins addressed
• Horizontal margins - controlled by ContextV - only flips when window edge hit
  • Could address this with optional margin requirements passed to ContextV (your call)
  • Cannot use CSS or forced resize because it conflicts with ContextV logic
• Added VerticalScrollBar visibility option to listview - could also add horizontal
• Tweaked margins for high contrast mode
• DropDown is fully modal - could pass through other keyboard commands if desired
• Re-Tested non-native select mode on : Windows 7, OS X, Debian
• As first list/ContextV effort , make sure I didn't miss use anything !

Let me know if I should try to merge, or update or issue new clean/squashed PR
Latest:

master...cleidigh:selectbox-3/squash2

@cleidigh thanks, I will try to reserve time in November to test and review in this PR.

@cleidigh it looks like you are not using the List widget within the dropdown right? Is there any reason? I think it would make a lot of things easier, specifically keyboard handling within the list as well as theming. The list is already coming with colors for selected/focused elements.

Also, did you find out if it is possible to use the context view widget?

@bpasero
I did completely convert to both , more tricks than I expected... Sorry, I thought it was clear enough above
I created a new branch not PR to leave the PR alone since I was not sure I could update and merge well.

Latest/List/Contextv :
https://github.com/cleidigh/vscode/tree/selectbox-3/squash2

I wanted your choice whether I did a new PR or attempted to back Merge the current. I know if I update I probably cannot squash commits on old.

@cleidigh oh yeah I misunderstood you, sorry. Feel free to create a new PR with your work so we have them separate, thanks!

@bpasero
Sounds good I will squash the commits hopefully without trouble and create a new PR now

@bpasero
See new PR
#37533

Closing, replaced by PR #37533