Support a special view in the quick pick optimized for displaying icons

[Tyriar]

The terminal has this existing icon selector:

There are several problems with this though:

• Internal codicon details are exposed, for example there are 4 plus icons at the start
• Icons are not translated
• All codicons are included, meaning themed icons like red debug breakpoints are included
• Picking an icon visually is a headache as you need to either search for what you think the icon is called or look through the whole list

@hbons put together this prototype exploring an icon selector for profiles:

I propose we implement @hbons's mock up above, but do it in such a way that the quick pick can be opened in a special mode that shows icons only initially. Then when filtering, it could revert to the standard display closer to the terminal's current icon picker so that the filtered search text is visible and it acts like a regular quick pick.

Doing it this way as opposed to creating a whole new UI component allows us to share code, enhance the quick pick, potentially expose this new mode as an extension API and keep the UX as consistent as possible.

[TylerLeonhardt]

Yeah this makes sense to me. We use a list for QuickPick today... so we'd still need some sort of a grid thing? If we don't have that already?

vscode/src/vs/platform/quickinput/common/quickInput.ts

Lines 278 to 388 in e682a8d

	export interface IQuickPick<T extends IQuickPickItem> extends IQuickInput {
	value: string;
	/**
	* A method that allows to massage the value used
	* for filtering, e.g, to remove certain parts.
	*/
	filterValue: (value: string) => string;
	ariaLabel: string | undefined;
	placeholder: string | undefined;
	readonly onDidChangeValue: Event<string>;
	readonly onWillAccept: Event<IQuickPickWillAcceptEvent>;
	readonly onDidAccept: Event<IQuickPickDidAcceptEvent>;
	/**
	* If enabled, will fire the `onDidAccept` event when
	* pressing the arrow-right key with the idea of accepting
	* the selected item without closing the picker.
	*/
	canAcceptInBackground: boolean;
	ok: boolean | 'default';
	readonly onDidCustom: Event<void>;
	customButton: boolean;
	customLabel: string | undefined;
	customHover: string | undefined;
	readonly onDidTriggerItemButton: Event<IQuickPickItemButtonEvent<T>>;
	readonly onDidTriggerSeparatorButton: Event<IQuickPickSeparatorButtonEvent>;
	items: ReadonlyArray<T | IQuickPickSeparator>;
	scrollTop: number; // used in tests
	canSelectMany: boolean;
	matchOnDescription: boolean;
	matchOnDetail: boolean;
	matchOnLabel: boolean;
	/**
	* The mode to filter label with. Fuzzy will use fuzzy searching and
	* contiguous will make filter entries that do not contain the exact string
	* (including whitespace). This defaults to `'fuzzy'`.
	*/
	matchOnLabelMode: 'fuzzy' | 'contiguous';
	sortByLabel: boolean;
	autoFocusOnList: boolean;
	keepScrollPosition: boolean;
	quickNavigate: IQuickNavigateConfiguration | undefined;
	activeItems: ReadonlyArray<T>;
	readonly onDidChangeActive: Event<T[]>;
	/**
	* Allows to control which entry should be activated by default.
	*/
	itemActivation: ItemActivation;
	selectedItems: ReadonlyArray<T>;
	readonly onDidChangeSelection: Event<T[]>;
	readonly keyMods: IKeyMods;
	valueSelection: Readonly<[number, number]> | undefined;
	validationMessage: string | undefined;
	severity: Severity;
	inputHasFocus(): boolean;
	focusOnInput(): void;
	/**
	* Hides the input box from the picker UI. This is typically used
	* in combination with quick-navigation where no search UI should
	* be presented.
	*/
	hideInput: boolean;
	/**
	* Allows to control if the count for the items should be shown
	*/
	hideCountBadge: boolean;
	hideCheckAll: boolean;
	/**
	* A set of `Toggle` objects to add to the input box.
	*/
	toggles: IQuickInputToggle[] | undefined;
	}

Here's what QuickPick looks like today... maybe we have an option called iconOnly or similar to only render the icons of QuickPickItems.

[sandy081]

@TylerLeonhardt I would like to work on this because it is needed for profiles icon feature. I will come up with a PR. Hope this is fine.

[Tyriar]

maybe we have an option called iconOnly or similar to only render the icons of QuickPickItems.

I think filtering should revert to the regular view so users can see the text/ids behind the scenes, this makes also helps tie the experiences together in the mind of the user. If that's the approach we take, something more along the lines of an icon preferred/focused view would be better than using "only" as the option.

[TylerLeonhardt]

I think filtering should revert to the regular view so users can see the text/ids behind the scenes,

Idk... Slack doesn't do that:

nor does Teams:

However, they both support showing the id on hover which we could do.

[Tyriar]

@TylerLeonhardt it would be better if the emoji picker did do that imo, otherwise it's difficult knowing what text is being searched especially without using the mouse (and vscode users like to work with text and the keyboard). Good topic for the UX sync?

[TylerLeonhardt]

I feel like folks will use the filter in the emoji picker often... more than not.

If so, and if we revert back to normal quick pick behavior, then this, which will require quite a bit of work to implement, will only be used in such a small scenario...

[Tyriar]

@TylerLeonhardt if it was just the regular quick pick it suffers from the issues where it's difficult to find an icon if you don't know what you're looking for as described in the top comment

[sandy081]

Throwing another idea: How about supporting in place context widget like below?

If we have a profile management editor, then this will give better user experience.

[hbons]

@sandy081 We could do that when we have local QuickPick mode. See #189030. For now I'd hold off creating a new control.

[hbons]

Agree with @TylerLeonhardt it would be nicer to keep the grid mode when searching. We could show the non-matching icons in disabled state instead of hiding them.

[TylerLeonhardt]

Coming back to do this post-UX sync... I agree with @Tyriar that resorting to the list view when the user types something in the input is ideal. Mostly because:

• right arrow & left arrow keys will have a more aligned behavior
• the user can see what the label of the icon is

[TylerLeonhardt]

Moving this to backlog since this is a feature request of the quick pick and I'm not planning on picking this up at the moment.