🧪 [Experiment] SizerBase class for GridSplitter + ContentSizer + PropertySizer

[michael-hawker]

Approved from Discussion #96

Problem Statement (copied from Discussion):

We have various types of experience which need 'gripper bars' in order to provide a user with the ability to resize/drag an area of UI around in an application. These all have similar visual and behavior cues, but may require different logic to manipulate the underlying UI structure.

Overview

This experiment adds the following components:

• SizerBase an abstract base class to centralize logic around input, visuals, and accessibility.
• GridSplitter knows how to manipulate a Grid's rows/columns
• ContentSizer knows how to manipulate the Width/Height of any FrameworkElement
• PropertySizer knows how to directly manipulate any bound double value

Using

You can try it out via the NuGet Packages here:

• UWP: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-MainLatest/NuGet/CommunityToolkit.Uwp.Controls.Sizers
• WinUI 3: https://dev.azure.com/dotnet/CommunityToolkit/_artifacts/feed/CommunityToolkit-MainLatest/NuGet/CommunityToolkit.WinUI.Controls.Sizers

Read more about Preview Packages here.

This control has moved from Labs to the new main repo.

CommunityToolkit members can also try it out with Codespaces.

TO DO

Preview Give feedback

1. Fix Mouse Extension Cursor change for WASM (was working at one point, think messed up conditional logic again) See Added manually defined required compilations constants #208
2. Add some enum/bool for auto hiding the splitter and having it appear on hover (think size should be consistent, so just an animation?)
3. WinUI 3 may behave oddly - see WinUI3 - ManipulationStarting Event only occurs on first touch -> e.Container Property is null in following manipulation events microsoft/microsoft-ui-xaml#6847
4. Orientation Property [SizerBase] Orientation and Cursor not set correctly #388

Not all these items are required to submit a PR. This list is here to help track what is remaining to implement before a technical review and discussion of moving into the main repository can occur.

Implementation Requirements

Preview Give feedback

1. Working Prototype
2. Feature Complete
3. Documentation
4. SizerBase
5. ContentSizer
6. PropertySizer
7. GridSplitter
8. Samples
9. SizerBase
10. ContentSizer
11. PropertySizer
12. GridSplitter
13. Tests
14. Community Feedback / Usage Testimonies

Tested Platforms

Preview Give feedback

1. UWP
2. WinAppSDK / WinUI 3
3. Web Assembly (WASM)
4. Android
5. iOS
6. MacOS
7. Linux / GTK

These items can sometimes be done ahead of time, but are usually started and completed after all implementation details are finished.

Technical Review

Preview Give feedback

1. Accessibility Audit
2. API/Naming Review
3. Code Quality/Style
4. Dependency Review
5. Design/Style Review
6. Final Approval

[michael-hawker]

Couple of things I've noticed, looks like I broke the WASM hover implementation again... and we should investigate an auto-collapse behavior mode too.

[michael-hawker]

Figured out what was going on with the cursor not properly updating when the Orientation is Horizontal (like in the sample) - regression from current Toolkit version.

It's this code here:

Labs-Windows/labs/SizerBase/src/SizerBase.Properties.cs

Lines 98 to 110 in 9045236

	var cursor = gripper.ReadLocalValue(CursorProperty);
	if (cursor == DependencyProperty.UnsetValue || cursor == null)
	{
	cursor = cursorToUse;
	// On UWP, we use the extension in XAML to control this behavior,
	// so we'll update it here (and maintain binding).
	// We'll keep it in-sync to maintain behavior for WinUI 3 as well.
	gripper.SetValue(CursorProperty, cursor);
	// We return here, as the Cursor will trigger this function again anyway to set for WinUI 3
	return;
	}

Since we set the value of the dependency property, when the initial pass run on load sets it to SizeWestEast. Then the detection logic runs and Orientation is changed to Horizontal, but the set gets ignored the 2nd time as the prop has been set...

Think this was abstracted in the old code as the inner class held that info.

Here, I think we need to just have the private value tracking what the cursor should be and leave the Cursor property for overrides? Will think about it more and get back to it as a separate fix.

Effects UWP and WASM (basically WinUI 2), Windows App SDK uses a different setup, so I think is uneffected.

[michael-hawker]

Behavior for WindowsAppSDK is looking good now on 1.3, will push a PR up shortly, also trying to fix the Cursor orientation bug number #388.

[alexfalconflores]

The styling of this control in UWP does not look the same as the styling of WASM or the toolkitlabs.dev page.
In the UWP version it shows an old design.

UWP (xmlns:labs="using:CommunityToolkit.Labs.WinUI" )

toolkitlabs.dev

[michael-hawker]

@alexfalconflores are you using the new package (CommunityToolkit.Uwp.Controls.Sizers) from the Windows repo?

[alexfalconflores]

I'm using this

https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-MainLatest/nuget/v3/index.json

[niels9001]

I'm using this

https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-MainLatest/nuget/v3/index.json

@alexfalconflores Looks like you are using the Sizers from Labs.. we have recently moved these to the main Toolkit and made any updates there.

So, instead of using CommunityToolkit.Labs.Uwp.Sizers use the CommunityToolkit.Uwp.Sizers package.. it's on the same preview Nuget feed!

[alexfalconflores]

Thanks for the help @niels9001 and @michael-hawker. The new control design looks great. Keep it up.

Do you know when UWP will support .net 7 or 8?

CommunityToolkit.Uwp.Controls.Sizers . nuget prerelease

[michael-hawker]

Do you know when UWP will support .net 7 or 8?

@alexfalconflores see discussions here and here - if you need the latest .NET then you'd want to port to WinUI 3 (which is what we're making all our components work with both to make it easy to do). If you just need newer language features for C#, look at PolySharp.

[michael-hawker]

This was shipped in the 8.0 Release, please update to use that version of the component. Any further issues/requests should start in the main repository.

[Fabi12345]

So I always have to point the cursor to the center of that splitter despite it requires the whole space along the container? And the normal GridSplitter belongs to a deprecated package, but has no hover function, sigh, WinUI has become a mess.

[niels9001]

So I always have to point the cursor to the center of that splitter despite it requires the whole space along the container? And the normal GridSplitter belongs to a deprecated package, but has no hover function, sigh, WinUI has become a mess.

@Fabi12345 This issue is closed, so it might not reflect the latest changes.

• You do not have to point at the center.. you can point anywhere on the control.

Recording.2024-10-24.160306.mp4

• GridSplitter belongs to the Windows Community Toolkit 8.x packages. Those are not deprecated at all: https://www.nuget.org/packages/CommunityToolkit.WinUI.Controls.Sizers

• What do you mean with 'hover function'? There's a hover state in the sizer controls in case you want to customize that!

You can install the Windows Community Gallery app from the Store here, it has all of the information you'd need: https://www.microsoft.com/store/productId/9NBLGGH4TLCQ

[Fabi12345]

Oh ok, that looks better, gonna try it, thanks!