Discussion: Create open-source implementations of comctl32 controls

[wjk]

The Windows common controls are still the backbone of many Windows apps. However, there are a number of pain points I’ve found over the years using the comctl32 controls:

• The common controls have a very specific high-DPI theming behavior (the sizes of the bitmaps increase, but the thicknesses of the lines do not). I do not like this behavior, as it makes details in the bitmaps harder to see as the DPI scaling increases, especially if you do not have 20/20 vision.
• The comctl32 list view supports collapsing groups and having action links in group headers. However, these controls have an unusual location (right side of the group header), don’t DPI-scale well, and do not match the look of the equivalent controls in Windows File Explorer.
• There is a bug in the tree-view control wherein the expansion triangles stay 16x16 physical pixels even on high-DPI monitors. (I can workaround this by setting a blank image list in the control; if I do so, then the triangles become large enough to see and click, but there are then also large blank spaces to the left of every item label).

There have been requests that a library be developed that wraps WinUI 3 controls in an API-compatible replacement for comctl32, so that apps can begin to use the Fluent Design look-and-feel without having to rewrite large parts of their existing UI code. There is a large amount of overlap between that request and this one. However, I personally still prefer the "Windows 7" look-and-feel for my apps, rather than the WinUI 3 one. The best way to accomplish this currently is to use APIs (such as comctl32 and uxtheme) that were developed in the Vista/7 era, but neglected since then. It would be even better if I could use the Windows 7-era bitmaps for controls (push buttons and whatnot), as I find the “flat” look and feel of Windows 10 to be bland and uninspired.

Due to the nature of comctl32 and uxtheme, only the Windows team can fix these issues, but they have never shown any interest in doing so. The spirit of Project Reunion is, as I understand it, to take features that would be implemented in Windows core and split them off so they can be open-sourced and maintained independently of the OS (where the architecture allows for it, cf #16). Therefore, I suggest creating an open-source implementation of the comctl32 controls that fix the above issues and allow for more expansion in the future. (This does not necessarily have to be based on the OS code. Using the OS code as a starting point would be cool and obviate the need to recreate everything; however, I know how reticent Microsoft is to release parts of that repo to the public, even in cases such as these.)

[mdtauk]

With WinForms being a modern wrapper around Windows Controls - and WinUI looking to be a modern replacement UI - is there a need for the Common Controls of Win32?

I wonder what future there could/should be for the Common Controls, MFC controls, etc.

[sylveon]

WinForms only works with C#, but Common Controls are usable from within C++ or other languages and are still frequently used (including within Windows itself). Discarding requests from developers not using C# makes me feel unwelcome in here.

Here are various examples of apps based on Common Controls only, none of them written in C#: https://github.com/pbatard/rufus https://github.com/TranslucentTB/TranslucentTB https://github.com/processhacker/processhacker https://github.com/Maximus5/ConEmu

[mdtauk]

It would be good if the MSStyles which control the theming and colorisation of common controls, could be made to function on a per app basis - at the API level - and if neither of those are implemented, drop back down to the OS theming.

These MSStyles should respond to OS settings like:

• Light
• Dark
• Accent Colour
• High Contrast

App developers would provide resources and visual assets for each of the supported OS themes - and when the OS setting is changed, the app is re-drawn using the new local assets.

Reunion could provide a set of default assets, given tweaks to make them fit nicer with WinUI control designs, and Fluent Design - so all apps which opt into Reunion - could use these if they wish, or choose to provide their own, or use the OS defaults.

[driver1998]

WinForms is a .NET warpper on top of user32 and comctl32, it also has these issues.

On the other side, comctl32 controls are by definition based on GDI, and have a lot of GDI related APIs, think owner draw buttons for example. We clearly don't want GDI running on WinUI .(so a compatibility layer for GDI as well?)

[mdtauk]

WinForms is a .NET warpper on top of user32 and comctl32, it also has these issues.

On the other side, comctl32 controls are by definition based on GDI, and have a lot of GDI related APIs, think owner draw buttons for example. We clearly don't want GDI running on WinUI .(so a compatibility layer for GDI as well?)

WinUI and GDI are separate, and I don't think GDI will be wrapped. This is more about copying the code for the Common Controls from Win32, into an open repository - and allowing modifications/bugfixes/etc.

Not sure if the control's GDI rendering can be separated from the logic code - but it could be an interesting idea to build a DirectX/OpenGL renderer to replace GDI

[davidcorbin-atmosera]

Chasing down a major problem - and this would have been a life saver. Code written back at the dawn of MFC is still in use, and probably will be for a decade or more from this point.