8.0 Release Plan 📝

[michael-hawker]

Latest info on Pre-release blog here https://devblogs.microsoft.com/ifdef-windows/windows-community-toolkit-8-0-pre-release/

Read more about our whole 2022 Release Plan summary on the discussion here.

Before we start looking at our full 8.0 release, we're re-working our infrastructure for the toolkit. Read all about the new Toolkit Labs for Windows coming first here.

H1 2023 - 8.0 Release – Create/Rename Windows Community Toolkit Repo to CommunityToolkit/Windows

• Leverage new tooling/improvements for project structure/samples/documentation/testing from Toolkit Labs for Windows.
• Maintain a single branch for all platform targets (e.g. UWP and WinUI 3)
• Ship all targeted platforms in a single NuGet package and namespace under CommunityToolkit.WinUI.*
  • Simplifies documentation and samples across platforms
  • Enables library and app developers to multi-target platforms and share XAML
  • Aids in transitions from UWP to WinUI 3 in the long-term.
• Seeded with code from our existing winui branch.
• Rename or Archive existing CommunityToolkit/WindowsCommunityToolkit repo when migration is completed.

Details

We are currently maintaining two separate branches of the toolkit, one for UWP and one for WinUI 3/Windows App SDK. This has been done manually and isn't sustainable. We want to take our learnings on creating our new infrastructure with Toolkit Labs for Windows and apply that to our existing code-base to streamline development of the Toolkit moving forward.

First, we would setup a CommunityToolkit/Windows repository that merges the project structure and updates to our processes from Toolkit Labs for Windows with our existing winui code branch. This would involve a lot of effort but also allow us to revitalize our samples and docs for specific features at the same time. It also makes it easier for a developer to focus on specific area within the Toolkit without having to load every Toolkit project or control.

Second, by moving to the new systems in CommunityToolkit/Windows, we would target all platforms within our single CommunityToolkit.WinUI.* based packages and namespaces for both UWP and WinUI 3.

This not only will help streamline our documentation and samples, but make it easier for developers to consume and multi-target XAML for UWP and WinUI 3 in their applications. Library developers can also do the same when building components on top of the Toolkit. We know migrating namespaces is a challenge, however, this incremental step makes migration between UWP and WinUI 3 easier for existing projects in the future as well.

Finally, we would rename or archive the existing CommunityToolkit/WindowsCommunityToolkit repo once the transition has been finalized. This repo would remain to preserve the history of our migration from UWP to a multi-targeted library. The new CommunityToolkit/Windows repo would be pruned to only preserve up-to the conversion from UWP to WinUI 3 (if possible).

Secondary Goals

In addition to the large goals of our releases above in re-working our infrastructure, other work on our samples and docs would need to be done as well. We would investigate if we could bring each Toolkit area over in chunks to re-work each area over time vs. trying to accomplish a giant move in one go. Hopefully this would also allow us to parallelize the work and engage any community members willing to aid in improving our samples and documentation for existing features.

Beyond infrastructure, there are new controls and components that have been worked on already or are already in development. The rest of this issue links out to existing known work that is being developed to track what needs to be migrated or incorporated into the plans above.

Issue Breakdown for 8.0 Release

Milestone
Feature Board
Bug Board
Technical Board
Sample Board

Below is a summary of the top level plan items. These items are in addition to everything that was initially released with the preview.

Legend of annotations:

Symbol	Description
✋	Help Wanted
0️⃣	priority 0 - must have for this release
1️⃣	priority 1 - nice to have for this release
2️⃣	priority 2 - stretch goal - unlikely for this release but we will try our best
❕	missing issue reference
🔦	investigating

Windows Community Toolkit Repo Refactor

These items will track what is required to initialize and setup the new infrastructure with the existing codebase.

• TODO, this needs to be populated after we create infrastructure with Toolkit Labs for Windows.

Book-keeping

• Finalize ColorCode Migration/Transition (Waiting on Legal) - Relicense Project to MIT ColorCode-Universal#20
• 🔦 Discussion: Do we revamp our branding/icons? [Feature request] Modernizing the WCT Sample App icon #3182

Refactors

• 0️⃣ GridSplitter clean-up Redesign of GridSplitter API #2976 (PR 🚧 SizerBase class for GridSplitter + new ContentSizer and PropertySizer components #4083)
• 1️⃣ AdaptiveGridView samples to migrate to ItemsRepeater and deprecate
• 1️⃣ Clean-up control styles to expose a named Default Style (otherwise it's hard to inherit properly - see TokenizingTextBox/PeoplePicker)

New Features

• 0️⃣ TransitionHelper for Animations [Feature] A animation helper that morphs between two controls #4323/PR A animation helper that morphs between two controls #4338
• 0️⃣ InfoBar StackedNotificationsBehavior [Feature] Prevent InAppNotification from disappearing when hovered #4194/PR InfoBar StackedNotificationsBehavior #4399
• 0️⃣ Settings Controls (Labs 🧪 [Experiment] SettingsCard & SettingsExpander Labs-Windows#216)
• 0️⃣ ResourceString Markup Extension Adding ResourceString Markup Extension  #4319
• 0️⃣ ContentSizer (as part of GridSplitter refactor above) Redesign of GridSplitter API #2976 (PR 🚧 SizerBase class for GridSplitter + new ContentSizer and PropertySizer components #4083)
• 0️⃣ PropertySizer (as part of GridSplitter refactor above) Allow app users to resize NavigationView's Pane microsoft/microsoft-ui-xaml#190 (PR 🚧 SizerBase class for GridSplitter + new ContentSizer and PropertySizer components #4083)
• ✋ 2️⃣ AdvancedCollectionView Improvements AdvancedCollectionView part deux #1128
• ✋ 2️⃣ RotatorTile OnCurrentItemChanging Event [Feature]RotatorTile OnCurrentItemChanging #2994
• ✋ 2️⃣ Gaze Input Cursor Color [Feature] Add GazeInput.SetCursorBrush method to change the default GazeCursor color #3210

Bugs

• 🔦 Investigate main bugs to call out we want to prioritize here above others.
• 0️⃣ Performance Option for AttachedShadow Improving performance of AttachedCardShadow by clipping inner content via CompositionMaskBrush #4410/PR Clip inner content from AttachedCardShadow using CompositionMaskBrush #4404
• 0️⃣ Relative Ancestor FrameworkElementExtensions.Ancestor causes an XAML memory leak Windows#107/PR Unregister the Loaded event in Relative Ancestor #4322
• Infinite Canvas

Migration Notes

• Improve tests for expressions see Fixed expression nodes created with custom param names incorrectly clearing during internal cleanup #4756

[Shomnipotence]

Will it get a new icon?

[michael-hawker]

Will it get a new icon?

Possibly, there has been discussion on this topic in the past #3182. As we get closer to setting a release date for 8.0, it's definitely something we should consider. Thanks for reminding us!

[Nirmal4G]

The namespace for Community Toolkit for Windows with CommunityToolkit.WinUI is too restrictive for what it enables or represents. I propose we move to CommunityToolkit.Windows!

I also have some ideas about repo structure that might not require heavy refactoring when and if we rebrand in the future.

[robloo]

I would like to add back DropShadowPanel and not deprecate it. The dev experience with this control is far superior to the new ideas in AttachedDropShadow which are just wrapping the implementation in composition (which is also poorly designed and doesn't fit in with XAML). AttachedCardShadow is slightly better but missing a lot of properties to control the look.

[Arlodotexe]

The namespace for Community Toolkit for Windows with CommunityToolkit.WinUI is too restrictive for what it enables or represents. I propose we move to CommunityToolkit.Windows!

Plans included supporting WinUI on other platforms, not just Windows, so using WinUI would be more appropriate.

[Nirmal4G]

Okay. But WinUI still represents Windows UI! Also, CommunityToolkit.WinUI.UI is more visually confusing at a glance. It's disturbing (to look at) to say the least.

May be CommunityToolkit.UI.Xaml would be a better alternative…?