The aim of this discussion is to compile a list of apps and resources, that are useful for WinUI/UWP developers.
Comment apps and resources you think are helpful, I will add them to this issue!
Shows all of the XAML controls in an interactive format. This app is the interactive companion to the Fluent Design Guidelines and shows the usage of both UWP Xaml APIs and Windows UI Toolkit APIs.
Source code: https://github.com/microsoft/Xaml-Controls-Gallery/
Get the XAML Controls Gallery from the Microsoft Store
Fluent XAML Theme Editor - a tool that helps demonstrate the flexibility of the Fluent Design System as well as supports the app development process by generating XAML markup for our ResourceDictionary framework used in Universal Windows Platform (UWP) applications.
Source code: https://github.com/microsoft/fluent-xaml-theme-editor
Get the Fluent XAML Theme Editor from the Microsoft Store
The Windows Community Toolkit is a collection of helper functions, custom controls, and app services. It simplifies and demonstrates common developer patterns when building experiences for Windows 10.
Source code: https://github.com/windows-toolkit/WindowsCommunityToolkit
View all Windows Community Toolkit projects here: https://aka.ms/wct
Get the Windows Community Toolkit Sample App from the Microsoft Store
XAML Studio, a Microsoft Garage project will help you rapidly prototype UWP XAML that can be easily copied into your app in Visual Studio. XAML Studio lets you preview your XAML code in real-time and interact with the result just like it was running in your own app!
Get the XAML Studio app from the Microsoft Store
Windows Composition Samples the place for getting the latest code samples and demos using Windows.UI.Xaml and Windows.UI.Composition to make beautiful Universal Windows Platform applications.
Source code: https://github.com/microsoft/WindowsCompositionSamples
Get the Windows Composition Samples app from the Microsoft Store
A simple app showing common resources that are needed when developing UWP, such as the Segoe MDL2 icons, system brushes and system colors.
You can download the UWP Resources Gallery now from the Microsoft Store.
A modern, native UWP replacement for the Win32 Character Map and Windows Font Viewer with flawless high DPI and touch support.
Get the Character Map UWP app from the Microsoft Store
Windows Template Studio is a Visual Studio 2017 and 2019 Extension that accelerates the creation of new Universal Windows Platform (UWP) apps using a wizard-based experience. The resulting UWP project is well-formed, readable code that incorporates the latest Windows 10 features while implementing proven patterns and best practices. Sprinkled throughout the generated code we have links Docs, Stack Overflow and blogs to provide useful insights.
Source code: https://github.com/Microsoft/WindowsTemplateStudio
Get the Windows Template Studio extension from the Visual Studio Marketplace
This repo contains the samples that demonstrate the API usage patterns for the Universal Windows Platform (UWP) in the Windows Software Development Kit (SDK) for Windows 10.
Source code: https://github.com/microsoft/Windows-universal-samples
The UWP App Experiences are beautiful, cross device, feature rich and functional app samples built to demonstrate realistic app scenarios on the UWP platform across desktop, Xbox, mobile, and more. Besides being open source on GitHub, each sample is published to the Windows Store for easier access for developers and each is accompanied with at least one blog post and short overview video.
Source code: https://github.com/microsoft/uwp-experiences
This repo showcases a sample Windows 10 application (using the Universal Windows Platform) focused in Line of Business scenarios, showing how to use the latest Windows capabilities in Desktop applications. The sample is based around creating and managing customer, orders, and products for the fictitious company VanArsdel.
Source code: https://github.com/microsoft/InventorySample
VanArsdel is an end-to-end sample built to showcase the Microsoft Fluent Design System as well as other capabilities of the Universal Windows Platform. It allows the user to browse the virtual "store" of lamps that can be organized and decorated.
Get the VanArsdel UWP Sample from the Microsoft Store
Source code: https://github.com/microsoft/VanArsdel
A UWP (Universal Windows Platform) sample app showcasing features useful to enterprise developers, like Azure Active Directory (AAD) authentication, UI controls (including a data grid), Sqlite and SQL Azure database integration, Entity Framework, and cloud API services. The sample is based around creating and managing customer accounts, orders, and products for the fictitious company Contoso.
Source code: https://github.com/Microsoft/Windows-appsample-customers-orders-database
Get the Customers Order Database app from the Microsoft Store
This repo contains a demo UWP app that is built for demostrating rich controls and libraries from Windows UI Library and Windows Community Toolkit.
Source code: https://github.com/microsoft/InsiderDevTourDemos19/tree/master/Sessions/ui
This UWP app was designed to showcase how Fluent Design, Windows Timeline and Adaptive Cards work together on the Windows Developer Day 2018.
Source code: https://github.com/microsoft/WDD-Spring-2018
This repo collects snippets of ready-to-use code that accomplish small but useful tasks of interest to Universal Windows Platform (UWP) app developers. These snippets represent simple solutions to common problems, and simple recipes to help you implement new app features.
Source code: https://github.com/microsoft/Windows-task-snippets
UI for UWP is a suite of 20+ UI controls for developers building UWP applications. It includes a wide range of controls for various application scenarios, including data management, scheduling, layout, editing, navigation, data/geo visualization, and interactivity.
Learn how to build great apps for Windows by experimenting with our samples. These samples show you how features work and help you jumpstart your own Universal Windows Platform (UWP) and classic Windows applications.
Link: https://developer.microsoft.com/en-us/windows/samples
Shows how win32 apps can consume UWP APIs and how UWP apps can use app services to run win32 code among other use cases.
Link: https://stefanwick.com/tag/desktop-bridge/
Thanks so much for putting this together, @chingucoding! We can help keep the description up-to-date as well as people post suggestions.
@chingucoding Just a list of links for now, if you want you can flesh them out with pics (or update the descriptions which I just took from the corresponding github pages) like you've already done with the apps/resources above 😁 (If not, I could also do it, but that would probably be tomorrow at earliest)
Additional apps/resources to check out:
And there are probably still a lot more apps/resources out there which will get added to this issue and which I forgot/am not aware of.
I feel I should also mention:
Thank you @Felix-Dev and @mrlacey for your suggestions! I have updated the issue :)
How do we want to proceed further with this issue?
Thank you @yaichenbaum for this suggestion. I have updated the issue :)
@jesbis @jevansaks @chingucoding In this thread it appears me to some folks would have benefitted from better visibility of this thread (and more in-depth content description - btw, that's not meant as criticism of the nice work you have done here so far, @chingucoding, but just a potential future work item for this topic 🙂). Do we have any plans for this thread here or do we just watch it getting buried under a whole bunch of future issues in the flow of time?
@jesbis @jevansaks @chingucoding It shall soon be more than just creative UI, but how to combine AI with these incredible (especially) 3D UI
@jesbis @jevansaks @chingucoding In this thread it appears me to some folks would have benefitted from better visibility of this thread [...]. Do we have any plans for this thread here or do we just watch it getting buried under a whole bunch of future issues in the flow of time?
@Felix-Dev Sorry for answering on that topic only now 😅
I agree that this issue/thread/discussion would benefit from being pinned or mentioned somewhere. As you already mentioned, as more and more issues are being submitted, this issue will slowly "disappear". Maybe there would also be a better way to handle this topic/discussion than in a GitHub issue. Maybe a separate GitHub repository?
(and more in-depth content description - btw, that's not meant as criticism of the nice work you have done here so far, @chingucoding, but just a potential future work item for this topic 🙂).
Yes, I agree that there should be better content descriptions. I though about what might help, but finding a more helpful description is quite difficult for some entries e.g. what exactly would be an in depth description of the Van Arsdel showcase app?
If you guys have ideas or in depth descriptions that help other developers identify the project that would help them the best, I would love to add them! 😊
I pinned it for now 🙂
@chigy who might have thoughts on including content like this in the documentation.
I'd like to pose a question to the audience. IF we have this information in our documentation set, where would you look for this type of information? How would you search for it? (i.e. search keyword) Do you expect this type of information be given to you in the official documentation set or as a GitHub item like this one?
I am asking this because we are evaluating the effectiveness of our customer storytelling through documentation, samples, or social network, etc.
I'd like to pose a question to the audience. IF we have this information in our documentation set, where would you look for this type of information? How would you search for it? (i.e. search keyword) Do you expect this type of information be given to you in the official documentation set or as a GitHub item like this one?
I am asking this because we are evaluating the effectiveness of our customer storytelling through documentation, samples, or social network, etc.
I think this type of information should be implemented in Visual Studio as a resource.
I'd like to pose a question to the audience. IF we have this information in our documentation set, where would you look for this type of information? How would you search for it? (i.e. search keyword) Do you expect this type of information be given to you in the official documentation set or as a GitHub item like this one?
I am asking this because we are evaluating the effectiveness of our customer storytelling through documentation, samples, or social network, etc.
Ideally I would like references to the respective sample on the pages in the documentation, where I would benefit seeing a real world example. E.g. on the page for Brushes link to the Fluent XAML Theme editor.
But that would be an extremely tedious process, and I don't know if it would be expected by many people there. 😅
I'd like to pose a question to the audience. IF we have this information in our documentation set, where would you look for this type of information? How would you search for it? (i.e. search keyword) Do you expect this type of information be given to you in the official documentation set or as a GitHub item like this one?
I am asking this because we are evaluating the effectiveness of our customer storytelling through documentation, samples, or social network, etc.Ideally I would like references to the respective sample on the pages in the documentation, where I would benefit seeing a real world example. E.g. on the page for Brushes link to the Fluent XAML Theme editor.
But that would be an extremely tedious process, and I don't know if it would be expected by many people there. 😅
@chingucoding , we do add links to apps in appropriate pages. Perhaps we should add more references on the pages that we might have. Feel free to suggest that on each doc pages' feedback mechanism (i.e. "this page") or even better, you could also send us PR!
@shaheedmalik , what do you mean by Visual Studio as a resource? Like template be built into the VS? I was wondering where you would expect this type of compiled best practices pointers to go.
@chingucoding , we do add links to apps in appropriate pages. Perhaps we should add more references on the pages that we might have. Feel free to suggest that on each doc pages' feedback mechanism (i.e. "this page") or even better, you could also send us PR!
Yes, you are right. However it feels like most links point to other pages inside the documentation or the XCG.
None the less, if I find a page, where I know a sample that might be helpful, I will create an issue or PR :)
@chingucoding I think they're talking about the panel that opens up in VS when you start a new UWP project:
@nmetulev @mrlacey do you know how WCT and WTS got in this list? We could talk to the owners about updating the resources/help section.
For docs, I think this is one of the main UWP landing pages: https://docs.microsoft.com/en-us/windows/uwp/get-started/, but it doesn't have a feedback button, though lives here
@nmetulev @mrlacey do you know how WCT and WTS got in this list? We could talk to the owners about updating the resources/help section.
It'll be whoever owns UWP within VS. I'd try Daniel J or Mike H
Since 2012 when UWP was released, I have wanted to migrate our point-of-sale application from WPF. One word prevented that migration; sandbox. I have lived in purgatory for the last 8 years, encouraged by Microsoft to migrate to UWP, but unable to do so. I have been concerned about remaining relevant, I needed the performance that UWP offered but as each of the last 8 years passed, Microsoft still offered no solution.
Now that the WinUI team switched focus to Desktop applications, I am in a position where I can begin the task of migrating all of this WPF to WinUI. Fortunately, I have already migrated the entire codebase from Net Framework to .Net 5.0. I have to be aggressive jumping on the early releases because the last 8 years has seemed like an eternitity.
Due to the Sandboxing of UWP, I never had the need to use a UWP flavor of XAML and for that reason I have zero UWP experience. From what I understand, WinUI is more like UWP than it is WPF. What would be extremely helpful for me and any other WPF expert, would be to have more explicit documentation on how to migrate away from WPF design patterns into those encouraged by WinUI WPF. Although I just began the daunting task of Migrating that XAML, it only took a handful of changes to see that this migration will not be trivial. Having a pre-paved approach for that migration would save me and others from having these surprising moments.
These are the types of surprises that would be good to know ahead of time. It would be great to have examples of do's and don'ts. If you think about it, XAML provides so much flexibility that it gives a newbie the tools he/she needs to re-invent patterns that are already handled. I was reviewing the code of a new WPF developer last week. He re-invented the DataTemplateSelector. I don't want to make those same mistakes as I migrate all of this XAML to the WinUI/UWP'isms.
As I begin to dig deeper I am sure that many of these issues will have simple solutions. Yet the real problem is the fear of the unknown, "what am I getting myself into, measured in effort"? There is no worse feeling than getting 80% through a migration effort only to realize there is one huge gotcha that makes it all a wasted go. Having a well documented approach should have been put together back in 2012 when Microsoft was encouraging us to leave WPF behind to use UWP.
I am excited to move this UI into the future, but more documentation would help reduce the risk that these migrations bring.
@jtbrower that's a great point and list of starting points for a documentation guide.
🦙 @SavoySchuler @stmoy could someone from the WinUI team make this a new separate issue on it's own? I think it'd be a good thing to follow-up on with others as it's own issue?
CC: @anawishnoff who is driving education and awareness.
@michael-hawker thanks for the mention. I am sitting at my desk after a long day of trying to wrap my head around this migration and for the first time in years I feel overwhelmed. I think that its just because I really have no way to define this effort or the extent of it. The biggest "oh man" moment I had today was realizing that there didn't seem to be a way to completely remove the Title Bar / Minimize/Maximize and Window close like you can do in WPF when setting the Window Style. That makes writing a full screen KIOSK app using WinUI impossible unless there is some unpublished way of doing this.
The other issue is that searching for examples or threads that have potential solutions leads to quite a bit of confusion because not only do my old WPF tricks of the trade not work, the UWP examples that I find do not seem to be applicable either. Its not UWP and its not what I know a Desktop app to be either. I can't tell you how happy I would be to be able to fully migrate over. The current effort I am working on intentionally does not have a specific release date so I could take advantage of all the goodness Microsoft offers in .NetCore/Net5 and hopefully that includes the ability to write Visually Appealing/Highly Performant equivalents to anything we can currently do in WPF. If not for the performance gains in UI rendering I wouldn't be taking the risk by moving over to WinUI 3 before it had been released in full.
BTW I just noticed that you created XAML Studio! You did a fantastic job on that tool! I wish the Visual Studio XAML designer performed as well as your tool does. Good job on that!
Edit : After posting the above I stumbled upon some other behavior that I don't think I fully appreciated the first time I read it. On the WinUI release it indicated that
WinUI 3.0 content can only be in one window per process or one ApplicationView per app
That quote was listed under the "Developer Tools" section but if I understand this correctly it has nothing to do with tooling, its more about application architecture. If I cannot have two windows open that use WinUI content then WinUI is out of the question for what I am doing. This would be another great item to add to the list for the migration documentation.
@jtbrower
The biggest "oh man" moment I had today was realizing that there didn't seem to be a way to completely remove the Title Bar / Minimize/Maximize and Window close like you can do in WPF when setting the Window Style. That makes writing a full screen KIOSK app using WinUI impossible unless there is some unpublished way of doing this.
Note that we are currently only in Preview 1 of WinUI 3.0. WinUI Desktop will continue to improve and evolve until WinUI 3.0 ships next year. That includes the Windowing story in WinUI with the spec for the WinUI Window wrapper class still in development.
That said, based on my understanding, it should be possible already to grab the window's handle and use Win32 APIs directly to modify the titlebar's appearance as you've described it. Never done that before so I can't point you here to the APIs to use but you could, for example, check the WPF's .NET Core source code on github for the WindowStyle API and see which Win32 APIs they are using there. Or perhaps a quick StackOverflow search might show up results.
@Felix-Dev thank I do understand its just a pre-release and I certainly took that in to account when I read ahead of time about the missing features in this preview. What makes it really tough for companies that develop extensive, powerful desktop applications, is being stuck in the limbo of WPF. That limbo has been 8 years long and for that reason the last thing any of us wants to do is invest a lot of time and money in a UI technology that will be superseded. I need the performance that UWP/WinUI offers but I also have to be very careful because I am taking a lot of risk.
I can be flexible with my own release schedule so that I avoid the cost of migrating from yet more WPF over to WinUI, but I have to take this risk wisely. As it stands today, I am unable to make a wise decision because there does not exist a public timeline that maps to a set of features. So when I am testing out this preview and find that showing content in more than one window is not supported, removal of titlebar is not supported along with the other long list over here, knowing that this is just preview 1 gives me nothing to plan from because there is no promise that these features will be implemented, am I not right? This doesn't help us much.
So that's why my "oh man" moments leave me feeling uncertain. I have nothing whatsoever to schedule my own effort off of and maybe I'm just not giving the WinUI team enough time to provide previews that are truly ready for desktop development. It did seem like the project went from Alpha to Pre-Release 1 over night if I am not mistaken. I am sure the team was pressured to get something in the publics hands for Build 2020.
I am thankful for the work the developers do, I am just one of you guys excited about .Net while dying for a performant version of XAML for desktop. Cheers
Edit : For anyone seeking the answer to the borderless Window we spoke about above, here it is.
@Felix-Dev you said something that took a moment to sink in. You mentioned that WinUI would be released in 2021 but when I jumped into this preview I had convinced myself that the release date was 2020. To make sure I wasn't losing my mind I pulled up the wayback machine and indeed this history from June 14th stated that the release date was planned for 2020. I am glad you mentioned "next year" or I would have continued to assume this year.
I can be flexible with my own release schedule so that I avoid the cost of migrating from yet more WPF over to WinUI, but I have to take this risk wisely. As it stands today, I am unable to make a wise decision because there does not exist a public timeline that maps to a set of features. So when I am testing out this preview and find that showing content in more than one window is not supported, removal of titlebar is not supported along with the other long list over here, knowing that this is just preview 1 gives me nothing to plan from because there is no promise that these features will be implemented, am I not right? This doesn't help us much.
@jtbrower
Indeed, a more detailed roadmap for WinUI 3.0 covering the specific features being worked on to be shipped with the WinUI 3.0 release (and those features/APIs which might won't make it into WinUI 3.0 but will only arrive in later releases) doesn't yet seem to have been made available in one compact place here in the repo. In the February WinUI Community Call @jesbis briefly previewed a more detailed WinUI 3.0 roadmap which you can see here (it's already outdated in certain aspects like SwapChainPanel). I'm not sure where the thinking inside the team right now stands about publishing such a roadmap on this repo and refresh it every month, as @jesbis mentioned as a possibility.
The effort required for WinUI 3.0 by the team is absolutely massive. Not only does the team have to decouple "thousands" of existing internal Windows APIs and make them ready for WinUI 3.0 - they also have to focus on Win32 support with WinUI Desktop which is another challening and time consuming task. WinUI Desktop also means the team needs to work on packaged vs unpackaged app support which also appears to be a considerable challenge. There are even more high-level tasks being worked on internally besides the ones I've listed but it should give you a good overview just how huge this WinUI 3,0 effort is.
The complexity of this project always meant that internal priorities for WinUI 3.0 might shift and some features have to be cutted for its release, perhaps making the team thus reluctant to share a more detailed roadmap where they might end up promising features for the initial WinUI 3.0 release they could end up having to cut later in the development process of WinUI. Enter the COVID-19 pandemic now and this is without a doubt creating even more uncertainty for the team. As you noticed, the COVID-19 situation already contributed significantly to a WinUI 3.0 release delay by multiple months.
That said, I do think in certain aspects it would help developers interested in adopting WinUI 3.0 if some more details could be shared - take for the example the WinUI windowing spec. While it was said this is an evolving spec, nothing much has been going on over there for over two months now. Seeing as the Windowing story seems to be quite important to the community (How easily can something be achieved? What API abstractions will be provided over the underlying Win32 APIs?....). I would certainly welcome it if @marb2000 could share with us an update on the Windowing story in WinUI in the upcoming weeks.
@Felix-Dev thank you again for another thoughtful and rapid response. Make no mistake, although I would love the excitement that comes with an extensive refactoring effort like WinUI, I do have a tremendous amount of respect for the challenge the team is facing while being open to the public. This is actually something that I have reflected on many times; that is the evolution of Microsoft going open source. On one hand it gives all of us developers the transparency that we have probably begged Microsoft for over the years. With a microscopic level of scrutiny, men and women like myself have a direct channel of communication with your teams via github. Although it benefits both parties, I have never been in a situation where my teams source code and issue tracking was wide open to the public before the project really moved into motion let alone prior to the first production release. I don't want to miss the opportunity to thank everyone for your part in keeping we third parties informed. I have a lot of respect for you all.
Regarding the transparency that Microsoft has adopted, from a third parties point of view, its easy for us to lose focus on our own efforts because we have the exact transparency that we asked for. In the case of WinUI, from the first WinUI community call I listened to, I felt like any time spent with WPF was time wasted. If Microsoft wasn't transparent and WinUI existed only as an internal project, I am sure I would have continued to pound out WPF code accepting the fact that it may not render at the speeds I hoped for but it certainly does a great job of giving me the tools I need to make a beautiful and maintainable application.
With that said I can appreciate the hesitancy in making the internal schedule visible to the public. However, I think the "cats already out of the bag". Companies and developers like myself read a WinUI announcement that states
We're planning to release WinUI 3 via a series of preview releases throughout 2020, with a production-ready preview in November
and then read between the lines that it was moved forward, the impact is the same as giving us a granular schedule that also slipped. So being more transparent about features and schedules doesn't really disrupt external companies any more than a generic schedule does it? Though it definitely causes the WinUI team more headaches and we all want the team to remain as focused as possible.
I have started a repo that follows the popular Awesome format of other repos.
@scottkuhl Good deal, thanks for sharing.
Most helpful comment
I pinned it for now 🙂
@chigy who might have thoughts on including content like this in the documentation.