feat(controls): Add `TitleBar` CenterContent property

[luca-domenichini]

This PR is fix for #1483 It adds a CenterContent DependencyProperty and a new column in the Grid of TitleBar, making developer able to put content in the center area of the titlebar.

Moreover, with HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}" we make developer able to align the centered area more precisely, to the left, center or right edge.

Pull request type

Please check the type of change your PR introduces:

• [ ] Update
• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, renaming)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] Documentation content changes

What is the current behavior?

Currently there are few, less obvious alternatives.

Issue Number: #1483

What is the new behavior?

Devs are now able to put content directly in the centered area of the title bar.

[luca-domenichini]

Hi @pomianowski , is there something more I can do to make this PR go ahead? Maybe I could ask for @Nuklon review, since I see he is probably the most active dev on this repo?

[apachezy]

I had also used the same approach to allow user content in the center of the title bar, but I realized it might be a temporary workaround and didn't submit a PR.

Later, I found that changing the HorizontalAlignment of the TrailingContent to Stretch would allow users to freely place content (left, center, or right), because:

<Grid.ColumnDefinitions>
    <ColumnDefinition Width="Auto" /> <!-- Title text or other header content -->
    <ColumnDefinition Width="*" /> <!-- TrailingContent!!!!!!!!!!! -->
    <ColumnDefinition Width="Auto" /> <!-- System buttons -->
</Grid.ColumnDefinitions>

The column where TrailingContent resides has a width of "*", but its HorizontalAlignment was set to Right. This is not reasonable — even though the remaining space is fully available, users were forced to align their content to the "right".

Changing it to Stretch is both logical and user-friendly, as it allows content to utilize the full available space. Why not do it?

Moreover, this method requires minimal changes, especially since no modifications are needed in the HwndSourceHook. This also means minimal burden for reviewers.

Back then, I wasn't very familiar with the PR process. I once accidentally included this change in a PR, but it was rejected — haha!

[luca-domenichini]

I think your arguments are valuable. Thanks for adding your point of view ⭐ Let's hope for a review by the maintainers! ⭐

[luca-domenichini]

@apachezy thumb up the PR if you want to push it further 👍

[apachezy]

So I suggest adopting the "TrailingContent.HorizontalAlignment = Stretch" approach, mark the TrailingContent property as obsolete, introduce a new property (e.g., "RemainingSpaceContent") to replace it, and then internally link TrailingContent to this new property.

This way, the changes required are minimal. It avoids cluttering TitleBar with too many "Content" properties, while still meeting the requirements. Why not go for it?

[apachezy]

I'll wait for your new solution to be implemented, and I'll give you a ton of likes for it! 👍

[luca-domenichini]

hmm.. I think having just a new center property will not break existing applications. Changing the existing one as you suggest, also could break them. My PR just add new content where previously there was nothing, so existing stuff should still work. If we change the existing to Stretch I fear many users would be affected.. am I wrong?

[apachezy]

Hmm... I think this is just part of the natural process of software iteration. Changing the TrailingContent.HorizontalAlignment property would only have the effect of making content that was originally right-aligned appear "distributed". Once developers notice this, they'll realize: "Haha, now I can place content anywhere I want!"

[luca-domenichini]

I see your point, for a brand new library would make more sense, and yes, for me would not be a problem since I'm making the PR and I would naturally adapt my code as well.

Though, I think the kind of change you are suggesting should be approved by maintainers more carefully, and since I want this PR to go fast without breaking anyone.. well.. let's wait for @pomianowski to react to your points.

Repeating myself: for me would be OK with your proposal. Just curious about owner directions.

[apachezy]

I feel that there are still some unresolved concerns in the current TitleBar implementation, particularly regarding the combination of WPF techniques and the Windows message–based approach.

While it seems to be working correctly right now, this is largely thanks to the accumulated efforts of multiple contributors.

I expect that more focused refinements will be needed in the future, so at this stage, I think it makes sense to achieve the required functionality with minimal changes.