Proposal: ColorPicker horizontal mode

[marcelwgn]

API spec proposal: microsoft/microsoft-ui-xaml-specs#53

Proposal: ColorPicker horizontal mode

Summary

The current layout of the ColorPicker is mainly designed to grow in height. However in some cases, it may be better to have the ColorPicker to be wide, not high.

Rationale

• In cases were height is limited, the ColorPicker is problematic to use
• Retemplating the whole control would not be that simple, since we need to completely reorganize the layout
• A horizontal ColorPicker may be easier to integrate due to the fact, that most content and screens are wide

Scope

Capability	Priority
Developers have the possibilities to use ColorPickers where height is very limited, but width is not	Must
The ColorPicker has a display mode, similiar to NavigationView where the developer can specify wether it should layout vertically or horizontally	Should

Important Notes

Open Questions

Examples

A standard ColorPicker using Orientation "Vertical"

<muxc:ColorPicker IsAlphaEnabled="True" Orientation="Vertical"/>

Standard ColorPicker using Orientation "Horizontal"

<muxc:ColorPicker IsAlphaEnabled="True" Orientation="Horizontal"/>

Remarks

API Notes

Orientation: The orientation determining wether to display horizontally or vertically.

API Details

[webhosthidden]
unsealed runtimeclass ColorPicker
{
    /// Gets or sets the DisplayMode of the ColorPicker
    Windows.UI.Xaml.Controls.Orientation Orientation = Windows.UI.Xaml.Controls.Orientation.Vertical;
}

[mdtauk]

Maybe the control should be made responsive, so it can re-arrange to fit the space available to it?

Win32:

UWP:

Adobe:

[marcelwgn]

Yes that would definitely be an improvement. Maybe this could also be a setting, just like the NavigationView handles it.

[robloo]

It would also be great if we could re-arrange the RGB/HSV entry text boxes themselves into a horizontal layout. A layout like what is shown below would be ideal to reduce space. That said, I'm pretty sure this was done due to localized text taking up a lot more space -- would be great to have it as an option though.

[jevansaks]

@chingucoding (or anyone else) this seems reasonable to us. The next step would be to propose an API for it and go through the API spec process. In this case it should be as simple as making a markdown file from this template and putting out a PR. Once that's approved then we can greenlight this for implementation.

[mdtauk]

Does something like this make any sense @chingucoding ?

NavigationView.Arrangement = Arrangement.Vertical

• Arrangement.Vertical
• Arrangement.VerticalCompact
• Arrangement.Horizontal
• Arrangement.HorizontalCompact

[marcelwgn]

Does something like this make any sense @chingucoding ?

NavigationView.Arrangement = Arrangement.Vertical

• Arrangement.Vertical
• Arrangement.VerticalCompact
• Arrangement.Horizontal
• Arrangement.HorizontalCompact

Something like this would make sense. However what is "Compact" in this case? There is already a way to achieve compact sizing. Also there should be an "Auto" mode shouldn't it?

[mdtauk]

I would say @robloo 's layout could be compact, maybe "inline" may be better to avoid confusion with the Compact Density.

[marcelwgn]

I think this "inline" mode won't work as some color translations can get lengthy and might overflow. For example: "Xanh dương" is blue in vietnamese. How should this be handled? Should the ColorPicker get wider even though our intent is to save space?

[mdtauk]

I think this "inline" mode won't work as some color translations can get lengthy and might overflow. For example: "Xanh dương" is blue in vietnamese. How should this be handled? Should the ColorPicker get wider even though our intent is to save space?

Inline does not necessarily equate to less space. It is more a declaration of how the constituent parts of the control arrange themselves.