I think that Xamarin will merge into .NET 5;
It would be great if they adopt the UWP XAML as the standard and work from there on, Microsoft and UNO making it the best for Desktop, Mobile, Web Browser (Azure) and IoT.
They could call it
UWP vNext (WinUI based)/ Silverlight 6 (UNO)

I think that the Blazor effort was a first step bringing .NET officially to the WebBrowser, using its current default rendering, ie. the HTML DOM
But I believe that soon they can even offer another rendering Engine, a lightweight complement for WinUI, something orbiting Silverlight, UNO Platform and Xamarin... like Flutter / WPF

It would be great if they adopt the UWP XAML as the standard and work from there on

Everything you guys want is already happening with Uno. MS would be wise to buy those guys out and then hire them to shepherd along the final development of Uno.

This is probably the wrong place to request a feature like this. As much I would like to agree to everything in this request, I believe the WinUI team and a lot of senior dev in the Windows community hold WinUI to be defined very narrowly.

In an ideal world, WinUI would just be like Material Design. There will be ways to have it in any platform with all kinds of library that implements it. However, WinUI is not a design language, and so is not Fluent Design. Microsoft not being in the model space has made their UI offering behind the competition by quite a lot.

WinUI is a UI library for Windows applications, and this is as clear as it gets. The design language is not separate from the implementation, and the implementation is platform exclusive because of features like composition rely heavily on the platform dependency. This is bad in the perspective of a mobile/cross platform dev, but the effort here is for Windows apps really.

This is also why probably Uno Platform can never truly be WinUI everywhere, not unless they port DX 11 to every platform.

I would suggest you to look into Comet(cross platform dev framework based on .Net). It's in its early stage, but the concept is not unlike Flutter. It too uses Skia(as an option) to draw the UI with a composable/declarative UI pattern, so devs can implement UI libraries like Material Design and have it look completely the same on every platform.

No it shouldn't be cross-platform. It's called Windows UI for a reason. Let's just get a UI system that works across all of Windows (platforms and languages) to start with hey? That hasn't even been achieved yet. We are still split between .net framework, .net core, uwp, and then the C++ story, which at least has uwp, but no game dev's use it, because UWP/WinRT still has some issues - distribution, forced taskbar & titlebar popups when in fullscreen (yikes).

Thinking about cross-platform would be a colossal waste of resources. Get it right on Windows first please. And get .net 5 out the door, and fix UWP and the windowing story, and put DirectX onto C#. And fix the GC. There is still so much to do in the narrow scenario, just on Windows.

And to the OP.

• UWP is universal. To say it's not universal is a false claim (they never meant to target Android, thank god). The original promise has been delivered. All Windows devices run UWP. Windows Mobile was a separate OS, they had to get rid of it. All new Windows platforms will be Windows (10 or 10X). Eventually based on CoreOS I suppose. And they will all run Windows applications. Just because we don't have a Windows phone at the moment is incidental. We have all the other device types. And we'll have Neo and Duo soon.

• Sandbox restrictions - These are good things. Win32 style system-wide access should be stamped out in general. If you have a specific requirement, you should put forward your requirement so that we can discuss how it could/should be done inside a UWP container and if you should be allowed to do it the way you are suggesting. And work out if UWP needs that feature. Because I can think of some advanced applications that could be written in UWP no problem. I can has program! You need to discuss specifics.

• .net native is being replaced and the distribution story will change with .net 5. I think it's fair to say that Microsoft are working on this. Surely they know of the issues. But you should file specific issues to target the real underlying problems here.

• "Don't couple WinUI to DirectX" - WTF? It absolutely should be coupled with DirectX, that is the native Windows graphics stack. Please don't even consider anything else. I absolutely do not want to come across OpenGL rendering surfaces under the hood. That would break compatibility and cause all sorts of mayhem.

@Gavin-Williams

Wonderful, let's make a slightly evolutionary upgrade over WPF.

UWP is universal

"All Windows devices run UWP" means nothing without mobile. HoloLens is niche, Surface Hub is niche, Windows 10 IoT Core is a joke.

It absolutely should be coupled with DirectX

As a developer, hard coupling gives me goosebumps. Is there any major reason why the graphics stack cannot be interchanged?

It's called "modularity". Microsoft has always struggled with that.

Sandbox restrictions are good things

Yes, they are, as long has they don't severely limit the range of applications that can be built. Have you tried to resize a partition from UWP?

I think it's worth mentioning and reminding that Google is developing Flutter and they are not calling it GoogleUI or AndroidUI. It works everywhere -- even on the web and desktop. I state this as there seems to be a propensity to "just get it working on Windows" but if another competitive offering exists that is cheaper, faster, easier to use, AND works on Windows + everything else... what will the developers (and corresponding market) choose? I can tell you as a small business owner that I know where I am putting my investment given the two choices.

Porting DirectX to other platforms seems a vaste work, maybe the solution is to use OpenGL or Vulkan instead of DirectX

@Gavin-Williams, I don't know if you are familiar with UWP, but when you build/distribute you target a specific version (or version range) of Windows. That idea is absolutely coupled, and one of the reasons why UWP didn't go as mainstream as WPF did.
@nerocui the whole purpose of a UI language is to de-couple the UI design from the raw drawing in a screen. That's why you see HTML being able to render in ARM/x64/x64.

XAML provides an outstanding abstraction of the UI primitives/composition/animation, the request makes absolute sense because of development cost and platform reach.

I respectfully disagree with @SuperJMN. Certainly, UWP has not yet attained feature parity with WPF. Despite it’s limitations as a framework for building kernel level tooling, for virtually every other software development task, with the right capabilities specified in the app manifest, you have a much better user experience from multiple perspectives (security, ease of deployment, install/uninstall experience, etc.). The security sandbox of UWP is an important (essential) feature. In many respects UWP is now well ahead of WPF.

The UWP .Net compiler eliminates the need for code obfuscation and the instability this can introduce to WPF. Performance has the prospect of improving over time without code changes as the compiler is improved. UWP itself has a much better design in terms of how it leverages DirectX and other system level resources. It also has a huge advantage over WPF when integrating with other languages, C++ in particular. Integrating high performance C++ components with C# is trivial under UWP. Access to DirectX surfaces is also much improved.

The remaining holes in UWP can easily be plugged. I would argue the bigger problem has been Microsoft’s failure in attaining the quality level that was associated with WPF. WPF just worked. Microsoft also failed to recognize the critical importance of LOB requirements like a Data Grid, INotifyDataErrorInfo, controls that feature validation states, and a robust DB out of the box. Most of these have been addressed, but it took too long. Non-rectangular regions are sill missing.

The other critical failure rests with certain WPF developers that have opted to stay away from UWP. Adoption is essential to building momentum. However, the adoption saga is understandable given how many times Microsoft has waffled on its initiatives. It’s obvious Microsoft is waffling once again. Resurrecting WPF by allowing it to plug into UWP UI services seems cool on the surface, but it does distract from making UWP solid.

I completely agree with @SuperJMN’s assertion that developers have lost hope Microsoft will do the right thing. The right thing does differ depending what sort of software you are building. If it’s high performance LOB applications that need to be created quickly and exhibit a broad set of capabilities while being safe and easy to install, UWP is mostly there except in terms of quality. That quality gap is what’s killing UWP more than anything else.

HTML+JS is the cross-platform solution of the day. We don’t need to re-invent it. Having a high perf XAML rendering engine on IOS and Android makes more sense if the intent is to make XAML more portable.

I very much agree that WinUI should aim to be cross-platform in the future. Here are some further thoughts.

Immediate priorities

I agree with some of the comments that the immediate priority should be ensuring WinUI 3 works on Windows with .Net 5 integration and that bugs are fixed. However, if it is not already too late, when making architectural decisions, the aim of being cross-platform in the future should be considered.

Why WinUI should be cross-platform

There are the obvious and most important reasons - developers want to target the largest audience possible without rewriting code etc, and C# (or C++ I suppose)/XAML is a nice combination. Without a cross-platform story they will move to other technologies like Flutter.

Another reason is to ensure that WinUI continues to be supported by Microsoft. Microsoft is only likely to continue supporting WinUI if their own apps are using it. They are increasingly focused on making their own apps cross-platform. It's true that some cross-platform frameworks such as React Native and Xamarin will use WinUI underneath, but what happens if other frameworks such as Flutter or browser-based rendering win out? Then WinUI will become redundant and will go into maintenance mode like WPF.

How should cross-platform be implemented

Although Uno is a great project, in my opinion it makes more sense to make the render (and input) layer cross-platform and build on that, which is what Flutter and AvaloniaUI do, rather than wrapping native controls. There are several advantages to the approach of making the render and input layers cross-platform. It seems to me that the API surface of the render and input layers is smaller than that of the controls (but I suppose it depends on whether you build controls on top of a few base ones etc). Secondly, if you rely on wrapping native controls then you are at the mercy of the platform. If they change their API you have to change yours or implement a work-around. If you don't do this quickly enough upon deprecations, your framework will break. If you want to add a new feature to a control you may have to implement it for each platform. You can't really have a 'vision' of how you want your framework to evolve because you are tied to the platform frameworks. Also it requires devs to test on each platform all the time as the look and behaviour of controls are different. Also, it would be difficult/impossible to implement more powerful features like the composition layer. Making the render layer cross-platform solves all these issues, and if you want a different look on each platform then you can add a different style. (I admit that, some behaviours, you would keep different on different platforms, such as scrolling on a Mac!).

Since WinUI is currently decoupling the controls and render and input layers from the platform, it seems in a uniquely well-placed position to do this.

One way to abstract the render layer would be to use Skia. However, I wouldn't want performance to suffer by forcing this abstraction. I have an alternative suggestion to look at for abstracting the render layer, which is the C++ proposal for 2D graphics - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf. They have obviously put a lot of work into the API surface and it seems pretty comprehensive. They argue that the 'problem' of 2D graphics was essentially solved many years ago and I have to agree with them that their API surface seems pretty complete. There are a lot of people against this proposal, but even if it doesn't get accepted I think the API surface could be used. If you write a Direct2D back-end for this API surface, then if the proposal gets accepted it will save the MSVC team from having to write it. Maybe the WinUI team could use this as justification for being allowed to work on it or adding some extra team members. Also, perhaps the authors of the paper would be willing to help. You could write the back-end for the other platforms using Skia or something and if the proposal eventually gets accepted then switch to the native implementations when they are made.

Finally, looking further into the future I wanted to mention WASI - https://wasi.dev/. This seems focused on systems programming for now, but it might have the potential to turn into a fully-fledged cross-platform app framework (it has cross-platform and security built in), with the above C++ proposal perhaps providing a natural candidate for the rendering layer API. (This is likely very far off though).

Looking at the evidence, folks like @SuperJMN have a lot of credibility given the content of thier repositories. I can see @SuperJMN probably gave up on UWP while it was still maturing (understandable). Microsoft would do well to review the repositories of folks commenting here. Some voices aren't particularly credible based on the body of work they present to the world.

@Noemata I used to be a huge XAML+MVVM fan. I've worked with it in Silverlight, WPF, WindowsPhone, Metro(WinRT). I burned out when it came to UWP and Xamarin ...

It's hard to see what separates this iteration vs. all of the other times I've looked at a new XAML stack.

Microsoft has put out some fantastic UWP sample apps. They really do showcase nicely what's possible.

Here's a partial list:

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

There are many more fine examples. None are built in a manner that is easily re-purposed or structured so the samples are cohesive with other works.

I don't recall nearly as much effort with corresponding WPF samples. This is mostly good.

The problem? It took too long to get to where we are now with UWP and XAML. And now the message is once again muddled. Had Microsoft merely provided decent project templates with Visual Studio when UWP was first released we'd be less negative about UWP. For the best VS templates you have to go here:

https://github.com/microsoft/windowsTemplateStudio

Not exactly out of the box despite being a very flexible and complete set of building blocks for UWP apps. How do you find all of this? No clue. Going on a treasure hunt to do your job doesn't build confidence. The Office Team refusing to adopt WinRT didn't help. They drive a lot of what goes into the OS irrespective of their theoretical arms length reach. Throw in quality issues, bugs, the failure of Windows Phone and inconsistent investement plus messaging and here we are.

Microsoft has put out some fantastic UWP sample apps. They really do showcase nicely what's possible.

@Noemata I agree, they really cool samples. But developing a complex app is insane, using UWP. It's certainly possible, but it's a lot harder. Yes, I do miss the WPF's "it just works" times.

One of the first things MS should give as a sample is a simple UWP app that that you can publish outside the MS store (and yes, it's not as easy as you'd think)

Another thing that does not sit well with me is that UWP was thought of with the "mobile first" in mind, ditching the right Desktop experience.

Correct me if I'm wrong, but most developers use UWP to develop Desktop apps, and the UI does not match that. First thing that comes to mind is the scrollbar - which, from the get go is optimized for touchpad. But for users the desktops , the scroll experience is very bad (side note: I think the WinUI team is working on fixing this). I've googled quite a lot to find a solution that will make the scrollbar "normal" again -- it's simply insane that I can't just call an API function to do that.

Same, the radio buttons/combo boxes have a min size also optimized for mobile. Simply setting the Width of a radio button is ignored, you actually need to set "MinWidth=0" for it to be taken into account.

And the text button color is white, then black on focus -- what's up with that? And the text button has an "x" you can use to clear it - that's touchpad - why do i have it there when there's no touchpad?

The default text box has spelling enabled -- why would I want that?

There are other issues, but I've worked around them. But the biggest problem is that things that should take 10 minutes, usually take 2 hours or more. And there are a LOT of issues like that. I've simply lost the ability to estimate - whenever I say something will take me half a day, it will take me 2-3 days. And it's kinda' depressing.

Greetings everybody,
as this is a general discussion issue and I don't know where else to place my UWP wishes/ feature requests..... I take the opportunity in this thread:

• Better support for integrating uwp apps into the contextmenu of windows explorer
  
  
  
  • Please support us here https://aka.ms/AA6rmrk
  
  
• UWP Markup Extension missing IServiceProvider, and the element itself on which the Markup Extension is used
• UWP Style Trigger missing
• UWP implicit data templates issue. See for example here
• no automatic printing possible without user interaction (works only for POS) see here

All above features or issues were addressed on uservoice which is now abandoned. Does anybody know what happend with those issues? Should we recreate them on feedbackhub?

Love the phrase "The Forgotten Developers". I know lots of them who are talented, experienced, passionate about technologies. They are veteran .Net developers. I have no doubt they, generally speaking, can make better apps than many kids who thrive on app development for iOS and Android.
If WinUI can provide a pleasant and robust path for them to utilize their extensive experience in C# + .Net + Xaml to make apps for Windows, Android, iOS and Web, many will jump on the wagon and the world will benefit from their high-quality apps.
WinUI + Uno Platform could be the ultimate call.

UWP Markup Extension missing IServiceProvider, and the element itself on which the Markup Extension is used

Got you covered here @mfe- !

Got you covered here @mfe- !

@Mike-EE Wow, that's awesome! I remember running into this when I wanted to port CalcBinding to UWP. What I ended up doing is a workaround where I add readonly fields in the view model.

"write once, run everywhere".

Microsoft moved away from this a while back.

Nice work all WE'RE FAMOUS! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

The Forgotten Developers are silent or just ignored

Love the phrase "The Forgotten Developers".

Let's organize under that name! 💪

I just wish for a cross-platform UI framework developed and supported by Microsoft. There is just nothing for the .NET ecosystem out there except for _Uno Platform_ and _Xamarin.Forms_ (if they are still working on targeting the desktop).

And even if I decide write a Windows-only business application from scratch, I do not believe that Microsoft fully commited to UWP. Correct me if I am wrong but didn't they abandon the Office UWP apps in favor of the Office Online PWAs? If MS ditches their own first-party framework then why should I trust in UWP? _cough Silverlight_

Thankfully WPF was not abandoned yet. But that only adds to my doubts.

Nice work all WE'RE FAMOUS! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Holly 🤭

Super! Let's expand to other big journals, web sites, etc 😛

For those seeking a cross platform solution for developing apps, you need look no further than Unity:

https://unity.com/

Like all such solutions, you wind up with a framework that encompasses a mini operating system. Java was the operating system cleverly disguised as a programming language.

A modern browser is now a mini OS. I think we have enough of these. WinUI/UWP is supposed to be the native UI for Windows 10 and onward. It might make sense to have a XAML engine that runs in more places. I'm not convinced that would fly against the head wind of things like Unity. I'd rather see a polished, high quality UWP before Microsoft goes off and starts re-inventing Silverlight so we can host XAML on other platforms. We all know how well that worked out. If you haven't looked at Unity, you're missing out. That said, be prepared to do lots of coding and even more debugging.

Next week I'll release a set of VS Templates for UWP that let you create apps in seconds. This has been used for "internal" projects. It will prove the point that UWP can be a RAD framework out of the box if only VS had the right building blocks built in.

Next week I'll release a set of VS Templates for UWP that let you create apps in seconds. This has been used for "internal" projects. It will prove the point that UWP can be a RAD framework out of the box if only VS had the right building blocks built in.

@Noemata That sounds cool! I'm quite curious!

If you all want a .Net based, cross platform UI framework that can adapt to any design language. Look no further, Comet is it.

https://github.com/Clancey/Comet

If you have some spare time, go contribute since it's still at its early stages.
Comet targets basically all platform in existence, and it gives you the choice to target native control in each platform or use Skia to draw everything so they are all consistent(exactly how Flutter does it).

It uses declarative UI and MVU pattern. It's developed by James Clancey, a Principal Program Manager Architect at Microsoft. Although it's not officially supported yet, but with enough community traction, it can be.

In Comet, UI is just a library, so you(or maybe Microsoft can) can develop a WinUI library just like how Comet has a Material Design library.

If you all want a .Net based, cross platform UI framework that can adapt to any design language. Look no further, Comet is it.

@nerocui this sounds cool, but at least from looking at it, there's no XAML designer. Building complex UIs is probably insane at its current stage. But it does look promising.

If you all want a .Net based, cross platform UI framework that can adapt to any design language. Look no further, Comet is it.

@nerocui this sounds cool, but at least from looking at it, there's no XAML designer. Building complex UIs is probably insane at its current stage. But it does look promising.

And it's not about drag-and-drop, it's about real-time preview of the UI in the designer when a change is made in the code.

Next week I'll release a set of VS Templates for UWP that let you create apps in seconds. This has been used for "internal" projects. It will prove the point that UWP can be a RAD framework out of the box if only VS had the right building blocks built in.

Is this using NoesisGUI? If so, there's a LOT of missing functionality that would be necessary for LOB apps. Now, WinUI targeting Unity would be awesome.

I've created a repo for documenting the current state of XAML and hopefully folks will help out and contribute with insights and actual code snippets that list how to accomplish tasks in the various flavors of XAML.

https://github.com/gatewayprogrammingschool/XAML-Standardization

Simple issue, move beyond the sandbox of today and embrace what is required for cross platform. Already doing it for every other aspect of Windows/OS why not the UI.

Take the sandbox cross platform.

From: anthonyadame notifications@github.com
Sent: Saturday, February 29, 2020 8:00:13 PM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Comment comment@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] Discussion: WinUI should be cross-platform (#2024)

Simple issue, move beyond the sandbox of today and embrace what is required for cross platform. Already doing it for every other aspect of Windows/OS why not the UI.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA.

Integrating high performance C++ components with C# is trivial under UWP. Access to DirectX surfaces is also much improved.

@Noemata Except what I care about is not having to write C++ to start with, WinDev keeps botching all attempts that would make .NET languages equal eye to eye in regards to C++ APIs, Managed Direct X, XNA, proper AOT compilation of .NET code, COM features, ....

Making WinUI 3.0 cross-platform will be that argument for porting existing .NET/Forms applications to WinUI.

For the beginning it will be enough to support macOS, and it's no problem when it doesn't have the same performance as on Windows, or not all features like animations.

Windows is the reference platform; of course it has to be coupled to DirectX for best performance.

In my opinion in make’s no sense trying to rewrite large C# applications in HTML+JS just to support macOS. And also for new desktop applications C# is the better choice.

For desktop applications C# and XAML are much more reliable than HTML+JS.

Making WinUI 3.0 cross-platform ensures the future of .NET, C# and XAML.

Hi All

I am a WPF contract developer working in London. Ive been building complex high-performcne user interfaces with WPF for a number of financial instututions since 2006. Here's my take on this:

1) I keep a close eye on the jobs market in the UK. 100% of WPF jobs advertised since 2006 (of which there have been 1000's) are for building high-performance financial trading desktop apps for the financial sector. There has yet to be any job advertisied for a UWP developer for any industry.

2) These desktop trading apps cant use UWP or the upcoming WinUI - its just not good enough compared to WPF for lots of complex reasons. Also Fluent design is not somethings these users are interested in - it just needs to look like an excel grid - no animations, no styling - just data and amazing performance.

3) These customers are not interested at all in cross-platform solutions. No-one uses a Mac, and mobile is not something they're interested in.

4) These WPF dev teams have large investments (time and money) in 3rd party WPF control libraries, or have had complex, performant custom control suites developed for them via people like me. They're not going to move away from WPF unless there is a very significant benefit (which there wont be for the foreeable)

5) For these financial institutions any application that doesnt need to be written explicitly for desktop / WPF is written with web technologies and Javascript. They're not interested in anything more exotic than that - no flutter, no blazor etc.

So this is the situation in the UK. Hundreds of WPF developers not looking to move into anything new anytime soon. Zero UWP developers (except for maybe a handful of one-man bands developing apps for the store - which is doubtfull looking at the state of the store)

Also, I dont understand all the hysteria about cross platform. Cross platform that spans both mobile and desktop is a fools errand. Never gonna be interesting. Microsoft tried this with UWP apps that ran on desktop and phone - it was a disaster - limiting apps to the simplest of UI's that could do nothing complex or interesting. Desktop and mobile devices are built for different tasks and use-cases, and need different apps - we all know this.

For me I want to see a lot more investment my Microsoft into WPF directly, without sacrificing backwards compatibility. I want to see WPF support control development in unmanaged c++ so we can work closer to the metal. I want to see better binding technology, better data templating, better control template functionality including partial inheritance. I want to see better debugging tools, and visual tree analysers. I want to see XAML debugging fleshed out more. I want better multi-threading support in the UI. I want lots and lots of things, and so do my fellow UK WPF contractors.
The current Microsoft roadmap gives me none of the things I want, and all of the things I dont care about.

If Microsoft doesnt support this vision (which they clearly dont right now), then plan B will be the community moulding WPF into the platform it needs to be via open-source contributions - assuming that Microsoft accepts a lighter touch when it comes to allowing new code and ideas to become part of the WPF framework.

@deanchalk I think most of this may have been better placed in the WPF repo to show them there is interest in WPF, posting it here mostly says you're not interested what is done in the WinUI repo / discussed in this issue. While thats valid input it probably won't lead to something constructive beyond void discussion.

@weltkante @deanchalk There is an issue in the repo asking for "legacy control support" in WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
At least point 4) fits that issue and should probaby be re-posted there to make the case for an investment by Microsoft.

@deanchalk, I'm still a big WPF fan. It's wonderful tooling that is, thankfully, starting to get some love from Microsoft. The manner in which Microsoft chose to drop WPF in the first place, was most unfortunate. UWP being the shiny new toy, should not have precluded continued investments in WPF.

UWP was in many ways, the right way forward. Unfortunately, the first iterations ignored some of the most critical requirements for folks that were using WPF and might have considered migrating over. Not least of which is the rather startling state of XAML fragmentation within the walls of a single organization. WPF != Silverlight != UWP != Xamarin. Wow!

I'm less sympathetic to WPF developers that have chosen to entrench themselves in WPF in the year 2020. Things have moved on considerably. XAML Islands with the ability to use the WinRT API give you a fairly easy path to start your migration over to UWP. And UWP is no longer lacking if you opted to do a wholesale conversion.

The bigger issue remains the lack of clarity from Microsoft on what's really next. All those that have been hoping for XAML Nirvana gave up with the Silverlight fiasco which is re-playing itself once again with UWP.

WinUI is so obviously a relabeled UWP, it's painful to witness. And it's equally obvious Microsoft hopes we'll all forget what UWP is/was.

Still, the left hand of Microsoft isn't always in tune with what the right hand is doing. WindowsX has made Win32 and everything that comes with it (WPF/Winforms/etc.) a tenuous prospect for applications that "might" run in its lower perf sandbox. UWP is, and currently remains the native UI for Windows 10, WindowsX and beyond. The WinRT API is a big improvement over Win32. So I guess you have to choose whether you want to move to the 2020's or stick it out in the 2010's.

WinUI is so obviously a relabeled UWP, it's painful to witness. And it's equally obvious Microsoft hopes we'll all forget what UWP is/was.

@Noemata WinUI is a new product based on UWP APIs (XAML, Composition, Input,...). The name makes sense as you will be able to use it to build UI for Windows apps no matter the underlying app model.

I'm confused. You yourself are mentioning 10X in the last paragraph. The UWP app model itself is getting a push with Windows 10X. Now, whether 10X will succeed is something only time will be able to tell. But MS has been clear in its messaging: UWP is the native platform of 10X (alongside web) as you pointed out.

@Noemata until 2020 catches up with the features available in 2010, many of us are forced to stay in 2010.

Many of us just got tiring of the rewriting train that started with dropping Silverlight, XNA and seeing how MS hand waves the rewrites requiring for .NET Core, WinUI, while dropping features in the process, doesn't win the hearts of many of our customers, with fully working applications that don't see why they should pay rewrites to get back less features.

Right now, thanks to the cleverness to have Android and Windows 10 X tablets, Xamarin and PWAs are what we are looking forward, not WinUI.

@pjmlp, perhaps. I'm curious what feature you are missing? I've ported over some fairly large WPF apps over to UWP. The biggest headache was the security sandbox and learning to work with it rather than fight it. Previously there were missing pieces, like the Data Grid, DB connectivity, a decent API for high speed communications and so on. There's very little missing now. There's a lot I couldn't do nearly as easily in WPF. To be fair, at present, there's nothing I couldn't do in WPF by leveraging access to the WinRT API except I would have lower perf because UWP compiles to machine code in a more optimal way and uses a better DirectX rendering stack. Plus you have to obfuscate your WPF code (make it more fragile) if you're intent on protecting your IP or preventing intruders.

Phones/tablets are great devices for point solution sort of apps. I wouldn't want to score a symphony on a phone, or design a skyscraper, and I'd rather be able to target part of the point solutions portions of my desktop app to mobile, than try and make mobile work on my desktop.

@Felix-Dev I get what WinUI is. I question why yet another fork was required just because WPF, Winforms and MFC/Win32 devs wouldn't buy into it. The better strategy would have been to make migration either more attractive or less painful or both.

Microsoft has done a lot of things right with UWP. There are a wealth of samples apps out there covering all sorts of use cases. They arrived late, as did the missing features. Is it really too late?

@Noemata WinUI would probably have happened either way (with or without WinUI Desktop) as decoupling the UWP UI stack from the OS is an absolutely necessary step. It would have been best if WinUI would have already existed when Windows 10 was first released but there are reasons why that was not the case.

As for is it too late....we had many such discussions over in the UWP community discord channel and also countless passionate exchanges here. Some of us think the ship has already sailed while others still think there is a chance the UWP platform/WinUI can grow and mature to become a major dev platform. Many people with many ideas how the best approach for MS could look like (i.e. go xplatform or not?). Fact is, the team is currently hard at work on WinUI 3 and its release will signal the start of taking on the real challenge: Pushing WinUI forward - with the community helping out - so that it will become the framework of choice for developers targeting Windows.

@Noemata, first of all compatibility with existing third party component libraries from the likes of Telerik, Component One, ...

Then not having to re-write anything to start with, as mentioned, we are fed up with rewrites.

In what concerns DirectX, not only the 3D modelling classes from WPF aren't supported, we are expected to write C++, because Microsoft cannot be bothered to create Runtime projections for DirectX, and the somehow pleasant C++/CX dialect got replaced by the wordy less capable, but hey better compliant, C++/WinRT.

On top of this, not only do we have to throw away perfectly working WPF code, we have to do the same to WCF, EF6 code.

I still believe that UWP is much better API that Win32, somehow what Longhorn should have been, but the way this is being played out just has burned too many bridges, as Microsoft has burned the rewrite budget from many organizations.

@pjmlp, those are all good points with rather meek counter arguments, so I won't even try. No support for the WPF 3D API was a big blow for me personally. Having to learn a new approach was no fun and a lot less capable given the WPF binding options for 3D. C# alternatives for 3D under UWP are there, just way less useful once you've experienced the benefits of binding on a 3D model.

C++/CX was another pain point that took too long to get resolved by C++/WinRT which might be stable next week sometime (it's still shifting).

WCF is dead (sorry, new options are much, much better). EF6 should have had a way better migration story. You are absolutely right on the re-write budget fiasco @pjmlp, clearly this is something Microsoft used to get and no longer cares to consider given the crazy/inconsistent churn on tech.

@Felix-Dev, you too make completely valid points. The UI decoupling should have been there from the start. The folks asking for xplatform UI based on XAML should re-phrase their request and ask for a XAML rendering engine on their platform of choice with a mini OS to replicate the API surface (another Java/Silveright/Uno Platform/Unity/Whatever … eventually ending with HTML that close to the metal apps can't begin to consider). I'm not privy to the latest MS internal initiatives at the moment. Looking outside in, WinUI is the waving flag indicating the ship is being righted again (how many more times?). Defending Microsoft became impossible with the death of Silverlight. I won't be picking up that sword again. I suppose what I'm really doing is lamenting the death of UWP :-( ... painful. https://www.youtube.com/watch?v=uBiewQrpBBA

Charlie == Microsoft

Cross Platform? Microsoft should just buy UNO and be done with tit.

Cross Platform? Microsoft should just buy UNO and be done with tit.

I would hope whatever solution presents itself, it would not rely on a web browser or web view of some kind. Display the UI in whatever the platform's native window or UI surface is - but look identical to how it would on Windows.

Cross Platform? Microsoft should just buy UNO and be done with tit.

I would hope whatever solution presents itself, it would not rely on a web browser or web view of some kind. Display the UI in whatever the platform's native window or UI surface is - but look identical to how it would on Windows.

That's how UNO does it except on Windows 7. Windows 7 is the only exception as it is using the Web browser.

For those WPF developers who require a cross platform desktop solution Wine may be a viable option for you. I have had great success porting large WPF applications (.NET Core WPF mostly) to run on Linux with Wine. I have a writeup that can help get you started:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

I have also started porting some WinForms app to Linux as well. So far I have not run into any issues.

Wine should also enable you to run on Mac, Chrome OS, and Android. I have only tried Linux.

To me this shows that using DirectX as the abstraction layer works and is a viable model to follow. I suspect it would even work well on the Web with WebGL once .NET WASM is more mature.

Getting Microsoft to help out with Wine (at least making sure they don't break it) would help a lot. They could help to create a truly native solution with WineLib and given their expertise I don't think it would be too much effort.

AvaloniaUI already IS already cross-platform. Why don't ask people in the project for help and feedback to improve WinUI?

Well, not as much as Uno Platform. Uno Platform runs on web too (WASM). Avalonia lacks this capability.

Avalonia also uses it's own dialect of XAML, which is something Uno is trying to avoid.

From: Shimmy notifications@github.com
Sent: Friday, March 27, 2020 4:09:30 AM
To: microsoft/microsoft-ui-xaml microsoft-ui-xaml@noreply.github.com
Cc: The Sharp Ninja ninja@thesharp.ninja; Comment comment@noreply.github.com
Subject: Re: [microsoft/microsoft-ui-xaml] Discussion: WinUI should be cross-platform (#2024)

AvaloniaUI already IS already cross-platform. Why don't ask people in the project for help and feedback to improve WinUI?

Well, not as much as Uno Platform. Uno Platform runs on web too (WASM). Avalonia lacks this capability.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA.

Most of WinUI's technology comes from Sliverlight, and Sliverlight has actually achieved cross-platform. So WinUI cross-platform depends on strategy, not technology.

Honestly... it's actually so pathetic Microsoft is now trying to play catch up... they only care about "big" marketshare, they are not looking what their customers/product fans want.

Microsoft is the reason why DESKTOP APP development has shifted to the outdated WEB development, even when web is so horrible.

I'm sure every XAML dev agree that HTML/CSS is so garbage.

But still... HTML, CSS, DOM... with frameworks like React, Angular, Vue who are trying to make it something little bit more pleasant. People still focused on this outdated web, not on Microsoft's new closed-source Windows-only platform that dies every 2-4 year for a new one.

XAML based Win-app platform should have open-sourced YEARS ago. It should have write once deploy on WEBSITE, Windows, Mac, Linux, Android (any platform customer wants). Windows Store should have been crossplatform with an XAML/UWP app renderer. (similar how Google Chrome is crossplatform with HTML/CSS renderer).

During Microsoft's golden age, a XAML based crossplatform app could have destroyed the web, then we wouldn't had to deal with this CSS, HTML, DOM and countless frameworks.

But no, Microsoft obsession with proprietary software made them lose to the web.

Meanwhile Google's Flutter is becoming what I always wanted for XAML.

I expect that WinUI 3 will be a target platform in MAUI. Uno platform has already announced that WinUI 3 Preview got support.
So, @jeromelaban / Microsoft what we probably really need is Uno/MAUI unification? MAUI is less useful IMO than Flutter or Uno without a web (browser) target.

Please leave your comments in the MAUI repository, too.

WPF(Silverlight) everywhere!

Porting DirectX to other platforms seems a vaste work, maybe the solution is to use OpenGL or Vulkan instead of DirectX

Google has ANGLE which allows running OpenGL ES natively on any platform by translating calls and shaders into native API (desktop gl [possibly provided by swiftshader software renderer], vulkan, directx, metal). It is also a core part of Chrome and Flutter, running alongside with Skia.

Microsoft could do a small (maybe just as a starting point) subset of DirectX for GUI apps and make it translate into native APIs just like ANGLE does.

What comes to the "different linux distro support" problem, linux users are often skilled enough to fix incompatibility themselves, and even then there is Flatpak which unifies packaging for desktops just like Docker does that for servers.

Mentioned in Lonje chat https://www.lonje.com/message/1968439855/

I really think WinUI should also support native theming on Mac and Linux while still supporting custom theming.
I'm not sure about Mac users but the Linux community likes to control how their desktop looks.
They already have Gtk which I think would be a good thing to wrap into the WinUi framework

I really think WinUI should also support native theming on Mac and Linux while still supporting custom theming.
I'm not sure about Mac users but the Linux community likes to control how their desktop looks.
They already have Gtk which I think would be a good thing to wrap into the WinUi framework

It is most definitely hard to do as WinUI is a style language, and underlying XAML frameworks require you to do theming yourself, while default themings are provided too.

I have suggested in the past, that the project should be structured in a way that enables the community to develop a Metal Renderer for macOS and iOS - and possibly a Skia renderer for Android.

The same default Styles and Templates could be used on all platforms, or Android and macOS styled default templates and resources could be created.