search

microsoft / microsoft-ui-xaml

Windows UI Library: the latest Windows 10 native controls and Fluent styles for your applications
MIT License
6.31k stars 676 forks source link

WinUI 3.0 roadmap - we need your input! #717

Closed jesbis closed 5 years ago

jesbis commented 5 years ago

WinUI 3.0

At the Microsoft Build conference in May 2019 we shared our plans for WinUI 3.0, which will greatly expand the scope of WinUI to include the full native Windows UI platform. This means that the full Xaml framework would be developed on GitHub and ship out of band as NuGet packages.

The WinUI roadmap is now up to date with the latest plans for WinUI 3.0:
https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

You can also watch the Build 2019 conference session State of the Union: The Windows Presentation Platform for more details.

We'd love to hear what you think, and have some specific questions below.

How will this affect building Windows apps and components?

WinUI 3.0 will provide many benefits compared to the UWP Xaml framework, WPF, WinForms and MFC.

So, we want to make sure it's easy for everyone to use WinUI 3.0 in new and existing apps. There are a few ways we can approach this, and we'd love to hear your feedback on what areas we should focus on.

Our current thinking is:

Creating a new app

We plan to create new Visual Studio 2019 project templates for common languages (e.g. C# using .NET Core, standard C++17 using C++/WinRT) and app model + packaging (UWP + AppX, Win32 + MSIX).

What templates would interest you most?

The developer experience would be similar to current UWP apps.

Adding WinUI 3.0 to existing Win32 apps

WinUI 3.0 will include Xaml Islands, which let you use WinUI Xaml in your existing WPF, Windows Forms, and C++ Win32 applications.

The current version of Xaml Islands is only supported on Windows 10 May 2019 Update (1903), but the WinUI version should be backward-compatible to Creators Update (15063).

Were you aware of Xaml Islands for modernizing desktop apps?
Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you?

Updating your existing UWP Xaml app to WinUI 3.0

You'll have to update your app's target version to WinUI 3.0 to take advantage of it, similar to retargeting to a newer UWP SDK today.

We want to maximize compatibility between UWP Xaml and WinUI 3.0, but there will be some things to be aware of when updating.

1. Namespace update

The root namespace for Xaml, composition, and input APIs in WinUI will be different than the Windows UWP SDK root namespace:

Old namespace New namespace (tentative)
Windows.UI.Xaml Microsoft.UI.Xaml
Windows.UI.Composition Microsoft.UI.Composition
Windows.UI.Input Microsoft.UI.Input

We're exploring options for helping you automatically update namespaces when retargeting your UWP app to WinUI 3, at least for .NET apps.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

2. Mixing UWP and WinUI Xaml components

The fastest path to releasing WinUI 3.0 would be to not support mixing:

with:

in the same app.

However, one of our biggest concerns is the compatibility issues and work that could create for existing UWP apps and component libraries, particularly if you're authoring or consuming UWP Xaml control libraries.
For example, existing versions of the Windows Community Toolkit wouldn't be usable in WinUI 3.0 apps, so both the Toolkit and any apps using it would need to update before using WinUI 3.0.

We hope that all UWP Xaml control libraries can be updated to WinUI 3.0, but we know that even in the best case it would take time for everyone to update.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

What would be your preferred solution for using UWP Xaml components with WinUI 3?

General questions

  1. What do you think about the overall 3.0 plan outlined above and in the roadmap? Would it enable you to use WinUI for your new and existing Windows apps?

  2. What kind of apps would you be most excited to use WinUI 3.0 for? Creating a new Win32 app and packaging it with MSIX? Adding new views to a WPF app? Modernizing a C++ MFC app with Fluent UI?

TonyHenrique commented 5 years ago

@mrlacey I mentioned Fody because I think it is an interesting solution and we need a better way to avoid the INotifyPropertyChanged boilerplate code. It would be good to have a MS supported solution to this concept of a Reactive object that automatically raises a event when some property changes. It works on C# classes and even on F# Records (but had some difficulties). So on the WinUI roadmap there should also have this.

Note: It would be good if we also could use the F# records to define our data entities and Bind then directly to the XAML UI. It would be cool if we could be using F# Records + Fody + DataBinding without problems .

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

This would be more familiar for folks coming from C#. Another approach would be the Elmish way. I think that both are interesting, and could be supported.

GeertvanHorrik commented 5 years ago

@tonyhenrique / @mrlacey I think the Fody stuff (OAP) should be out of scope. The WinUI team have enough on their plate already, and I think it's better to have the weaving in separate projects (much faster release cycles in case of improvements).

And I think this is actually a .NET (IL) implementation detail of the models, not actually anything to do with WinUI (although it can listen to the change events). My suggestion is to keep them separate. For example, I use Catel and it has its own Fody weavers to make sure everything gets weaved correctly.

4creators commented 5 years ago

What I'd really like to see is a go-forward XAML dialect with truly universal aspirations. I should be able to write a .NET app using XAML, and have that app run on Windows, iOS, and Android. The app should be truly first-class on each platform and have access to native elements as needed.

There is a long standing proposal to go in that direction: Cross platform UX for .NET 5 - original title Cross platform UX for .NET Core 3.0. The overwhelming support of community for it is obvious and we can hope that MSFT will realize that this is the best direction to develop any UI framework working on .NET. There is pretty much no reason to keep separate codebases for different platform groups and forcibly creating separate developer skill sets based on different UX frameworks supported by .NET.

By creating single UX for all platforms we cancel all inefficiencies in framewrk development and lower the barriers to developer adoption. Only these two aspects should be sufficient to consolidate all UX XAML based frameworks.

MarkIngramUK commented 5 years ago

@mfeingol / @4creators , I would settle for

The app should be truly first-class on each platform

on Windows to start with...

It's 2019, I want a fast, native UI, and I don't want to have to seriously consider making a user interface with CreateWindowExW, GDI, etc.

Suriman commented 5 years ago

Now that with WinUI3.0 and above the code is decoupled from Windows 10, are there plans in the future for WinUI to work on Linux and Mac?

r7dev commented 5 years ago

@jesbis Touch interactions will be kept in WinUI 3.0?

mdtauk commented 5 years ago

Thanks for the clarification, I had assumed the way 3.0 would work was to include Xaml Islands in WinUI, rather than use the Community Toolkit.

With it becoming XAML plus Win32, it makes more sense, especially with the Windows Core OS rewriting it's shell in XAML.

As I understand it now, this rich Win32 API access is in C and C++ | with anything in C# relying on .NET (all be it now .NET Core).

Perhaps there should be a safe and simple way to access these Win32 APIs, as well as more entry points for displaying an apps UI?

jesbis commented 5 years ago

Touch interactions will be kept in WinUI 3.0?

@r7dev yes, the plan is to keep the same level of touch support.

Happypig375 commented 5 years ago

F# is ignored on the WinUI 3.0 roadmap. Microsoft ignoring one of its products once again.

eklipse2k8 commented 5 years ago

Win32 API Thoughts

Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language.

On OS X, to access AppKit you just needed to bridge the objc_msgSend C API and gain access to the entire obj-c infrastructure. All of those languages above did a really good job of bridging that and it made it easy to write in your language of choice and produce something compelling.

So if you want to to make WinUI 3.x be the true path forward for accessing low-latency, low-memory, high quality Win32 UI, you need to consider the ease at which other language maintainers can tap into the infrastructure.

UI Consistency

If you're really planning to decouple the UI from the system, what is the plan for the UI remaining consistent with each OS upgrade? When Apple makes tweaks to shadows and gradients in AppKit or iOS, Apps that rely on the system frameworks inherit all of those tweaks and remain consistent. It's also going to make it hard for you to add system-wide experiences because Apps that are locked to UI infrastructures 3 years ago may not operate well with some new system service, so they will have another compatibility layer as time goes on.

There will always be features that need to be opt-in, I can think of Dark Mode as something that if the app wasn't designed for it, it really wouldn't make sense to offer it as an option, but there are still tweaks to system components that would change over time.

Binary Size

What is the planned story for delivering all these UI.dlls with our projects? Will these things be 40mb of runtime that need to ship with our projects? What will happen if a project is abandoned, will they start to look outdated because they use old UI frameworks?

One of the benefits of C++ is that it has a minimal amount of library overhead depending on the codebase. Certainly if every single app from here on out required WinUI 3.x, that is going to be 40mb x number of apps.

vitordelucca commented 5 years ago

Binary Size

WinUI is already a dependency, just like .NET is. It's already a system-wide library. :)
You don't have duplicated dlls, and you won't have it. https://www.microsoft.com/store/productId/9N00JJ7S3L39

contextfree commented 5 years ago

@eklipse2k8

"Something I also thought about is the reason win32 has stuck around too. I think there's an assumption that this is because of legacy projects, but it's actually quite deeper than that. The Win32 ABI is super easy to hook up with your language of choice, nodejs, python, rust, go, ruby, c#, c++, etc. etc. If my core project is in rust for example, and I want to generate a window to manage the output, as a rust developer, it's super powerful to access the win32 API set and build a front end in the same language."

This is a mixed bag though as while implementing WinRT support for a new language is a huge hump to get over, once you do, you end up with autogenerated typed bindings to any new APIs. I've been working on a Rust project that bridges Win32 and WinRT recently (using the Composition APIs in a Win32 window), and the Win32 parts have definitely been more of a pain overall even though I've had to clumsily work around the remaining lack of Rust support for some WinRT features like class inheritance. (It does definitely help that using Composition inside Win32 is now possible, since it allows incrementally improving support for this feature instead of having to tackle the entire app model all at once)

Probably the biggest problem is that the documentation for low-level WinRT ABI details is kind of disorganized, and there's just very little understanding or awareness of them in the world/community, I'm hopeful this situation will improve with the xlang project though.

mfe- commented 5 years ago

What templates are you most interested in?

Currently I prefer to start from a Blank App (Universal Windows) project. I like templates with a preconfigured framework too, but only when i want to try out something quickly. A "Main Menu" Template and MDI Template for UWP would be nice too (as those templates exists for WinForms too)

Were you aware of Xaml Islands for modernizing desktop apps? Does this expanded backward-compatibility on Windows 10 make Xaml Islands more useful to you

Yes, I'm aware of Xaml Island. If I can, I'll try to stick to a pure WPF or pure UWP app. I wasn't in a situation where I'd would require such a feature.

Would it help if Visual Studio or another tool automatically updated namespaces for you?

Yes, sure if it works reliable! I'm surprised by the many comments which don't appreciate such a nice feature. Also this feature could check if an update to WinUI 3.0 is doable, adopt the XAML Code, adjust the namespaces and install the required WinUI nugets.

How important to you is full compatibility between existing UWP Xaml components and WinUI 3.0 apps?

I would expect to change only the namespaces of the control to work full with WinUI 3.0. I don't want to invest much time in upgrading to WinUI 3.0

Do you create or use UWP Xaml control libraries or WinRT components that you couldn't easily recompile and update alongside app code?

I'm using third party UWP Xaml control libraries (like Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ). I think I would be able to upgrade simple controls from third party libraries like a Dockpanel by myself to WinUI 3.0.

What would be your preferred solution for using UWP Xaml components with WinUI 3?

The fastest path to releasing WinUI 3.0 would be to not support mixing [...]. I absolutely would prefer such a solution as long, as I get all basic controls. I would expect that all classes from Windows.UI have an equivalent class in the Microsoft.UI Namespace.

The main topic in WinUI 3.0 was all about controls and windows 10 compatibility which can be used from UWP and WPF or WinForms via XAML Island, if I'm correct. Are there any chances that the UWP XAML Markup gets somehow additional features?

I'm really looking forward to WinUI 3.0 and its backward compatibility !

jesbis commented 5 years ago

F# is ignored on the WinUI 3.0 roadmap

Are there any chances that the UWP XAML Markup gets somehow additional features?

@Happypig375, @mfe-:

The roadmap only covers the initial 3.0 release, and for the initial release we're mainly focused on parity and backward compatibility for existing features, with a small number of new features.

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Why is every second Windows.UI.Xaml.Controls control (TextBlock, Border,...) declared as sealed?! Please don't do this in WinUI 3.0 with UWP.

Unsealing controls is actually one of the small number of new features we're hoping to include in 3.0 😊

mdtauk commented 5 years ago

When it comes to languages, it would be neat to mix and match (which should be fine if everything is compiled down before packaging)

F# used for some back end logic - C# for Databinding and UI code - C++ for controls and maybe some low end Win32 hooks or even to launch a WinForms dialog.

All code languages are equal, interchangable, with WinUI 3.0 handling all the UI

MarkIngramUK commented 5 years ago

That’s xlang 😉

mdtauk commented 5 years ago

That’s xlang 😉

@MarkIngramUK Hmm, I thought it was a bridge between languages, which abstracts each language, rather than allowing code files from multiple languages in a single project.

I have kind of struggled to understand the purpose of xlang - glossing over the updates that have been happening in the repo (but still have it in my watching list)

Does xlang work pre or post compiling? Is it its own abstracted language which can be projected, or does it just sit between existing code files?

MarkIngramUK commented 5 years ago

Yes, you can’t mix languages in a single project. It’s a bridge, but still useful for those purposes.

mdtauk commented 5 years ago

@MarkIngramUK I guess so if its code that can be compiled then included.

It would be good to be able to use C# to access native Win32 features, without PInvokes and other .NET tricks

galvesribeiro commented 5 years ago

@jesbis I'm honestly more interested in a cross-platform aspects of this project...

I think that at start, you guys should rename it to something more generic and not strictly to "Windows".

I got it that the initial implementation should be strictly focused on Win32 and back UWP/Xamarin apps and Windows but just OSS it and make it from the beginning called like a "Windows-only" framework, will definitively not get much traction just like UWP didn't and developers from other platforms would never get interest on it.

If the target on .Net 5 is to be "One .Net Everywhere", which is basically what everyone always expected since .Net 1.0, the foundations for "Anything but Win UI" framework should start cross-plat.

A very good example on how to make it right is Google Flutter. Flutter is on its very early days, but got A LOT of traction due to the fact that their core (aka Flutter Engine) is 100% cross-plat and works everywhere (including IoT, Win, OSX, and now even Web!).

That is just my 2c. I would love to get back to work on Xaml but if it keep on the same line as on UWP, I'm afraid it will not get the right traction and will be another attempt to re-write WPF that will eventually need another attempt in the future and so one so forth.

Please don't take me mad and don't take my comment as a bad criticism. I just wish that the efforts on the UI on .Net world would get something like Flutter, .Net Core 3.0/.Net 5, and even Blazor.

galvesribeiro commented 5 years ago

For the record, I event started a project to rewrite/port Flutter engine entirely on C# and .Net Core due to the lack of options on .Net World...

galvesribeiro commented 5 years ago

BTW, CoreUI is a good name...

Kudos to Jake Helfert for that suggestion 😄

💃

mdtauk commented 5 years ago

BTW, CoreUI is a good name...

Kudos to Jake Helfert for that suggestion 😄

💃

CoreUI may get confused with .NET Core

WinUI is very much focused on Windows, but the XAML framework within it, could get renderers for Metal (iOS and macOS) or Vulkan (Android) - and FabricWeb could be the PWA/ChromeOS way to handle the other platforms.

If the team ever choose to bring the presentation platform over, and Xland or Xamarin could handle the runtime for cross platform apps.

contextfree commented 5 years ago

About the migration from inbox UWP UI to WinUI 3.0, I'll quote a recent blog post from @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Fun bottom note: What’s happening to UWP is not that it’s being killed: Microsoft is pivoting bringing the bests parts to where we need them. This actually happened before, but it was unfortunately not used as an opportunity to perform a pivot. Remember Silverlight? Guess where .NET Core’s cross-platform CLR came from. And lots of Silverlight’s code also ended up in UWP. Had they only pivoted and said “Yeah we agree Silverlight doesn’t make sense in the consumer spare, but it’s thriving in the enterprise space, so let’s build on that, and we’ll evolve it into .NET Core and Windows Store”. Unfortunately that didn’t go so smooth, and lots of people still suffer from PTSD and wary of whatever Microsoft does that appears to be killing off any technology.

I really think it's important to remember that being perceived as killing off or resetting existing frameworks without giving developers and codebases a good way forward doesn't just affect developers on the existing framework - it can cast a cloud over future efforts as everyone wonders why the new thing won't just meet the same fate. This isn't meant as a remark on any specific proposed migration approach, more a response to the comments to the effect that migration doesn't matter because not many people are using the existing inbox UI framework. That's not the only consideration!

mdtauk commented 5 years ago

@weitzhandler WinUI 3.0 is about combining various Win32, .NET Core and UWP frameworks with a single XAML framework, and interoperating with WPF, WinForms, and MFC++

XAML on Windows is rendered down to Direct X.

If you wanted to take that same XAML, combined with .NET Core, and make it work on other platforms. You would need to write new renderers for those platforms. iOS and macOS use Metal as their Direct X equivalent. Android uses Vulkan. No idea how Linux handles rendering, I would guess its just Open GL.

Microsoft will not want to do that themselves because it does not make sense for them. But WinUI 3.0 will be open sourced - so others could choose to try to bring it cross platform

mdtauk commented 5 years ago

@mdtauk

Thanks for clarifying that. Flutter is probably the future for me.

That is just my understanding, I could be mistaken.

Flutter is supposedly getting Windows support in the future. And React Native support is coming to Windows also. Plus there are PWAs if you are invested in that Web HTML and Javascript world.

TonyHenrique commented 5 years ago

To me the whole WinUI story can make more sense if they also take in consideration allowing at least a basic subset of it run cross-platform (macOS, iOS, Android) including Web, and also offer a better F# support and project templates (including XAML Two-Way Binding to F# Records, and also a more functional Elmish way)

zezba9000 commented 5 years ago

XAML needs to be environment agnostic just like HTML is without taking 100mb+ for even the most basic tool apps as HTML apps do. This means a XAML framework that is written in pure C/C++ or C# and can be hosted in WASM, Win32, UWP, iOS, Android, macOS, Linux etc with minimal effort when it comes to porting. You need an agnostic rendering backend like game engines use to start with.

None if this UWP focused XAML is solving any problems my company or me personally has had for years with XAML... and thats portability. TBH MS is going about UI completely wrong and its going to get no where fast (its wasting a lot of valuable time for a lot of people). This UWP XAML hackery just doesn't come off well to people I show it to... which is sad because it just means a never ending push back against the adoption of XAML and I have no more arguments at this point.

The only way to save XAML in my opinion is:

Simply put there are two conditions that have to be combined into one before XAML adaption will be excepted.

1 MS needs to back the XAML project or people fear it falling out.

2 It needs to be cross-platform or everyone is going to be stuck with crazy bloated HTML runtimes.

Anyway thats my two cents and if WinUI 3.0 is designed right maybe porting will be possible. At this point though idk what to feel.

eklipse2k8 commented 5 years ago

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree.

Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard.

No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

Kade-N commented 5 years ago

There's a few comments about being cross platform in here, and I'm not so sure that WinUI would need to be cross platform to be successful. It wouldn't work well on Mac or Linux anyway, as it's different enough that it wouldn't feel native on either of those platforms. This project is owned by a team that has a wealth of knowledge about how Windows internals work, and it would be a distraction for them to go off and figure out how to also make something work really well on Mac or Linux to same degree. Also... Fluent on Mac would feel clunky, just look at iTunes, Apple had to port their entire UI system to Windows, and it definitely feels out of place. Font rendering is different, the animation curves and shadows and color choices just feel so out of place in Win10. I mean, it's fine and usable sure, but I prefer spotify which doesn't try to emulate any desktop UI and just uses a web browser under the hood. On Mac, seeing the reveal spotlight with square components in a desktop full of rounded corners and no reveal effect would clash so hard. No, I think this project should focus on offering the best in class way to make native Windows software, for developers who want/need to build windows software. Leave the cross platform stuff to the Electron/Typescript teams to solve.

I don't think anyone really wants full Fluent design on other platforms, but rather just be able to maximize common code between platforms.

This is something that has already been addressed by the Microsoft Design team. The Fluent website explicitly says "design and build custom apps that are natively iOS while still uniquely Fluent". The Fluent docs show that native control styling should be used. https://www.microsoft.com/design/fluent/#/ios https://developer.microsoft.com/en-us/fabric#/controls/ios/button

What should be avoided, is having to design and maintain completely separate UIs for each platform. That doesn't mean that it needs to look identical on the surface, but should share a common layout, and UI designers should be able to reuse as much as possible. The actual styling does not (and should not) need to match the Windows 10 system styling.

In essence, what is wanted is an easy way to get Windows apps running on other platforms, without having to remake the entire UI - not to bring Fluent design to other platforms. That would enable people to write for Windows first, and then bring their app to other platforms without a lot of work.

eklipse2k8 commented 5 years ago

@KyleNanakdewa Well if they're open sourcing it, let some Xaml fans go off and create the underlying platform bits. I think it's probably architecturally complex enough and takes advantage of Win32 enough that i suspect the port would be a massive undertaking.

mfeingol commented 5 years ago

I think this project should focus on offering the best in class way to make native Windows software

This argument might be compelling if Microsoft didn't already own an existing cross-platform XAML toolkit that just happens to offer a very different dialect of XAML than WinUI.

Mike-E-angelo commented 5 years ago

Plus there are PWAs if you are invested in that Web HTML and Javascript world.

Yes... "that world" which is quickly replacing everything we know about native OS/Store/Hosted development. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Consider "that world" exists on all modern devices with an HTML5 renderer:

You will notice that Windows now has the smallest market share, meaning that any offering that caters specifically to this platform will be one that reaches the smallest marketplace. Doing so only lowers an application's maximum potential market reach which, in turn, lowers its maximum potential revenue ceiling.

Compare this with Flutter, which with one codebase reaches all of the aforementioned marketplaces, along with the web, which as mentioned is composed in aggregate of all three -- therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.

While I am a huge fan of the efforts here to open source, collaborate, and solicit community feedback, I have yet to see anything from these discussions (which I also enjoy 😁) that signal to me with any confidence that the efforts here will be competitive -- and therefore profitable -- when compared with the likes of Flutter (which btw is also gearing for PWAs).

GeorgeS2019 commented 5 years ago

Diagram control is essential in any data driven modern desktop experience in soon to be official NET CORE 3 (Sept 2019) and eventually. NET 5 (Nov 2020)

I see the provided Networkview open source control as an effective use case on how to work with Xaml to port WPF to Win UI control. This ported Win UI will serve as a good guild for others to port other slightly more complex WPF controls to Win UI.

We see 2 in 1 use case where our app need to support the tablet mode in future Windows Core OS. We suspect Winform in. NET Core 3 will not help.. another strong justification why Win UI diagram control is NOT just an exercise of PoC BUT should be part of win ui core controls in similar FIRST class as Grid control moving Forwards..

mrlacey commented 5 years ago

If you think other new features like better F# support or new markup capabilities are important then please do open a new feature request so we can track them separately!

Seems @migueldeicaza is taking matters into his own hands: https://github.com/microsoft/microsoft-ui-xaml/pull/736

MarkIngramUK commented 5 years ago

I want to echo @eklipse2k8 's thoughts on cross-platform. When making a cross-platform UI library you will always have to make compromises. WinUI should not compromise - it needs to be the modern replacement of Win32 UI (I don't want to be calling CreateWindowExW any more!) and it needs to be a showcase of what you can do on Windows. WinUI on macOS or Android would always deliver an experience which could never match the native experience. We write cross-platform applications, and we write native UI on each platform. That way the customers get the best experience on their choice of platform. If people want a cross platform solution, that's fine, they should look to another library for that purpose - perhaps one that wraps WinUI on the Windows platform.

And with regards to PWA, these do not represent the full use of the Windows UI system, recommending focusing on "single window applications" would immediately rule out any professional piece of software (except games). There are solutions already for PWA and cross-platform - we don't need another one.

Obligatory XKCD: https://xkcd.com/927/

mdtauk commented 5 years ago

@MarkIngramUK I think the talk of Cross Platform is more about being able to code to .NET and XAML for declaring UI - then to have that app run on Android, iOS, macOS, Linux?! - without having to change the code behind or abandon the XAML.

Now if there were XAML Renderers for these other platforms - how they interpret the XAML could be like Xamarin Forms, which hands over to native UI platforms - or just essentially draw to the graphics card buffer and draw the pixels on screen - maintaining most of the same controls styles.

WinUI 3.0 should remain a Windows focused project to unify the various APIs and ABIs with a modern XAML based UI platform. But that doesn't mean Xamarin or individuals can't take the rendering code and make versions for other platforms.

All that would be needed really (at a high level of thinking) is to ensure the code that renders XAML to the screen in Windows is contained, so other renderers could step in for cross platform scenarios.

WinRT/UWP/XAML is going to need some refactoring to extricate them from the Windows 10 OS - so how that refactoring is done, to allow for future expansion, is something to keep in mind. Whether cross platform becomes a reality or not.

Pinox commented 5 years ago

@MarkIngramUK I agree with @mdtauk

There should be no reason why we can't use xaml to describe UI components in other libraries including React. If you look at a project like http://www.cshtml5.com , they use xaml that gets converted to html. I also don't think anyone alludes to the fact that the end goal is for the UI to look the same on other platforms but what I personally want is something on the UI side that I can use to leverage my existing investment in eg UWP

The point is simply this. If I make a proposal to a enterprise customer and present an awesome UWP app that is fantastic in all respects. If that enterprise customer has 1 user that is using for example a MacBook Pro, then I immediately have a problem as the enterprise customer will rather take something that works everywhere (lowest denominator => website) than my "native app" even if they run on Windows 10.

So accessibility is key. The fact that MS is still expecting us to make investments in "native apps" in 2019 without any roadmap to cross platform capability is crazy.

Any new project from a enterprise perspective is likely to follow the above logic for accessibility and therefor all new projects will be biased towards the web and all because there is no roadmap that includes cross platform capability on XAML/UWP

So then we fast forward 2-3 years from now , no new investment from companies into UWP/win32 and you are sitting with another "Silverlight" that nobody cares about.

MS can even tell me that XAML is deprecated tomorrow and the "new" UI library is for example React. As long as c# can be glued to this new library then I will cut my losses, dump XAML and embrace this new cross platform UI library. At least my investment has durability and is accessible long term.

By not providing clarity on this specific issue around cross platform UI capability, MS is creating uncertainty around their "native stack" and therefor most enterprises will rather run throught a fire with a wooden leg than embrace the unknown.

Mike-E-angelo commented 5 years ago

And with regards to PWA, these do not represent the full use of the Windows UI system

Fair enough, and I agree. My primary point with PWA was to demonstrate that its market share dwarfs any single particular market, as it is comprised in aggregate of all markets.

That said, I suppose part of the confusion here on my part is the namespacing to reflect Microsoft.*, when really it sounds like it should still be Windows.* (or even Microsoft.Windows.*).

There are solutions already for PWA and cross-platform - we don't need another one.

Unfortunately, this is not the case for .NET development, which is part of the confusion and cross-platform angst around this announcement and subsequent discussion.

ekral commented 5 years ago

therefore maximizing market reach and potential revenues for application developers while reducing the necessary costs of building applications to do so.

Sometimes performance and UX details can make a big difference. Skype has maximized market reach using Electron framework at the cost of sacrificing performance and the result is the commercial disaster.

mrlacey commented 5 years ago

Regarding cross-platform (xplat) solutions. Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.

If WinUI was to also be xplat, how would it incorporate things that are unique to Windows? Wouldn't that prevent it from doing new and innovative things? Or would that mean it's on Microsoft to port anything new or differentiating from Windows to other platforms too? What about things that couldn't be ported because the other underlying OS couldn't support them--should they not be added to Windows?

If you build something with native Windows technologies, it's reasonable to assume that Microsoft will support that for a period of time and provide a path forward to newer Windows based systems in the future. (Acknowledging SilverLight as an exception.) I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy. If you built an app for the iPad with Swift and wanted to also bring that to the Windows desktop, would you expect Apple to change iOS development to make that easy?

If you enjoy or prefer using native Windows technologies that's great. What you can't do is defer the business decision you make in choosing those technologies to someone else. All technology choices have consequences and no-one knows what might be required a few years in the future or what your customers might ask for. Asking for software developed specifically for Windows to also be able to run elsewhere can give the impression that the aim is to avoid making a technology decision that could have possible negative consequences at any point in the future. Based on the nature of technology and the speed of change I don't feel that's realistic.

That said, if you want to build an xplat solution (and there are lots of people who do & reasons for that) because you either want to target multiple operating systems now, or may want to in the future, then that's a reasonable and understandable scenario. For that Microsoft have Xamarin. Or, if you'd prefer something with XAML more like UWP, there's Uno. (There's lots of other options too.) If, like me, you want to see Xamarin have better native support for building Windows apps, I don't think having WinUI try and do mulitple things is the answer.

WinUI is about more than just XAML and specific controls. It includes details of how those controls and the apps that are built with them integrate with the underlying operating system. If WinUI planning focuses on making Windows development on Windows the best it can be then that's a good case for having innovation and good future support. It's also likely to increase the chances people will want to continue using Windows and therefore it becomes important that it has solid support from multiple xplat solutions.

galvesribeiro commented 5 years ago

Regarding cross-platform (xplat) solutions. Xplat solutions are an abstraction over multiple native underlying systems. My understanding of WinUI is that it will be the native system for Windows.

Sorry but I don't feel that way...

Look at Flutter... It has a core engine that can render anything on any platform it supports.

On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.

So, that IMHO, that would be the best approach to make something cross platform and that at same time represents the underlying platform capabilities.

Mike-E-angelo commented 5 years ago

I don't think it's reasonable to assume that if you build something with native Windows technologies and then want to run it on a competing operating system then it's up to Microsoft/Windows to make that easy

Right... I think the point here that others are making is that this seems a bit backward/tone-deaf these days, especially in the context of starting a new application. Why would someone build a native Windows application when that only reaches a small % of the market? This is not a good use of capital.

If it's to maintain legacy Windows applications or to specifically make a Windows application, then yes I am in agreement with all of this and it makes sense. However, since there appear to be breaking changes and further investments involved, the value proposition of doing this vs. using Flutter has yet to be explained.

galvesribeiro commented 5 years ago

That is precisely what I'm saying...

For example, the flutter embedders for Desktop on both Win10 (WPF and UWP) as well as OSX are coming.

They are 100% managed by flutter runtime, but they are only using (for example) WPF/UWP to get the windowing management and Graphics pointer. All the rest is managed by the engine...

We've ported flutter engine ourselves to an embedded ARM device and I have to say it was an awesome experience. Why? Because it born to be portable and to run anywhere by letting the "embedder" to deal with platform specific implementation details on primitives like GPU, Software rendering, Input management, etc...

That is why I'm saying that WinUI by means of UWP: The empire strikes back is not going to work long term.

MSFT must come with something cross-platform, open, and portable. Just like they did with .Net Core, with Blazor, etc... Reinvent UWP/XAML will not going anywhere.

I believe XAML has a good potential if used properly in a sense where it is used to "describe" (or declare like some say) the UI. The "engine" build the render tree from it, and then dispatch the render commands to the underlying platform.

Like MSFT recently did with Chromium as the core for Edge, I believe WinUI (or whatever the name it became) could leverage Skia as it has backends for GL, DX, Vulkan, Software Rendering, FB, etc... Just by starting with that you have a HUGE potential of adding other platforms later...

MarkIngramUK commented 5 years ago

@galvesribeiro ,

Look at Flutter... It has a core engine that can render anything on any platform it supports.

On top of that, it has components that are fully implemented on Dart using the engine managed layer and that represents (draw/render) in pixel fidelity the platform and design language you want to use for example, Material.io and Apple's Cupertino.

Great, so as soon as Apple release an update to macOS, and the UI updates (perhaps button corner radius changes, or background gradients change, etc) your Flutter application doesn't update and continues to look like the previous OS - unlike a native control which would get the benefits for free.

galvesribeiro commented 5 years ago

@MarkIngramUK that is the work on the team to support updates.

Just like Xamarin team provide updates from day 0+1, this team could do the same. Google team does that as well...

By using the "native" control, you are back again on Xamarin world were you only do, wrappers (aka Renders)...

We're not discussing C# bindings to native controls (Like Xamarin does)... We are talking about a full UI framework like you do with Flutter...

galvesribeiro commented 5 years ago

For the record, nobody uses the "default" theme for any platform. They all create their unique UX on top of the design languages of each platform.

If you are so concerned about having alway look as the native component, your app probably will never have good audience as they would look... Meh...

MarkIngramUK commented 5 years ago

I believe we're talking about two different projects here. WinUI needs to be the Win32 replacement. People are asking for a cross-platform solution, which is reasonable, but I don't think it should be this project.

galvesribeiro commented 5 years ago

Also, Flutter allow you to use the "theme" on all platforms. So you can run Cupertino on your Win10 PC. A BIG example is Material design. It is a design language, not a set of controls. It can be used anywhere... It just happens that some platforms (like Android) has its native controls implementing it...

galvesribeiro commented 5 years ago

@MarkIngramUK

I'm just clarifying why WinUI should not be just a Win32 replacement, thats all.

If that is the case, then I'm pretty sure it will fall in a foreseeable future just like UWP...