Skip to content

Conversation

@hermitdave
Copy link
Contributor

Added TitleBarExtensions
Added StatusBarExtensions
Added ApplicationViewExtensions
Added documentation for ViewExtensions

Added TitleBarExtensions
Added StatusBarExtensions
Added ApplicationViewExtensions
Added documentation for ViewExtensions
@hermitdave
Copy link
Contributor Author

@timheuer any thoughts on this?

viewHelper:StatusBarExtensions.BackgroundColor="Blue"
viewHelper:StatusBarExtensions.BackgroundOpacity="0.8"
viewHelper:StatusBarExtensions.ForegroundColor="White"
viewHelper:StatusBarExtensions.IsVisible="True"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about binding it to property page? This way we could see live change :)

namespace Microsoft.Toolkit.Uwp.SampleApp.SamplePages
{
/// <summary>
/// An empty page that can be used on its own or navigated to within a Frame.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not required ;)

var greyBrush03 = (Color)Application.Current.Resources["Grey-03"];
var greyBrush01 = (Color)Application.Current.Resources["Grey-01"];

TitleBarExtensions.SetButtonBackgroundColor(this, greyBrush03);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking about a kind of recorder: like TitleBarExtensions.SaveState / restoreState

/// </summary>
/// <param name="obj">The <see cref="DependencyObject"/> typically <see cref="Page"/></param>
/// <returns><see cref="Color"/></returns>
public static Color GetBackgroundColor(DependencyObject obj)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question that applies to all other properties: Why not attached properties? They could be animated or bound then.

@hermitdave
Copy link
Contributor Author

@deltakosh the issue there is that title bar / status bar do not have one to one with Page. There's only one instance and that would be the reason why WP7 status bar did not support binding.

@deltakosh
Copy link
Contributor

Makes sense!

@skendrot
Copy link
Contributor

skendrot commented Mar 6, 2017

Has this been tested with page navigation? I remember a WinRT app I wrote that had issues with page navigation and change titlebar/statusbar properties when navigating back and forth

@hermitdave
Copy link
Contributor Author

@skendrot hence the sample page

@skendrot
Copy link
Contributor

skendrot commented Mar 6, 2017

There is only one sample page. Has it been tested going to another page that does not want any of the properties set?

@hermitdave
Copy link
Contributor Author

Shell and the sample

@hermitdave
Copy link
Contributor Author

I can add it to every child it that helps

@hermitdave
Copy link
Contributor Author

@skendrot design of underlying object is such that once set they remain until changed

/// <summary>
/// Gets a value indicating whether TitleBar is supported or not.
/// </summary>
public static bool IsTitleBarSupported => Windows.Foundation.Metadata.ApiInformation.IsTypePresent("Windows.UI.ViewManagement.ApplicationViewTitleBar");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be ApiInformation.IsTypePresent("Windows.UI.ViewManagement.ApplicationView"))?
Or maybe you missed a .?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pproperty and type don't need to match

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hermitdave Oh. I didn't know that. Thanks for the info.

titleBar.InactiveForegroundColor = value;
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If possible, could you add a property to update ExtendViewIntoTitleBar?

Copy link
Contributor

@Odonno Odonno Mar 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok. I am sorry. I checked again and it is the same class name TitleBar but it is from another namespace. You can find use it in using CoreApplication.GetCurrentView().TitleBar and the class name is CoreApplicationViewTitleBar. It has 5 properties but I generally only use the ExtendViewIntoTitleBar.

@Odonno
Copy link
Contributor

Odonno commented Mar 6, 2017

Another idea. It could be also useful to handle some properties of SystemNavigationManager. I use it often in my apps, it could be a simple property of the Page.

SystemNavigationManager.GetForCurrentView().AppViewBackButtonVisibility = AppViewBackButtonVisibility.Collapsed;

@hermitdave
Copy link
Contributor Author

@Odonno I have exposed 2 more properties..
@deltakosh still want me to tweak things ?

@deltakosh
Copy link
Contributor

I still have several questions unanswered :)

@hermitdave
Copy link
Contributor Author

@deltakosh I am sure you already have the branch and are tweaking stuff as we speak

@Odonno
Copy link
Contributor

Odonno commented Mar 6, 2017

@hermitdave For me, it's really good. If you can add the new properties in the documentation, it will be perfect.

@deltakosh
Copy link
Contributor

No I mean: I have some comments in your code (like the one about property page or the not required comments)
image

@hermitdave
Copy link
Contributor Author

@deltakosh so you want me to remove the bind page and the sample page ? or just the bind ?

@deltakosh
Copy link
Contributor

i want to use the integrated mechanism with IsVisible=[Boolean:True]
And remove the unnecessary comments

Copy link
Contributor

@skendrot skendrot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we name the classes "TitleBar", "StatusBar", etc instead of "StatusBarExtensions", "TitleBarExtensions", etc. This does complicate things for code, but greatly simplifies for xaml.

Should the methods only accept a Page? Right now you could nest the properties into a button if you wanted which wouldn't make sense. Makes more sense to restrict the access to them to a Page

TitleBarExtensions.SetForegroundColor(this, lightGreyBrush);
}

private void Button_Tapped(object sender, Windows.UI.Xaml.Input.TappedRoutedEventArgs e)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this event created/subscribed to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skendrot vestigial code.

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:local="using:Microsoft.Toolkit.Uwp.SampleApp"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:viewHelper="using:Microsoft.Toolkit.Uwp.UI.Extensions"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we change the namespace declaration to viewExtensions or just extensions. "viewHelper" doesn't make sense for the namespace

xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:local="using:Microsoft.Toolkit.Uwp.SampleApp.SamplePages"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
xmlns:viewHelper="using:Microsoft.Toolkit.Uwp.UI.Extensions"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we change the namespace declaration to viewExtensions or just extensions. "viewHelper" doesn't make sense for the namespace

@hermitdave
Copy link
Contributor Author

@skendrot being able to attach them makes sense but that requires attached properties. This is something @deltakosh is keen on though. I might close this PR and someone else can pick it up.

@skendrot
Copy link
Contributor

skendrot commented Mar 8, 2017

@hermitdave Are you referring to this?

Should the methods only accept a Page? Right now you could nest the properties into a button if you wanted which wouldn't make sense. Makes more sense to restrict the access to them to a Page

If so, I'm merely suggesting to change the method parameter you have from DependencyObject to Page.
Example:

public static class StatusBarExtensions
{
    public static Color GetBackgroundColor(Page page)
    {
        ....
    }
    public static void SetBackgroundColor(Page page, Color value)
    {
        ....
    }
}

@hermitdave
Copy link
Contributor Author

@skendrot right you are.. I'll fix the PR if we keep it.

@deltakosh
Copy link
Contributor

We should keep it. it is clearly useful

@hermitdave
Copy link
Contributor Author

I meant we should create a new PR

@deltakosh
Copy link
Contributor

why?

@Odonno
Copy link
Contributor

Odonno commented Mar 8, 2017

@skendrot @hermitdave Yeah. Definitely. If we can remove the "Extensions" suffix in xaml, it could improve the readibility of the code. I mean, not necesary but if that's possible, we should do it.

@deltakosh deltakosh added this to the v1.4 milestone Mar 8, 2017
@deltakosh
Copy link
Contributor

We can merge this one and do a second one for the requested changes if you want @hermitdave :)

@hermitdave
Copy link
Contributor Author

@deltakosh i thought you preferred all properties to be bindable

@hermitdave
Copy link
Contributor Author

That was the only reason for suggesting this PR be closed

@deltakosh
Copy link
Contributor

Oh no I was fine with your explanation.

@hermitdave
Copy link
Contributor Author

I'll push changes tonight

@hermitdave
Copy link
Contributor Author

@skendrot can you review the changes ?

@skendrot
Copy link
Contributor

skendrot commented Mar 9, 2017

I like the new names. Were you going to change the methods to accept Page instead of DependencyObject?

@hermitdave
Copy link
Contributor Author

@skendrot silly me.. Forgot

extensions:StatusBar.BackgroundOpacity="0.8"
extensions:StatusBar.ForegroundColor="White"
extensions:StatusBar.IsVisible="@[IsVisible:Bool:false]"
extensions:StatusBar.IsVisible="@[StatusBar IsVisible:Bool:false]"
Copy link
Contributor

@Odonno Odonno Mar 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hermitdave Why that change? Does it work like that?

Copy link
Contributor Author

@hermitdave hermitdave Mar 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe not!!!

@hermitdave
Copy link
Contributor Author

@Odonno fixed that.. thanks.. should have tested it on mobile as well!!

@hermitdave hermitdave merged commit 057e7a2 into dev Mar 9, 2017
@hermitdave hermitdave deleted the ViewHelpers-HD branch March 9, 2017 18:04
@Odonno
Copy link
Contributor

Odonno commented Mar 9, 2017

@hermitdave Yeah. Great job. I am eager to use it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants