WinAppSDK 1.6 Plans

[codendone]

Planned work for Windows App SDK 1.6 is largely in four focus areas, with the main examples listed for each focus area:

• Quality:

  • Address top issues, including some top control issues, WinAppSDK installer

• Performance:

  • C# Native AOT support, fix some general performance issues

• Better experience:

  • Better TitleBar and tab dragging
  • Better developer experience (such as IntelliSense and x:Bind improvements)

• Progressing in 1.6, but not finishing until 1.7+:

  • TableView, inking controls, and cross-process Islands
  • Smooth app resize

Please use this discussion to provide feedback on these plans, or to provide feedback and up-votes on the next features and issues we should prioritize.

[Natriss]

What is the price tag on the maps control?
I remember something vaguely about costs of x amount tiles rendered.
Is there a way to cap it?
Could you elaborate on that?

[Natriss]

It's still a control in WinUI 3.
Idc if it's native or not. I only care about the price we as developer have to pay.
It's so vague on when you get charged and knowing there is no limit that we can set is a bit scary.

[Natriss]

@codendone could you elaborate on this?

[codendone]

I think you've already found this, but for the benefit of others:

• Pricing - Azure Maps

There isn't a limit, as far as I've heard, but I'll update if I find more.

[Natriss]

Thanks @codendone.
What does MS mean with Base Map Tiles - 5000 free.
What is a tile. Is that a piece of the world map? The world map itself? How big is a tile?
It's also just a fixed number. Does this mean we can only have 5000 free forever or is that renewed daily, weekly, monthly or annually?

[HEIC-to-JPEG-Dev]

The tiles are 512 x 512 (or 256 x 256) - the content of which depends on what you want the map to display, satellite images, road, etc. So your screen view is divided into a tiles of 256 x 256 and each one you populate, costs you 1 tile. Tile counts are renewed each month

[horaciodiez]

ChatGpt wrote:

Dear WinAppSDK Team,

I hope this message finds you well. As I explore the capabilities of WinAppSDK, I've identified a usability concern related to ContentDialogs, especially when utilized for data entry. Due to the fixed positioning, the inability to drag and reposition these dialogs limits their flexibility and prevents users from viewing the content beneath them.
Introducing the option to move ContentDialogs or considering a Dialog-like Window would greatly enhance user experience and address this specific limitation.
I've noticed that even some Blazor libraries already offer similar controls for the web.
I'm eager to know if there are plans or considerations for incorporating this feature in future WinAppSDK releases. Thank you for your time and dedication to the developer community.

Best regards,

Thank You! 😄

[codendone]

Thanks for your feedback, @horaciodiez. Yes, improved dialog capabilities, including those you mention, is something we'd like to make easier and maybe even default.

[horaciodiez]

Hi!
Are there any new bytes on this?

Thank you.

[charlesroddie]

C# Native AOT support, fix some general performance issues

Finally with AOT support we can move from UWP. For us the faster this can come, even in a beta version, the better, as maintaining UWP is preventing us from moving to dotnet8.

[HEIC-to-JPEG-Dev]

I'm going to say no to that hypothasis because WinUI by default does not use the AppContainer. Not using the AppContainer makes WinRT Disk IO a factor of 10 times slower than UWP. Switch on the AppContainer and WinRT IO performs as UWP, but you lose all the .net FileInfo etc and the app is bound by its container.

[sungaila]

Right now you cannot run WinUI 3 inside an AppContainer like UWP. I mean, you can do it, but basic functionality like file/folder pickers won't work.

[lhak]

I would like to see the following experimental features being promoted to stable:

ContentExternalOutputLink class: To enable blending of content with swap chains using directcomposition interop.
DisplayInformation (the dpi related methods): Needed to provide initial window sizing as the XamlRoot dpi methods are not enabled until the window is shown. Alternatively another way to set window sizing in a dpi independent way.

Alternatively, a way to enable experimental features in stable releases would also be beneficial, as the experimental releases lack bugfixes compared to the stable releases.

[dongle-the-gadget]

You can shoehorn the experimental WinMD files into stable (Files uses this). ContentExternalOutputLink is implemented in stable, but you just aren't able to access it without raw ABI or an experimental WinMD file since its metadata has been stripped from the stable WinMD.

[kmgallahan]

On the documentation side:

• Please fix the broken API search function, it has not worked since WASDK had its docs split out from WinUI 2. And by "broken" I mean no results are ever returned: Search isn't working MicrosoftDocs/winapps-winrt-api#6.
• Please update all Visual Studio F1 (go to API docs) to direct to the WASDK API docs. Currently, some go to WASDK (e.g. Page and Grid) and others to WinUI 2 (e.g. NavigationView and InfoBar).
• Please add additional documentation for the available lightweight styles found in Generic.xaml. Only a few are mentioned such as in the NavigationView Guidelines, while the majority require inspecting Generic.xaml to figure out what is available.

[HEIC-to-JPEG-Dev]

Please update the WinAppSDK repository documents - the links still point to version 1.1 as the main roadmap

[duncanmacmichael]

Happy to update the version references - can you point to where you saw any documents still talking about 1.1? The roadmap page currently refers to 1.5 (will be updated soon to 1.6), and none of the other pages in the Docs folder of the repo refer to 1.1, so I'm not sure which documents you're talking about here.

[HEIC-to-JPEG-Dev]

From the WinAppSDK home page, there is a link under Helpful Links - More details about the Windows App SDK

On th epage that opens, there is a section called More Documentation - the link Roadmap + vote on features is where it goes to the wrong roadmap page

[duncanmacmichael]

Ah, that's what you're referring to, like the comment below this one. I went ahead and removed references to that site since we don't plan on using it or updating it anymore, and have redirected to the roadmap page within this repo instead (which we plan on updating for 1.6 soon once we're done processing feedback and finish planning). Thanks!

[james1301]

Why did you stop using this product board: https://portal.productboard.com/winappsdk/1-windows-app-sdk/tabs/2-planned?

This was quite clear what was going on and offered voting which allows the most popular options to be visible. Is there anything else like this I should be looking at?

I would like to try to make use of some of this through XAML Islands for WPF, in an easy way that works well. Not sure what this will look like at present.

Going all in on using Win UI 3: Validation on editors and this issue: microsoft/microsoft-ui-xaml#6299

[ChaimCL]

If I remember correctly, the message was that the person responsible for creating the section left the team and he used a private account to create it, so it was abandoned.

[james1301]

I see, recreating it or something might be good 🙂. And removing links to the old one. It just seems a good way to get numbers on the features that are in demand. Especially now a lot of the fundamental stuff is there now.

[duncanmacmichael]

Thanks for asking this! That site was before my time working on this project so I had to go digging a little bit, and it turns out @ChaimCL is correct. We have no plans to update the site, so I've gone ahead and removed links to it and redirected to the roadmap page within this repo instead (which we plan on updating for 1.6 soon once we've processed all the feedback and are finished planning).

[christosk92]

Any updates on #3305 ?

[kmgallahan]

Please resolve [BUG] XamlTypeInfo.g.cs generates invalid code for types with required or init properties if possible.

I'm sure this issue will give every WinUI developer a headache at some point. ~I just lost a fair amount of time trying to figure out why my builds were failing.

[kmgallahan]

Please stop automatically adding this stuff to csproj files every time a XAML file is added to a project, it hasn't been necessary for a while now and is just garbage to clean up:

    <ItemGroup>
      <None Remove="asdf.xaml" />
    </ItemGroup>

    <ItemGroup>
      <Page Update="asdf.xaml">
        <XamlRuntime>$(DefaultXamlRuntime)</XamlRuntime>
      </Page>
    </ItemGroup>

[MartyIX]

Performance:

* C# Native AOT support, fix some general performance issues

@codendone Is there a plan to improve general performance in the sense that MAUI applications on Windows will be faster? Right now, in the debug mode, I can see that simple WinRT calls take several milliseconds which adds up quickly.

[DarranRowe]

@charlesroddie

Outside an appcontainer it has both poor performance and poor security.

This would actually imply that it has poor performanice in the AppContainer too. Because of how it works, an AppContainer cannot have a positive effect on performance and could only have a negative effect due to potential workarounds. Since an AppContainer at its core is extra security, then it is cannot make code perform better.

@MartyIX
Honestly, there is a lot to say here. But basically, I believe that a packaged application running outside of an AppContainer should never need to use the future access list. A desktop application should run with the same integrity and security levels in a package as it does outside of the package.
Try using System.IO to create and write a file in your user's documents directory without using the picker and without adding any capabilities.

For another example:

    winrt::Windows::Foundation::IAsyncAction MainWindow::Click_Click(winrt::IInspectable const &, winrt::RoutedEventArgs const &)
    {
        wil::unique_hfile test_file;

        test_file.reset(CreateFileA(R"(C:\Users\Darran\Documents\test.txt)", GENERIC_READ | GENERIC_WRITE, 0, nullptr, OPEN_ALWAYS, FILE_ATTRIBUTE_ARCHIVE, nullptr));

        std::string t = "Test File\r\n";
        DWORD written{};
        WriteFile(test_file.get(), t.c_str(), t.size(), &written, nullptr);

        co_return;
    }

If you notice, this code creates/opens a file directly in the user profile's documents directory. This works without issue if the application doesn't run in an AppContainer, but fails if it does run in an AppContainer because the application doesn't have permission to write to documents.
The future access list is also pretty heavy too, so I wouldn't be surprised if it is what's dragging your performance down. Also, Windows.Storage is pretty bad for performance in general.

[MartyIX]

So that's my observation too and I created dotnet/maui#23047 because I found that the future list was/is not necessary to use. If I get it right what you mean.

I just don't get why Windows.Storage is so slow. I'm not sure what it actually does during that 20+ seconds.

[DrusTheAxe]

Windows unpackaged apps typically run with IntegrityLevel=MediumIL, and CreateFile, FindFirstFile, etc directly interact with the target filesystem. Windows apps CAN run with other IL, e.g. High (aka Elevated) and Low. In Win8 'AppContainer' was introduced which, technically, is a separate construct from IL, though when a process runs in an AppContainer it's also running with IL=Low. Although in theory you could have an AppContainer'd process running with other IL it's kinda nonsensical (AC restricts accesses but IL=Medium largely doesn't).

In practice, AppContainer offers Low-er IL experience - more restrictive than LowIL, and much closer to a true 'sandbox' compared to LowIL.

To round out the options there's also Least Privileged AppContainer (LPAC). When AppContainer was created it turns out many Windows APIs wouldn't work as they require access (often readonly but still, access) to many resources. Said resources were ACL'd with an ACE granting access to the ALL_APPLICATION_PACKAGES SID (yeah, maybe not the most accurate of names, just roll with it). AppContainer can be useful for many applications but some scenarios call for a truly no-privilege process, or a handful of specific privileges (depending on the scenario). And thus enters LPAC as an AppContainer but not automatically granted ALL_APPLICATION_PACKAGE.

Package apps have diverse answers, depending on the specifics.

A UWP app is declared in appxmanifest.xml with uap10:RuntimeBehavior="windowsApp".* UWP apps always run in an AppContainer.**

What people commonly refer to as a 'desktop packaged app' or, to be pedantic, uap10:RuntimeBehavior="packagedClassicApp" and years back referred to as 'Desktop Bridge' apps typically run as MediumIL (just like the typical unpackaged app). But they can run in an AppContainer via uap10:TrustLevel="appContainer" and even run elevated.

BTW to round out the options there's uap10:RuntimeBehavior="win32App" which requires uap10:TrustLevel="mediumIL" (AppContainer is not supported) as well as Packaged Services (session-0 service) running as LocalSystem, LocalService or NetworkService. See docs for more details.

Circling back to Windows.Storage and AppContainer vs MediumIL... Windows.Storage goes thru different (and typically more) codepath than CreateFile, FindFirstFile, etc. in large part driven by AppContainer often requiring brokered access to the target resources, where 'brokered' often means another process between the caller and the target resource to enforce the security checks and isolation required by AppContainer.

MediumIL may shortcircuit the brokering codepath to varying degrees, hence the reason Windows.Storage can be faster in a MediumIL process than AppContainer, and why CreateFile etc can be faster still in many cases. Be it Win32 APIs CreateFile, FindFirstFile, etc, or .NET System.IO, CRT APIs (open, fopen, etc), or other equivalents they're typically equal or faster than Windows.Storage APIs and more convenient and natural for your given language.

* Or by declaring EntryPoint other than "windows.fullTrustApplication" or "windows.partialTrustApplication". For more details see https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-application#combinations-of-activation-info-attributes

** There's an exotic exception case to run MediumIL but it's so exotic w can just ignore it for all practical purposes. Exotic, like, I can count all instances on my fingers and keep my shoes on, and maybe one of my gloves too :-)

[HEIC-to-JPEG-Dev]

And yet, there are many instances where Windows.Storage is faster when in an App Container. For example, using the indexer to get properties is 10x faster in the App Container than when not. Run an enumeration of indexed files with cached properties in UWP or WinUI when the trust level is "Partial Trust" and it is 10x faster than running the same code in WinUI when "Full Trust"

[DarranRowe]

And yet, there are many instances where Windows.Storage is faster when in an App Container. For example, using the indexer to get properties is 10x faster in the App Container than when not. Run an enumeration of indexed files with cached properties in UWP or WinUI when the trust level is "Partial Trust" and it is 10x faster than running the same code in WinUI when "Full Trust"

But to make that more fun, there are so many more cases where it is also 10x slower.
One example of this is Windows.Storage.Streams.FileRandomAccessStream.OpenFileAsync takes around twice as long as CreateFile outside of an App Container. But when in an App Container, it takes around 20 times as long as CreateFile, or 10 times longer that itself.

[HEIC-to-JPEG-Dev]

Modify the AppConatiner to allow use of WinRT disk IO and .net FileInfo at the same time. WinRT IO is 10x slower when the AppContainer is in full trust.

[MartyIX]

You are correct, the AppContainer is either on or off for the package. When off (default), WinRT IO is 10x slower but we can use the .Net FileInfo; when it's on, WinRT IO is 10x faster but we lose the .Net features.

How can one test that please? I would love to test this if it can make my MAUI app faster.

btw: There was a discussion here and I have still not found the time to measure stuff but I can see that unmanaged calls take a lot of time from my MAUI app (and not that much is happening imho).

[HEIC-to-JPEG-Dev]

Are you asking how to turn on/off the AppContainer in WinUI, or how to time your code, or what specifically is slow ?

[MartyIX]

Are you asking how to turn on/off the AppContainer in WinUI

Yes. That is my question.

[HEIC-to-JPEG-Dev]

Look at the properties of the app, there is a trust level that can be partial or full

[DarranRowe]

My opinion. I want to write app X using WinUI - WinUI is 10x slower compared to UWP - this is a WinUI problem.

If you use the technology outside of WinUI and you get the same results then it isn't a WinUI issue. Have you tried to package up a regular .NET application and see if the performance is the same when using the WinRT runtime classes?

It doesn't make it a UI framework problem if you observe the behaviour using that framework. This is especially true since anything under the Windows root namespace is completely independent of WinUI 3. This is why I have suggested multiple times to use the Feedback Hub to provide this feedback. Providing the feedback to the correct location seems a lot more productive than mentioning it in a repository of an unrelated SDK.

[HEIC-to-JPEG-Dev]

Update the Visual studio templates to use .net 8/9 - it's still on .net 6

[DarranRowe]

They have been.
At the moment, the lack of the updates for the templates in Visual Studio itself is likely coming from the Visual Studio side of things.

[HEIC-to-JPEG-Dev]

A fix in some GitHub repository doesn't help - if it's not in the tooling (e.g. Visual Studio) it effectively doesn't exits. If it's the VS teaming falling behind then it's the responsibility of the WinAppSDK team to get it published.

[DarranRowe]

Of course.
But if anyone ends up here with the same question, then they know where the updated templates are. They can also manually fix the projects too.

[HEIC-to-JPEG-Dev]

The GitHub repository is not a fix though - it requires an internal MS account to compile. There are also no instructions on what to do; we can't compile the VSIX, so I'm not sure how this helps ?
Of course we can search the internet to find out how to fix the projects, but it has been 4 months since .net 8 was released.

[DarranRowe]

so I'm not sure how this helps

I guess my use of "manually" didn't help.
Two words then. Copy, paste.

With the files being on the repository, you can copy some of the contents of the files there and paste them into your solution. You can update the .csproj, .pubxml and individual source files with any changes.

Now, the IMPORTANT point to note, I am NOT advocating that this is a solution or anything like that. I'm just stating that this is a way to get the new project template contents into a new project now.

[AndrewKeepCoding]

Smaller app folder size would be very welcomed by many devs.
#2478

[AliShahesmaeili]

Native os splash screen like UWP
#500

[SID9-HoneyBee]

Very pleased that the content on inking controls has been updated. I look forward to being able to utilize this feature in version 1.7+

[jingliancui]

https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2022

Support installer for unpackage publish content

[Damix48]

I think that these 2 issues are very important to fix, they are in the microsoft/microsoft-ui-xaml repo:

• Resizable pointer shows up even when a window is maximized microsoft-ui-xaml#8665
• When the app is maximized, the hidden taskbar cannot be triggered. microsoft-ui-xaml#8431

[jp-weber]

For me, the missing designer is the most important feature:
Discussion: WinUI 3.0 XAML Designer. microsoft-ui-xaml#5917

[uixiu]

At least, WinUI developpers deserve a good previewer.

[WindowsNT]

It would help the new APIs like https://learn.microsoft.com/en-us/windows/ai/apis/text-recognition-api-ref could be used in a plain GPU. Very few have a NPU yet.

[harvinders]

@codendone It would be nice to see support for Native AOT for OptionalPackages. We have OptionalPackages loaded at runtime using AssemblyLoadContext.

[Scottj1s]

@harvinders, what specific support are you looking for? Is there some error at build or runtime with PublishAot=true for your optional package?

[ghord]

Any plans for improving transparency support when integrating with DirectX/WebView2? Specifically, I'm taking about this limitation described in https://learn.microsoft.com/en-us/windows/apps/windows-app-sdk/composition:

It's not possible to have compositor content behind external content (that is, behind/below the external layer(s) in the diagram above). So, for example, it's not possible to give a WebView2 a transparent background in order to be able to see XAML buttons or images behind it. The only things that can be behind external content are other external content and the window background. Because of that, we discourage/disable transparency for external content.

Microsoft.UI.Composition is poor replacement for Windows.UI.Composition when you try to integrate multiple different technologies together, as it has huge limitations. One could continue using Windows.UI.Composition still, but it seems it is no longer being updated with new features...

[DarranRowe]

I think they have stated previously that if there was enough demand, they would investigate the issues around the external content and support it natively.
For Windows.UI.Composition not being updated, funnily enough, the Windows composition engine did get an update. DirectComposition was updated with IDCompositionDevice4 and IDCompositionTexture. Windows.UI.Composition was updated with ICompositorInterop2, ICompositonTextureInterop, and the CompositionTexture runtime class. This was also backported to at least 22H2 with the 23H2 feature update.
While it wasn't as widely advertised, the Composition Swapchain was also introduced in Windows 11.
The big thing to remember is that the primitives available through the composition engine are pretty extensive already, what features do you believe that should be introduced in any of the composition engines?

[polaarbear]

Is Drag and Drop finally going to be fixed in MAUI WebViews? It's been broken since launch and reported repeatedly. Was supposed to be fixed in 1.5

[MartyIX]

I created dotnet/maui#22992 yesterday. It should be available on MAUI nightly channel for you to test it.

[WindowsNT]

It would help also if the redistributables are installed with Windows. Why should my app carry the entire dll bundle and why should I install a redistributable. It's 2024 and we have plenty of hard disks. All Win APP SDK binaries should be installed in system32 and the app should specify the version to use, which should be installed at runtime on demand.

[anlexN]

Anybody can question this issues?

[ChaimCL]

It's still too early to wait until it's not too late for them to convert inbox apps like Recorder to WASDK.

[sungaila]

I would love to see more work on WinUI 3 apps running inside an AppContainer. We have an UWP app we would like to migrate to WinUI 3 but most basic things like file pickers won't work.

I think every call that needs a CoreWindow, and uses a HWND in WinUI 3 instead, is broken right now.

[charlesroddie]

Full trust is way more trust than a normal user should give to a 3rd party app. It allows an app access to all user files. That's a ridiculous level of trust. All the main OSes understood that and had sandboxed stores until this WinUI backtracking.

I will find a machine where I can access and upvote the feedback hub issue but really this is about developer technology rather than something that end users will directly understand and report (which is what the feedback hub is about). And I don't think anyone reads that as the half life of windows bugs is over a decade. We need a more urgent way to get this information across since there is currently no way to deliver secure windows apps post UWP.

[DarranRowe]

but really this is about developer technology rather than something that end users will directly understand and report (which is what the feedback hub is about)

This is untrue. The Feedback Hub has the "Developer Platform" category which is for API and tool bug reports. Microsoft has also always had paid support.

[mominshaikhdevs]

all of you, please raise your concerns over here: #219 - AppContainer for Win32 apps and also the win32-app-isolation repo, so that it gets worked on in the Windows OS itself, cause it's an OS level feature.

[charlesroddie]

@charlesroddie As I mentioned in my post, I created a feedback hub issue last year. So the Windows team know about it. But as I also mentioned in my post, nobody has been upvoting this.

I was not able to do this. Clicking on this link gives "Your account doesn't have access to this feedback". This applies to both links you gave. A search in the feedback hub app brings up nothing. I do see a section called Developer Platform and the first 20 posts were all low quality feedback items with no replies. I never saw any reply to a feedback hub post. I don't think this feedback hub is maintained. Let's focus on ways we can actually reach people.

[DarranRowe]

@charlesroddie
Well, there is little else I can say at this point.
Honestly, I'm getting quite tired of fighting this corner in general.

But if I could make a suggestion, to you or maybe anyone else who stumbles across this. Go to the issues of this repository or the microsoft-ui-xaml repository and look for any feature requests for implementing a Windows App SDK version of the pickers. If you find a feature request like that, advertise the heck out of it.
If you don't find one, make one. Do not phrase it as "fix the pickers in Windows.Storage.Pickers". Instead phrase it along the lines of "Since the Windows team is not fixing the pickers in Windows.Storage.Pickers, I request a new set of pickers in Microsoft.Windows.Storage.Pickers that implement the same functionality as the Windows pickers, but work in appcontainers and when running elevated." Once this has been posed, advertise the heck out of that.
This is a request that is actionable by the WAS team. Well, that is all I'm going say on this.

[anlexN]

I am verified google contributor, I have read windows docs step by step, I learn knowledge from Adobe, Amazon, Google, IETF, Microsoft and more. I like to compare those knowledge and shape one knowlege that is good for me. Only by comparison can I discover, Only by comparison can I master.

Based on windows docs, WinForm, WPF, WinRT have been deprecated. C++/WinRT is modern and standard C++, replace WinRT. UWP have not deprecated but legency and it dependent on very old .NET runtime.

Now microsoft focus on WinAppSDK, as you say, WinUI. But WinUI have a very big wrong, it still is XAML + C# (maybe + C/C++) code style. Another meaning, it is not declarative code style like android compose, react, SwiftUI.

Nowadays, the top 3 systems are: Android, IOS/MacOS, Windows. But only Windows is not declarative code style for development. This is a very big Strategic failure for Microsoft. Microsoft is so crazy, oh my god.

I also read many Microsoft repo in the GitHub. Every time, I post a issue. No Microsoft official engineer can reply me in time. So I recommand Microsoft plan some official engineers to solve many and many your github issues in time. Only this can shape a good relationship with community.

C/C++ is amazing, powerful and fast performance, it have many standard and is lead by all global top company. but it have no standard about UI. So I recommand to finish UI work by other language, other work by C/C++. Intuitively, For android, Kotlin + C/C++. For Web, ecmascript + C/C++. For Windows, C# + C/C++. For IOS/MacOS, Swift + C/C++.

Hello Windows team, does team have a plan to follow compose, react, SwiftUI code style? I am looking forward this big and dreamful plan.

I have read many windows source code. For example, windows fluentui web is written by react.

[anlexN]

Your sample shows how to add a WinAppSDK island with Xaml content to a Win32 app.

Your sample still is the business logic and UI file split. But what I need is all (almost) in one. please see official android's jetpack compose tutorial.

Have you tried jetpack compose and SwiftUI to develop apps?

[DarranRowe]

Your sample shows how to add a WinAppSDK island with Xaml content to a Win32 app.

Of course, it is that kind of sample. Which is why I stated:

It would therefore take the same form as what is provided in an official sample.

The use of "take the same form" here is important. This does not mean that it is a sample of what you want to do. What it means is the sample gives an idea of what you would want to do. As one small example, you would remove line 242 and place the explicit control instantiations there.

So again, I feel as if there is a language barrier problem where you are failing to understand some meanings of phrases. I don't feel as if this discussion is constructive as is.

[anlexN]

So it is not official supported windows development way, it is also not mainstream windows development way.

your explanation is something like Jetpack compose and SwiftUI declarative ways, is not equal to Jetpack compose and SwiftUI declarative ways.

I am right.

[DarranRowe]

I think I have finally figured out what the source of this confusion is.
To put it simply, "Official support" does not generally imply written by Microsoft. To give one pretty big UI library as an example, consider Qt. If the Qt group provides support for the Qt library, then this is officially supported. The Qt group, being the official owner of the library, support their product.
Because Windows is an open platform, Microsoft can not, and does not, restrict libraries. So while their own libraries can be classed as "official", this has the weaker meaning of being owned by Microsoft, the same company that owns the platform.

As I stated right at the start of my series of posts, I don't believe what you are looking for is the same as what others are referring to. I believe what you are referring to, and are looking for, is a product that is owned and maintained by Microsoft. In English, this is not what supported means. Support, in software, generally means to allow something to happen, or it means to provide assistance when needed. If what you meant by support was "Microsoft official product", then you are wrong. As mentioned already, using things as previously descrived is supported by Microsoft due to the virtue of it using publicly documented APIs in a documented way. If you really do mean supported in the "Microsoft allows it to happen" sense, then you are wrong.

You would be correct in stating that the only methods of using WinUI 3 without Xaml are based upon methods not provided as a product by Microsoft.

[anlexN]

I hope Windows team can make a plan or roadmap for it.

[supthos]

Yeah! I would like to be able to render text layouts directly to an image with custom fonts loaded at runtime. It seems like you all don't pay too much attention to font matters, or don't care. Is Windows App SDK in serious development or was it just a phase, someone with an utopian ideal and we all just drank the kool aid?

[AliShahesmaeili]

#4613

[sungaila]

My People is no longer being developed. It may be removed in a future update.

https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features

[AliShahesmaeili]

My People is no longer being developed. It may be removed in a future update.

https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features

Yes i know but is there an alternative to it?

[sungaila]

Sadly no, I also miss this feature.

[Apollo199999999]

Any updates on this: #2504? Proper functionality of FileOpenPicker and FolderPicker regardless of whether an app is running as administrator should be basic functionality.

[Balkoth]

Since this is about the UWP pickers, why do you mention the native pickers? I thought the context made it obvious that this was exclusively about the UWP pickers. The pickers exposed through Windows.Storage.Pickers and in some other locations fail when both elevated and when ran in an appcontainer regardless of the presence of the Windows App Runtime.

It is because you did and i did not:

You can get the exact same results without the Windows App SDK being present in a process if you use the various pickers in a Windows API, WinForms or WPF application.

Am i misunderstanding something here?

---

If you were someone working on the Windows pickers, how high a priority would you give this feedback? Now, suppose EVERYONE who was affected by this issue, or the elevation issue, were to upvote this feedback. How many thousands of upvotes do you think it would have? How high a priority do you think it would have then?

Because of code ownership, the WASDK team have previously shown that the best they can do is mark this kind of problem as external and report a bug internally. The Feedback Hub is the place where us developers can add A LOT of weight behind a problem by upvoting an issue. It also matters because usually, only the people who complain are the ones who are heard on this forum. It should be generally much easier to convince people to open an application and click a single button. It is very possible that, in an alternate timeline where the Feedback Hub was used properly, this could have been fixed in Windows 11 22H2 or earlier.

If the system is bad and not accepted, its time to change the system and not the people.

[DarranRowe]

Am i misunderstanding something here?

Most likely my assumption of context by directly responding to a post? Also, from a C++ side of things, only the UWP pickers tend to be described as pickers in the documentation. The older ones are dialogs. There are the older Common Dialog Library and the newer Common Item Dialogs.

It also seems like the C# classes wrapping the Common Dialog Library also refer to them as dialogs.

[mominshaikhdevs]

Since UWPs/CoreWindows are long dead, The
Windows.Storage.Storage* and Windows.Storage.Pickers.*
family APIs won't work as fully as expected.

What we need are replacements of Windows.Storage.Storage* to Microsoft.Windows.Storage.Storage* and
Windows.Storage.Pickers.* to
Microsoft.Windows.Storage.Pickers.* that works -

1. Both in AppContainer and Without AppContainer(MediumIL and HighIL).
2. Gives native/raw win32 APIs Performace and also Supports Multi-threading.

(just like now we have Microsoft.Windows.Storage.ApplicationData as an alternative to Windows.Storage.ApplicationData.)

[DarranRowe]

@mominshaikhdevs
I assume you mean Windows.Storage.Pickers and not Windows.Storage.Storage.

[mominshaikhdevs]

@DarranRowe edited.

[lolametro]

Could you please ensure this regression will not be released in the final 1.6?
Even in the WinUI 3 Gallery app, this is clearly visible after upgrading from 1.5 to 1.6.

WinUI3: ContentDialog is missing entrance animation: microsoft/microsoft-ui-xaml#8476