Template10: Discussion: remove Custom Title Bar
My plan now is to remove the Custom Title Bar feature of Template 10 because it basically caters to the Windows Phone. I realize it is NOT in the Mobile Extension SDK, but still, can anyone argue to leave it?
JerryNixon
All 6 comments
Nope, no argument here. I am not really concerned with windows mobile now, moved to over to android recently but uwp is still a focus for development. Don't think I really used it any way with mobile site.
mvermef
on 3 Sep 2017
Wouldn't a Custom Title Bar be useful for handling changing the windowing title bar? The bits that change the Status Bar colours, could be deprecated, but not removed. Its not as if the API surface will change much. And who knows what Windowing and Shell changes will come to cShell which this control could be useful for?
mdtauk
on 3 Sep 2017
While I agree that cShell will probably bring changes are, we actually sure that MS will attempt another push into 'mobile' again, that won't fail, the guy/gal above knows that I wanted Windows Mobile (Phone) to succeed.
Unfortunately, over the many iterations from windows phone 7 (att focus), being an early adopter from windows mobile 6.5, to what it's not now, future proofing a control for something we have no evidence of said device appearing.
At least not any indications past rs2_feature branch the directions would take since this branch is effectively the last for the 950's at least that is my guess. That anything past this would not be supported. Loved my 950xl but eco-system is nothing compared to play store, when was the last time you saw a new product have windows in their mobile cycle
mvermef
on 3 Sep 2017
Not in this form, but I'd like to see the custom title bar in another form. It would be cool, if the control would be 'hidden" and we manipulate the title bar only with XAML, like https://marcominerva.wordpress.com/2015/05/19/easily-manage-the-title-bar-in-windows-10-apps/
jp-weber
on 4 Sep 2017
I might write a service to handle it, optional, external.
JerryNixon
on 6 Sep 2017
Doing it as a control could allow you to place it onto the page, where it contains the TextBlock that can act as the title, host a back button, become the hit-target for a customised TitleBar, and calculate and set it's own height based on the value the API puts out.
I can understand if it no longer includes the mobile Status Bar elements like colours, control of the progress bar, and text element, as well as setting itself as the occluded rectangle height to ensure elements on the page do not appear beneath it. As mobile is essentially dead.
A use case would be to enable an app to use a background fluent Acrylic brush, extend into the TitleBar area, so it too uses Acrylic - but still have the back button, and window title label. Without having the dev do it in code.
mdtauk
on 6 Sep 2017
Related issues
marcinmarkiewicz
路
9Comments
resolutedreamer
路
4Comments
HesamKashefi
路
6Comments
mjmeans
路
10Comments
Joebeazelman
路
5Comments
Most helpful comment
Doing it as a control could allow you to place it onto the page, where it contains the TextBlock that can act as the title, host a back button, become the hit-target for a customised TitleBar, and calculate and set it's own height based on the value the API puts out.
I can understand if it no longer includes the mobile Status Bar elements like colours, control of the progress bar, and text element, as well as setting itself as the occluded rectangle height to ensure elements on the page do not appear beneath it. As mobile is essentially dead.
A use case would be to enable an app to use a background fluent Acrylic brush, extend into the TitleBar area, so it too uses Acrylic - but still have the back button, and window title label. Without having the dev do it in code.