Re-usable Window template

[MichelMichels]

I'll write a reusable template from your code to package in a nuget package for better usability.

[sygmond]

I'll write a reusable template from your code to package in a nuget package for better usability.

Can you give me more details about this? Sound interesting to be able to (re)use this and update it via nuget and not having to keep track of the changes when you implement it in your own project, but I'm not very familiar with it.

[MichelMichels]

Yes, I will try to set something up as soon as possible. In essence, it will be a Control derived from Window with a style applied.

[sygmond]

That would contain the whole project or just the xaml part? Looking forward to see it :)

[MichelMichels]

It would contain the whole project with various editable parts. I'm trying to put something together on an experimental branch to show you, but didn't yet complete it yesterday.

[MichelMichels]

@sygmond I started an experimental branch which contains a rough start for the control: https://github.com/sygmond/WindowChromeMultiscreen/tree/exp-001.

I also added the possibility to add some controls in the center of the titlebar.

[MichelMichels]

See the projects WindowChromeMultiscreen and WindowChromeMultiscreen.Demo. This is very much WIP.

[MichelMichels]

Signing of for tonight. I'll try to finish it tomorrow.

[sygmond]

On one of my production app I added a company logo on the left side before "Title" and after "Title" I added a menu aligned to the left. The whole goal of this project is in fac to enable us full control over the window design like logo, title menus and buttons in the titlebar.

A control between Title and minimize button is a very good addition indeed.

Probably another control/logo placeholder would be nice before Title.

Most of the apps are designed like that: logo, title, menus, close buttons.

[MichelMichels]

I was planning to add another control before the title 😄
Atm I'm just abstracting the work you did already, will get to the icon part soon.

[MichelMichels]

@sygmond if you find the time, you can checkout the branch exp-001. I made all your initial work into a custom control called CustomChromeWindow.

It contains multiple customizable areas:

• BeforeTitleArea - This can contain multiple controls that use the horizontal StackPanel layout
• AfterTitleArea - Same like above
• CenterArea - Same like above but is vertically centered on the window and atm will overflow into title and button area if too wide

The naming of everthing is temporary a can obviously be renamed. This was mostly a POC.

PS: Jot library is not supported at moment of writing

[sygmond]

I will take a look this evening. We have the same local time.

[sygmond]

@MichelMichels I'm sadly very limited in time because I'm wrestling with my few months old child most of my non-existing free time. On top of that, it passed two years from last time I worked on a WPF project, that making it difficult to remember some stuff. Takes some time till you get back on track.

That being said, I took a look at the code and I can say that I never used templates like that in WPF, and I mean with "PART_" and the Attributes, but I've seen it being used in libraries like Telerik.

I followed the code and I kind of gasped the usability of it and it looks interesting.

I can't say or comment much about the implementation because "PART_" templating is not my strongest knowledge (yet 😁).

I did some small refactoring to play with it, even if it's a POC 😋.

I go with the flow and see where it goes. Anyway, its not written in stone and things can be adapted later.

One thing that I noticed is the titlebar search box overlapping with the title right side area. In general I prefer Grid instead of StackPanel because I have more control over UI and responsiveness.

P.S. Probably would be a good idea to add an .editorconfig with some code conventions that I usually use on daily basis and build on that.

[MichelMichels]

No problem man! I understand the struggle, having a nearly 2 year old kid myself 😄.

I understand your issue with the CenterArea panel. I mentioned it earlier that it is overlapping at the moment. I did this because I wanted it to be centered on the Window, regardless of the contents left and right, and I only know 2 methods to achieve this:

1. The method I use at the moment, but more refined to limit the width of the CenterArea by monitoring the sizes of the left and right elements
2. Using a grid and using stars width on the left and right column while using 'auto for the center'

[MichelMichels]

I'd like to hear your thoughts about naming the several added properties, and the naming of the window control itself. Do you have any ideas to change this? Or do you like the naming I used?

[sygmond]

I think that the window control has the right name CustomChromeWindow considering that the native name is ChromeWindow.
As far as I've seen, the properties have also a good naming, but I will double check once I get there after cherry-pick-ing your commits.

I have to think about CenterArea and what exactly refers to. If the meaning is about the area between the title and minimize button, allowing someone to add some buttons in there or a menu, aligned to left, center or right, then the CenterArea is fine.

But... if the CenterArea is about an area that is always aligned to the center of the title bar... I don't see the practicability of it. Usually after Icon and Title comes a menu and/or buttons aligned on the left side, not in the middle. These buttons or menu would go all the way to the end just before minimize, maximize and close buttons. A CenterArea aligned to center would only be useful as a Title, if someone wants to put the name of the app in the middle instead of on the left. But that would invalidate the usability of having menu/buttons on the title bar, or would have to put them on the left, kind of weird.

Currently I'm working on moving your commits without losing their author and file commit history, to a new branch dev because in the POC exp-01 branch everything that was in the WindowChromeMultiscreen.UI project was copied in the CustomChromeWindow Control project, invalidating all files git history.
I prefer going step by step and renaming the WindowChromeMultiscreen.UI to WindowChromeMultiscreen and then recreating the WindowChromeMultiscreen.UI and moving back from WindowChromeMultiscreen what is not needed anymore (AppState, etc.).
This way all files keep their changes history because git will know what was renamed in what.

[sygmond]

@MichelMichels I didn't forget about your good work, I have a WIP where I add all your changes from exp-01. Just need some time to finish it.

[MichelMichels]

@MichelMichels I didn't forget about your good work, I have a WIP where I add all your changes from exp-01. Just need some time to finish it.

No problem!

In the meantime, I'm experimenting in my own repository over at github.com/MichelMichels/wpf-controls to try out some ideas. We can port that over once you're ready.