Modern FontDialog and ColorDialog

[JaiganeshKumaran]

Proposal: Modern FontDialog and ColorDialog

Today Windows provides a FontDialog and a ColorDialog which are used by many apps however they don't have a modern UI and don't look Fluent. Also, they don't work in UWP apps so this for desktop apps only.

Summary

I'm proposing updated versions of these dialogs which use Fluent design and work with any kind of Windows app including UWP and is universal. For easier access, they could also be wrapped in a Windows Runtime API.

Rationale

• Many apps rely on these features and this will help modernize that
• Consistent experience. Many apps want a simple way to pick fonts or colours. However, these old dialogs won't work under UWP apps and are currently for desktop apps only.

Scope

Capability	Priority
This proposal will allow developers to use FontDialog or ColorDialog from a UWP app or desktop app with great Fluent design styling	Must

[andrewleader]

Transferring this to the WinUI 3 / XAML team as this is a UI/XAML related ask, thanks Jaiganesh!

[mdtauk]

Can you provide details of the Win32 APIs responsible for system colour and font pickers.

@andrewleader I think this should be a Reunion ask, providing @Jaiganeshkumaran is detailed about what APIs you want wrapped in a Reunion WinRT implementation.

WinUI would be used to create the UI for these dialogs, but it is Reunion level IMO

[mdtauk]

Here is some documentation on the Windows common dialogs @ranjeshj https://docs.microsoft.com/en-us/windows/win32/uxguide/win-common-dlg

Whilst WinUI 3 could be used to design the new dialogs, I think it would have to be Reunion which handles the display of the newer modern versions, and fallback to the legacy ones where appropriate, say with Windows 8.1

[JaiganeshKumaran]

These dialogs are part of the system and not WinUI. A newer version could be built using WinUI 3 (eg: the color dialog can use the color picker control) however the new one should be available for all apps using the API without any change and not just WinUI 3 apps.

[sylveon]

I don't think any design change can easily be retrofitted since these dialogs can be customized by the developer, in a way that effectively binds them to Win32. For newer apps, something like the WCT's ColorPickerButton could be translated to C++ and added to WinUI.

[mdtauk]

I don't think any design change can easily be retrofitted since these dialogs can be customized by the developer, in a way that effectively binds them to Win32. For newer apps, something like the WCT's ColorPickerButton could be translated to C++ and added to WinUI.

Developers are always free to roll their own dialogs of course, but there was a proposal/discussion in the Reunion repo about modernising the File/Folder Open/Save dialogs. And it was explored how these could be customised. https://github.com/microsoft/ProjectReunion/pull/99

https://github.com/microsoft/ProjectReunion/issues/88 I submitted some design ideas to the discussion

[sylveon]

I'm not saying the replacements shouldn't be customizable, I'm saying the way existing dialogs are customized makes it near impossible to use any new color/font picker on existing apps, because it will break the developer's customizations.

[mdtauk]

I'm not saying the replacements shouldn't be customizable, I'm saying the way existing dialogs are customized makes it near impossible to use any new color/font picker on existing apps, because it will break the developer's customizations.

Reunion does plan to use polyfills and shims to bring new APIs to existing devs.

As Reunion would be an opt in, the developer adding Reunion to their existing app, will be able to evaluate it. It would also help the Windows Win32 Inbox apps update their UI and keep their code behind. Apps like Wordpad, Notepad, Paint, etc

[sylveon]

I should clarify, nearly impossible to retrofit without code changes. The old pickers won't be going away for compatibility reasons.

[mdtauk]

I should clarify, nearly impossible to retrofit without code changes. The old pickers won't be going away for compatibility reasons.

Yea that's an unfortunate reality, and the OS team can only make so many changes to these legacy dialogs without breaking apps.

But choosing to use Reunion, should move usage of these old APIs into the new versions with minimal changes, so that means "reading" the supported customisations, and bubbling them into the new versions.

The OS shell and inbox apps, should use them as an incentive to other developers.

[sylveon]

I doubt that would work either, the customization API is pretty solidly Win32. It makes uses of dialog templates, WndProc hooks, etc. Dialog templates define how Win32 controls are laid out, which window styles they use, etc. It might be translatable to XAML but it would take a lot of effort.

WndProc hooks has the client code take complete control of how the dialog behaves, draws, etc, all using Win32 APIs. That outright can't be replicated in XAML

[mdtauk]

I doubt that would work either, the customization API is pretty solidly Win32. It makes uses of dialog templates, WndProc hooks, etc. Dialog templates define how Win32 controls are laid out, which window styles they use, etc. It might be translatable to XAML but it would take a lot of effort.

WndProc hooks has the client code take complete control of how the dialog behaves, draws, etc, all using Win32 APIs. That outright can't be replicated in XAML

It should be documented the limitations of opting into the reunion dialogs.

Some customisation such as additional CheckBoxes, TextBoxes, etc could be translatable. But visual styles and custom window Chrome would and should not be supported.

Many times modifications made to these are aesthetic, and the modern dialogs should look nice enough, to not want to modify it.

For any other customisation, beyond setting colours and brushes, then they can still drop back down to the legacy versions.

[sylveon]

Almost any additional checkbox/textbox involves a WndProc hook (because those are implemented through window procedures in classical Win32) and therefore can't be translated. There's also more to WndProc hooking than just visual appearance customization and new controls, other dialog behavior can also be changed at will. If we're gonna make users pay the price of needing to change code, might as well go all the way and devise a new API without weird backward compat knudges.

[mdtauk]

Almost any additional checkbox/textbox involves a WndProc hook (because those are implemented through window procedures in classical Win32) and therefore can't be translated. There's also more to WndProc hooking than just visual appearance customization and new controls, other dialog behavior can also be changed at will. If we're gonna make users pay the price of needing to change code, might as well go all the way and devise a new API without weird backward compat knudges.

Well I am pretty much suggesting that. A new API, and new Xaml based UI.

If developers want more than just additional CheckBoxes and input fields, then they will have to do it the legacy way.

If they currently customise their common dialogs, then if the new API reduces code and still allows them the extra bits they need, they can choose to adopt it.

This new API would be supported on all universal platforms, so Xbox, Teams, Holographic etc

[ranjeshj]

These dialogs are not part of WinUI as mentioned earlier. @SavoySchuler could you help route this request ? @chigy as FYI

[LeftTwixWand]

Hi. There is a cool color picker In the XAML Controls Gallery. I propose to use it as the base for the future modern component.