search

microsoft / WindowsAppSDK

The Windows App SDK empowers all Windows desktop apps with modern Windows UI, APIs, and platform features, including back-compat support, shipped via NuGet.
https://docs.microsoft.com/windows/apps/windows-app-sdk/
MIT License
3.85k stars 322 forks source link

Announcement: Proposed approach for windowing in Project Reunion #157

Closed rkarman closed 3 years ago

rkarman commented 4 years ago

Windowing in Reunion

We are excited to share some news with you today around the future of windowing for Windows developers. We have been listening to your feedback and concerns for this space over the years and we believe the approach we have chosen will address these in a positive way. This area has a lot of history (some of the features you use today, such as sizing and positioning windows, has been around since the first version of Win32) and a lot of investment in the developer community (your multi-windowed apps, your customized title bars, your customized dialogs and tool windows to create unique experiences, etc.) - we want to acknowledge and honor that as we go forward.

This post will outline our approach from a high-level perspective, our guiding principles, and our goals for the windowing space for Project Reunion. We are eager to get your feedback here, and we are open and ready to adjust our plans based on what you tell us. Nothing is set in stone - we are starting this journey here today, together with you.

A unified windowing space

In the past we have had two very different ways of "doing windowing" for Win32 and UWP - one very powerful but complex to work with even for basic windowing scenarios; one very limited in capabilities but easy to achieve the basics with.

For UWP we have been in a constant state of "catching up" on core functionality, and never being able to. While for Win32 we have been in a state of non-innovation, leaving developers behind because we have focused on bringing new features only to UWP where we can guarantee that guardrails are in place.

We heard you - this situation is not making anyone happy and moving between the two worlds is hard.

With Project Reunion we are taking a bold stance - we want all Windows developers to have the power of Win32 windowing at their disposal, but we also want to provide easy to adopt APIs that can provide consistent experiences across apps, as well as easy to use APIs that lower the bar of entry for new developers.

We also want the windowing model to be fundamentally the same, so that we create a familiar way of working for developers regardless if you chose UWP or Win32 as your application model.

Our approach in order to achieve this? A layered set of APIs.

Layers of APIs

We acknowledge that if you started with CreateWindowEx and used HWNDs for your app, you want to be able to continue to do so going forward. A re-write of your main window proc is just not going to be feasible. Therefore, we are bringing most of the windowing primitives from USER32 to Reunion. This gives you access to powerful APIs when you need them.

We also acknowledge that some things are really hard to do, or to get right for all situations, with the USER32 APIs, so we bring you AppWindow - a high-level windowing API surface that gives you access to a modern Windowing Model with an easier to use surface for areas where we have gotten a lot of feedback in the past, or where we want to help drive innovation, consistency in experience, or make it easier to adopt new features.

How is this different from the old Win32 vs UWP situation?

First, all these APIs are accessible to you regardless of process model - both UWP and Win32 have access to all the layers of the APIs. There might be some behavioral differences when calling the low-level APIs due to the security context of your app and whether it is running in a container or not. For example, the fact that we give you access to lower level APIs from UWP does not mean we give you access to other processes or their windows, you’ll only be able to modify your own windows - the security context for UWP is not changed.

Secondly, we are giving you the ability to freely move from one layer to the other regardless of where you started from.

Existing apps and their adoption to Reunion

For Win32 we touched on the approach already, by moving most of USER32 to Reunion we hope that you will have a straight-forward and easy path to adopt Reunion. Note that we are not saying that everything in USER32 will be available in Reunion and that there will be no work needed to move your Win32 app to Reunion - there will be parts of USER32 that will not being carried forward, but we will try to keep this to a minimum and limit the apps impacted.

For UWP the story is a little bit more nuanced. UWP have multiple windowing currencies, each with different limitations and life-time management. We are not going to preserve them all and move them to Reunion. As we mentioned earlier we are unifying the windowing model, this means changes to UWP that will require work. We are working through the details of the migration story for UWP depending on where you start from (CoreWindow, ApplicationView, AppWindow), and will start sharing that with you over the coming months. Our aim is to make it easy to migrate most UWP projects to Reunion for the windowing space, and we will do everything we can to help you come with us on the Project Reunion journey. If you have worked with AppWindow in UWP, you should be familiar with what we have in mind.

More details please!

We know that this post is light on technical details and completely lacks API shape information. This is intentional. We first wanted to share our approach for this space with you, to allow you to give feedback on this and influence it. As we align on the approach and start to move forward on the details, we want to design the APIs in the open together with you, not hand down a ready-made solution that we've designed in a vacuum. We hope you agree that this is the right approach, and we look forward to work out the details together with you for the initial release and for many years to come as Reunion grows.

Starting the journey together with you

Over the coming months, we will create functional and API specs here on GitHub and we are looking forward to a great partnership with the community. As a first step of this partnership we'd like to share our guiding principles and high-level goals for the windowing area as these will help inform everyone where we're coming from and what we're aiming for.

Guiding principles for Reunion windowing

We will support developers "where they are" – we will aim to support existing Win32 app developers with limited rewrite of their existing code; we will aim to support existing UWP developers with an easy transition from AppWindow and ApplicationView to Reunion windowing APIs.

We will design our new APIs with existing developers in mind, such that we do not leave existing Windows developers behind or alienate them with "yet another solution"; for developers new to the Windows ecosystem we will strive to have a low barrier of entry.

We will provide a full stack of APIs – powerful low-level primitives, targeted at expert developers that allow them to innovate and create experiences beyond our own roadmap and imagination; high-level scenario APIs that allow for any developer to light up our new features and take advantage of new form factors at a low cost.

Goals

  1. We will provide a global windowing currency across Win32 and UWP.
  2. Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.
  3. The windowing API for new projects, whether they be Win32 or UWP, will be a high-level, easy to use, API that follows modern development principles and patterns.
  4. We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.
  5. Developers shall have access to the full spectrum of windowing APIs (both high- and low-level) with as few restrictions as possible. Ex. there may be a need to avoid certain window messages, events, or calling patterns when mixing between APIs of different "levels".

Non-Goals / Negative Goals

Open Source

It is our goal to provide as much of the windowing stack for Project Reunion as Open Source as possible. We will listen to your feedback on what you need in this space and adapt as we move forward.

MarkIngramUK commented 4 years ago

Is there a plan for handling the pain (for Microsoft) of eternal backwards compatibility? As developers opt-in to Reunion it would be good to embrace the idea of deprecating functions in future versions, in order to provide the best APIs possible. Though I appreciate you probably don't want to think about past v1 release, I just wanted to point out how bonkers it is that Win32 still has support for 16-bit APIs (and even in UWP e.g. LocalAlloc and co).

sylveon commented 4 years ago

New APIs making use of LocalAlloc have been added as recently as Windows 8. LocalAlloc being present in UWP also hurts no one and makes porting old code easier, so it's a positive.

However I agree that we could drop some APIs like SetWindowLong (which is 1:1 replaced by SetWindowLongPtr)

riverar commented 4 years ago

Questions:

MarkIngramUK commented 4 years ago

I'm just advocating for allowing old APIs to be removed, or updated, and for new APIs to be added. I guess if Reunion is shipped with the app, that would be reasonably trivial to achieve.

smj389 commented 4 years ago

I'm just advocating for allowing old APIs to be removed, or updated, and for new APIs to be added. I guess if Reunion is shipped with the app, that would be reasonably trivial to achieve.

As Raymond Chen keeps reminding us, source compatibility is important to adoption. There is code out there that started with Win16 and is probably still with us today.

dpaulino commented 4 years ago

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

Regarding this goal, I noticed that Win32 was explicitly mentioned. For clarify, can someone confirm if UWP will also recompile to Reunion with limited code changes for the windows space? I apologize if the question doesn't makes sense, I'm still wrapping my head around Project Reunion

smj389 commented 4 years ago

Win32 apps shall be able to recompile to Reunion with only limited code changes for the windowing space.

Regarding this goal, I noticed that Win32 was explicitly mentioned. For clarify, can someone confirm if UWP will also recompile to Reunion with limited code changes for the windows space? I apologize if the question doesn't makes sense, I'm still wrapping my head around Project Reunion

We will provide a migration path from UWP AppWindow API onto the high-level Reunion Windowing APIs that is mostly automatable.

rkarman commented 4 years ago

Great questions Rafael! I'll try to address them as best I can.

  • What is a "windowing currency"? (Please use plain English in all outward facing comms.)

The object/construct you use to reference a window. In Win32 this is HWND, for UWP it is CoreWindow, ApplicationView and AppWindow depending on what APIs you are using. We want to make sure you can reference a window in the same way across the different app models, and also make sure that as a developer you don't have to think differently about a window based on what API created them.

  • What do you want from us? I presume this thread will just fill up with random complaints and feature requests. Is that what you want? Do you have any questions you need answers to?

I know that this announcement is light on technical details that may be needed in order for you to give deep and meaningful feedback on how this approach for windowing will work, benefit, or impact each of you and your specific app needs. But in general I want to bring windowing to top of mind of the community in order to set the stage for the specs that will start to show up for this space in the near future.

A couple of questions I want you to think about and try to answer as we continue the conversation (some of it on this post, some of it on new posts about specific features):

rkarman commented 4 years ago

Is there a plan for handling the pain (for Microsoft) of eternal backwards compatibility? [...]

We are thinking hard about this one. As I wrote above we are targeting "most" of the windowing primitives, not all. This is intentional - we will weigh app compatibility and usage against "cleaner platform" and potential tradeoffs of not bringing an API forward. As part of the next steps we will be sharing what we believe are a good "first set" to bring forward and have a communication with you to align and adjust as needed.

LanceMcCarthy commented 4 years ago

From an appearance standpoint, my hope is that I can still use the best of what CoreWindow offers, but with the flexibility of some Win32 window features.

For example, the most asked for things for UWP CoreWindow has been things like custom window geometry and real transparency.

Easy Acrylic is still amazing so we don't want to lose that, so imagine being able to combine Acrylic with custom geometry without needing to write a custom graphics pipeline.

mdtauk commented 4 years ago

Am I right in thinking that the initial version of this, when it is added to Reunion, will take us all back to the current windowing offered by Windows?

Are there plans and thoughts for adding new innovation to windows and windowing?

There was talk at Build 2018 I think, about actual new modern windowing concepts there were to come to UWP.
Will these come for all Reunion apps now?

And how far back will these innovations be supported, Windows 10 Threshold / Windows 8.1 / Windows 7?

image image

Felix-Dev commented 4 years ago

Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?

@rkarman When working on UWP apps specific pain points, compared to Win32 apps, for me have been so far:

smj389 commented 4 years ago

Being able to handle more than one window from the same thread / message loop is key in Win32 and is really missing in UWP (unless I missed an API).

mrlacey commented 4 years ago

one very limited in capabilities but easy to achieve the basics with

I always found the UWP windowing options to be more complicated than I would have liked. I would never have called them "easy". Making them ever "easier" in the future would be great.

The explanation of laying of APIs isn't clear. It sounds like all APIs will be available everywhere and does not explain how they will be layered.

How does https://github.com/microsoft/microsoft-ui-xaml-specs/pull/71 relate to this?

sylveon commented 4 years ago

Being able to handle more than one window from the same thread / message loop is key in Win32 and is really missing in UWP (unless I missed an API).

AppWindow allows that, but ContentDialog can only be opened once per thread at a time. Which means if you use that you're forced to use threads anyways.

Worse even, XAML islands in a thread currently leaks if I just exit the thread after the window is closed, so I had to implement my own thread pool to keep the message loop running once the window is closed (because the Windows thread pool doesn't do that) to allow the cleanup to be performed correctly. Fun times.

rkarman commented 4 years ago

Trying to reply to a couple of items in one go since this is not a threaded forum... I will also incorporate some of the feedback into the original issue so that new readers don't have to spelunk through the comments to get the some of the clarifications made here.

@LanceMcCarthy -

From an appearance standpoint, my hope is that I can still use the best of what CoreWindow offers, but with the flexibility of some Win32 window features.

This is right at the core of what we are aiming for with this strategy.

Easy Acrylic is still amazing so we don't want to lose that, so imagine being able to combine Acrylic with custom geometry without needing to write a custom graphics pipeline.

I can't yet detail the specific feature that can be mixed and matched between the layers here, but our goal is to limit the restrictions. So that, yes, if/when you are able to change the shape of your window with the lower level APIs you can do so even if you used a higher level API to say apply Acrylic.

@mdtauk -

Am I right in thinking that the initial version of this, when it is added to Reunion, will take us all back to the current windowing offered by Windows?

Not sure I parse this the right way, so please be patient with me as I try to answer it. Will you be able to do a lot more with windowing from UWP? Yes. With the initial version you will be able to do a lot of what Win32 apps can do today in terms of window customization and manipulation. But not to windows outside of your own process.

Will the high-level Reunion AppWindow object be more powerful than what is available in UWP today through CoreWindow/ApplicationView, and UWP AppWindow? Depends. We are working on the roadmap and engineering plan, but our intent is to make it available as early as possible and that might limit the amount of features we include in the first release. But we do have ideas and plans for more, which leads me into the next part:

Are there plans and thoughts for adding new innovation to windows and windowing?

Yes, there are. 😀 We have some interesting features that we want to bring to the world, but we are not yet ready to talk about some of them. As for the 2018 //build/ talk - yes, that was me doing that talk and that was the plan we had at that time. The high-level goals are still there in that we keep seeing innovation in user interaction and device types, and we want to make sure that our windowing model is capable of handling this.

But will all the features we talked about back then come to Reunion? Yes and no. Some feature are no longer relevant, some are being satisfied by access to the lower-level APIs, some are still on the roadmap though and when we are ready to we will bring them to Reunion. More details on the specifics as we start to publish specs and along with them a roadmap - which we will adjust based on feedback and needs of the community.

And how far back will these innovations be supported, Windows 10 Threshold / Windows 8.1 / Windows 7?

I am truly sorry to not be able to talk to this part in details just yet, but this is something that is being worked on across the Project Reunion as a whole. What I can say is that we will do our best to align with the larger project's goals to the extent that it is technically feasible. I hope to have more details to share during fall.

@Felix-Dev - Regarding the Title Bar customization - this is great feedback and something we will make sure is covered in the specs for that feature area.

When writing an app which will be run in the background most of the time, Win32 apps allow the running app's window(s) to be hidden from the taskbar. [...] Will this API be shipped and when?

This API will be part of Reunion. Not necessarily with that specific shape, but it is part of the requirements I have for the Reunion AppWindow, yes. There should be more info coming with that feature spec.

@mrlacey -

The explanation of laying of APIs isn't clear. It sounds like all APIs will be available everywhere and does not explain how they will be layered.

The higher-level APIs will all be built using the lower-level primitives. There will be no "black box" and completely different stack powering the higher-level APIs like today with the difference between CoreWindow and HWND.

How does microsoft/microsoft-ui-xaml-specs#71 relate to this?

XAML is a framework that builds on, and sometimes abstracts, platform constructs. As such it will in some cases provide it's own version of similar objects in order to provide developers with a familiar programming/object model. XAML is building on top of what we provide at the platform layer, and we are working across the teams to align between the different layers and make sure we can support each other's roadmaps and visions.

some general closing comments for this reply

For everyone on this thread - thank you for your comments and feedback so far, I really appreciate this.

If I've missed answering a question it is not on purpose, so please forgive me and let me know so that I can try to answer that too.

If there is something that is still unclear, please do not hesitate to tell me and I will do what I can to bring clarity (and again, I will update the original issue with some of the details from the comments here).

pjmlp commented 4 years ago

Sorry to say, but I got even more confused how things will shape up with Reunion.

Before Reunion's announcement it seemed that UWP adoption was in a slow and steady rate, but now with Reunion, replacement of C++/CX with C++/WinRT (with related productivity drop), uncertain future for .NET AOT with WinUI, alongside other attempts to drive UWP adoption, it seems to me that most of us are better off with outdated Win32, Forms and WPF until everyone at Microsoft can finally make their mind what Windows development should be like.

As for the proposal, it looks good, assuming it gets delivered and doesn't get dropped like many other Windows 8 - 10 related stuff.

MarkIngramUK commented 4 years ago

@rkarman will any new API additions be added to the OS as well as Project Reunion, for those of us that don't need to consider backwards compatibility? An area that I would love to see made simpler in Win32 would be custom title bars. In our apps we render 100% of the UI including the title bar and whilst we've already done it, it just seems like a hack (we have to process all mouse input by returning HTCLIENT because Windows prevents WM_LBUTTONUP for anything which isn't the Close button).

shaggygi commented 4 years ago

Is this part of the effort @marb2000 was doing for windowing with WinUI? For example, I recall there being some sort of proposal over on https://github.com/microsoft/microsoft-ui-xaml-specs.

UPDATED: Oops. Just noticed this was already mentioned.

ianhan commented 4 years ago

This document has hard line breaks at the end of each line which makes it hard to read when it wraps at larger font sizes. IMO this is always the way we should have done it - providing a glide path from Win32 so folks can make incremental progress on their giant Win32 apps. Big thumbs up.

wjk commented 4 years ago

I have some questions on the scope of this plan (which, by the way, I applaud). Will this mean that I can place arbitrary HWNDs in my AppContainer window, or arbitrary WinUI controls into my HWND? Will this mean I will be able to take an HDC from GDI+ and use APIs like those in Windows.UI.Composition on it?

Most importantly: Will there be a way to write drawing code under the assumption of 100% DPI, and have it automatically scaled up (locations, thicknesses, corner radii, everything) to look exactly the same at higher DPI settings without my having to do math with my locations/thicknesses/etc? WPF does this for me, but that technology has stagnated. While Windows Forms is much more active and lightweight, which is why I prefer it, high-DPI drawing in GDI+ is squarely the responsibility of the developer, and it’s hard.

Finally: You mention lifting some of the APIs in user32.dll into Reunion. Does this actually mean we will be (hopefully) seeing code in this repo that was once in user32.dll, gdi32.dll, or other files? If so, I can’t wait for the day when that code arrives. Thanks so much!

jtorjo commented 4 years ago

Does this mean we'll finally have the ability to place a window where we want on the screen in UWP? And set its state (minimize, restore, maximize)? That would be insanely awesome!

tringi commented 4 years ago

I feel I need to chime in here, although I'm not optimistic about the outcome. I also feel like I should be dishonestly strongly biased towards Win32, in hope that a proper middle ground were to be achieved, but I will try to refrain from it.

Also note that this all is written from point of view of a programmer, who writes Win32 apps that reguarly run on Windows Servers with PS/.Net/WoW uninstalled, in nano containers, and on old versions of the OS. I also might not be completely up to date with current development of Windows internals.

Subjective

The biggest problem of UWP windowing is that it's apparently done by young, passionate and optimistic people, who wanted so much more, much better windowing system than Win32 offered, but were (understandably so) scared away from expanding on Win32 by existing complexity. Who decided they could do better starting from scratch, but ultimately weren't able (for reasons irrelevant) to exactly and correctly duplicate the vast array of existing features and functionality.

As an user, if main window of the UWP app is sluggish, feature incomplete, and feels different then I'm going to be unreasonably critical to the rest of the App. And that doesn't even touch controls, buttons, etc.

Take a lack of Clear-Type text rendering as an example. On High DPI displays it's not that bad, yet usually still perceivable; but not everyone has those. On a simple app, with a few buttons, who cares, but it becomes issue if it's something you need to stare at longer or often. I mention this because for two decades, quality of text rendering is/was something that greatly differentiated Windows from other OSs for me, especially as a workhorse system that I have to stare at for 12 hours a day.

Speculative

That's why the whole thing failed. It's irrelevant if the underlying technology is great. Although it's not; simplest UWP apps still randomly crash, often from immediate unavailability of GPU memory, and you can't program reliable OOM behavior. It's also irrelevant if UWP is only way to access new APIs. That results in nobody using them; thank God for WinRT, but even that still seems like a band-aid in my scenario.

Constructive

I understand noone wants to touch USER32, but in order to move forward, you'll need to bite the bullet. And to make people like Raymond Chen or Larry Osterman do it. Or heavily review and supervise it. Perhaps also modernizing it by splitting USER32 to client/server, due to the way w32k is built is a source of continuous flow of security bugs, but that's not point of this topic.

My basic tl;dr would be: MERGE. Merge all windowing into USER32 (meaning the client part in regards to the previous paragraph) and merge all rendering to DWM.

Remove all the dozen of different window border/titlebar/sidebar types and reimplementations from UWP, and move them to USER32/DWM. Merge all similar. Where possible make those things a Common Control. Where not possible (titlebar styles) make those available under new window exstyles. OK, the bits are probably all used up, so through SetWindowLongPtr, it's not that hard to add a few DWORDS to WND struct, and branch in xxxDefWndProc.

Make this support granular. Not just single flag. Add simple API abstracting WM_GETMINMAXINFO, slighly more complex for typical use cases of WM_NCCALCSIZE ...and here, ffs finally after all those years fix window border rendering. It even affects File Explorer of all applications. I'll gladly provide guidenance and screenshots if it "Doesn't look like anything to you." ...hell, I'd probably work for free on anything I mention in this diatribe.

Next, move background brushes support to DWM. Again make it accessible to everyone through DwmSetWindowAttribute. It's just combination of blending bitmaps and blur shaders. There's no legitimate technical need for UWP App model in this.

DWM really could use some work anyway. E.g. improving DWM composition to handle transparency on more than single layer. Since Windows 8.1 we can have nested layered windows, so update DWM so that children windows too support no redirection bitmap and can be rendered by other means (accelerated DirectWhatever).

Next thing for DWM, to catch up to the other significant OS manufacturer, is support for (can't recall the proper term) flattening of all semi-transparent layers. I.e. DWM sending notifications (if registered for) to a window whenever the content behind changes, including the final bitmap, so that the application can render Clear-Type text (or any sub-pixel anti-aliased content) over it. There's of course a lot of space for optimization here, like not providing this during animations (where those parts would use fast grayscale AA), or if it's determined that the part of the backing texture for the window that will contain anti-aliased pixels is already opaque.

I might have been overthinking the above a little, but the point stands.

This Reunion initiative can be really great thing, if it starts addressing one of the major discontent of people who work with Windows and stare at applications for long hours. Inconsistency. Introduction of UWP (Metro, Modern, ...) style GUI added a huge amount of inconsistencies. Inconsistencies, even not perceived, increase mental strain put upon the heavy users. Focus on unifying GUI/UX and the positive response from public will surprise you.

Start fixing small stuff, basic stuff that's broken for years and should not be. Like window borders: breaking top border, bad transparency at 200% dpi, losing borders when extending client are to titlebar (the Explorer issue mentioned above). Fix default minimum window size so that minimize button isn't pushed out of bounds. Fix braindead resizing of taskbar icon, especially pinned, and add API to query proper taskbar icon size. Drop all those reinvented custom menus, merge them to CreateMenu API, merge the functionality for all to use, or at least (as a start) work hard on unifying the appearance and behavior. Right now you can get 5 different menu designs within 10 clicks from desktop on freshly installed Windows.

Okay, I'll stop now, it's already way too specific when you were calling for high-level feedback.

Concluding

Start doing the above, and you'll be on the right track.

Don't add Reunion as another windowing target. After plain Win32 we had MFC, WinForms, WPF, flavors of UWP, now WinUI. Nobody will bother to even try to learn another.

Otherwise, well, the in-browser apps and Electron-style abominations will take over the application ecosystem. It will became irrelevant what OS the regular user is running. Nobody will be actively choosing Windows, nor any other OS, they won't care which OS they use. Pretty logon screen won't change that. The legacy apps will start disappearing faster, rendering major selling point of backward compatibility irrelevant. And Windows-exclusive productivity, work and content-creation is only a small part of the market.

VagueGit commented 4 years ago

Thank you for sharing your plans. We have a UWP app in the store. We are beginning migration out of the store due to lack of third party tooling support for UWP. In defence of UWP, we have been able to offer our customers a brilliant look and feel that we were unable to achieve with our Win32 apps.

We are beginning our port with WinUI Preview 3. We expect the port to be a 6-9 month journey. Should we start building our new UI with Window or Page in order to make the Project Reunion journey easier for ourselves over this term?

marb2000 commented 4 years ago

@rkarman I have removed some End-of-lines in your post so people can wrap the text. I hope you don't mind :)

About the WinUI's Window work. Basically, the Microsoft.UI.Xaml.Window (MUX.Window) exposes a high-level Window APIs specifically to consume XAML. For example, this is the reason why there is a Content property of type UIElement. It uses the UWP or Win32 windowing APIS depending on the execution environment. For example, this code:

Window window = new Window();

internally does a Win32's CreateWindow call, generates the message loop, instantiates the XAML host, and so forth when WinUI 3 is running in Desktop. Project reunion will improve these underneath windowing APIs, so MUX.Window will be able to make use of it. It will simplify the WinUI's windowing code, or even we could deprecate WinUI's APIs if they don't make sense anymore.

Does this make sense?

VagueGit commented 4 years ago

@marb2000 Are you saying start with Window, not with Page as Page might go away?

Dhebug commented 4 years ago

Since everybody is commenting :)

I don't have any particular opinion about "Project Reunion", all I wanted to mention is that 100% of my application on the Windows platform are written 100% using the Win32 API, and I don't have any plans to change that any time soon, even for new projects, and the reason is that as far as I'm concerned this is the best API to use on Windows:

So yes, the API is not super pretty, it's not "modern" or "fancy", but it just works, and for somebody like me who write tools, it's what matters, because that means I spend more time on actually doing my work than in doing support.

I don't think people keep using Win32 because they are back in the past, they just use it because it's a sane choice that get the work done and will not be deprecated two, five or ten years later (I'm still actively supporting some tools that has change history that go back to 1997).

Side notes:

sylveon commented 4 years ago

I can agree to the sentiment: I've been trying to adopt WinRT APIs in my Win32 application and each time I've been severely burned by cryptic errors nearly impossible to diagnose, for example #101.

marb2000 commented 4 years ago

@VagueGit

Are you saying start with Window, not with Page as Page might go away?

Sorry, I didn't mean this. Page won't go away. Page is frequently used as a Window.Content in UWP and you can use it in Desktop as well. Page is a great pattern for Single Page Apps or scenarios that requires navigation history.

I was talking about the hypothetical case of MUX.Window having an API that is a dupe or subset of a new Reunion's Windowing API. Then, WinUI could consider mark it as deprecated (if possible).

VagueGit commented 4 years ago

@marb2000 Thank you for the clarification regarding Page/Window. Tools vendors who do not currently support UWP (particularly report writers) may have more work to do to support embedding a control in a Page, where they might already support a WPF Window. For us there may be greater chance of finding 3rd party tooling support for tabulated reports in the near term, if we migrate from Page to Window. Does that seem a reasonable reading?

marb2000 commented 4 years ago

@VagueGit

Tools vendors who do not currently support UWP (particularly report writers) may have more work to do to support embedding a control in a Page

Thinking aloud, they can expose the report as a UserControl or Control and this control can be hosted via Page or Window or other UI element, right? But I'm guessing because I didn't use a report component in years, so I'm not very up-to-date. I will let other coworkers chime about it.

VagueGit commented 4 years ago

Yes @marb2000 typically a Control, but the range of 3rd party controls for UWP is a subset of those available for WPF. It may well be a sandbox/permissions thing in UWP, but there was clearly a deterrent of some sort blocking tools vendors. There may well be a perception among tools vendors that the road to a WinUI Window is easier than to a WinUI page. Perhaps there should be a discussion/guidelines for tools vendors as part of the process.

JaiganeshKumaran commented 4 years ago

Currently Win32 apps need to handle full screen manually while UWP apps get it for free. Please provide a full screen API for Win32 apps since many implementations are bad. Similar to UWP full screen where you can hover on the top or bottom to see taskbar of titlebar, Win32 apps should also do that. Also all Win32 windows should support Shift + Windows + Enter by default without any dev work.

Poopooracoocoo commented 4 years ago

win32 apps don't have access to the UWP's CompactOverlay. win32 apps can keep their windows on top but it's not as easy to implement and they have issues with virtual desktops : https://bugs.chromium.org/p/chromium/issues/detail?id=841152 https://bugs.chromium.org/p/chromium/issues/detail?id=1016848 It defs aligns with Project Reunion's goals but then again, y'all also rejected updating those styles 🙄 *cough cough* #82

AzAgarampur commented 4 years ago

@Poopooracoocoo Since you just mentioned my proposal, I was thinking if #166 could also draw things like the UWP full screen button and handle full screen just like UWP. Maybe that's what you were already thinking.

sylveon commented 4 years ago

win32 apps don't have access to the UWP's CompactOverlay. win32 apps can keep their windows on top but it's not as easy to implement and they have issues with virtual desktops :

One of the main goals of this approach is to give Win32 apps access to CompactOverlay

Poopooracoocoo commented 4 years ago

@sylveon sorry, that comment was copied and pasted from a duplicate issue I made

prayaas-a commented 4 years ago

Does bringing a lot of the user32 APIs to UWP mean that you are more likely to adopt UWP for future projects?

Yes, for me. I've had a few projects I've started in UWP simply because it's a modern platform and it looks better. Somewhere down the line, I realized I didn't have the APIs or capabilities I needed.

Does this question imply that UWP is "here to stay"? If UWP apps do get support for a ton of missing APIs that have hurt WinRT since the beginning, it would be a much more viable platform. One would be able to use powerful APIs and still keep all the other innovations that UWP has - like sandboxing, app lifecycle, power management, security. Once Reunion is in a usable state, is Microsoft going to market UWP as the first choice platform for new Windows apps?

My concern here is - is Microsoft looking to modernize Win32 and sprinkle in innovations from the UWP world on to it so that UWP is no longer needed, or is Microsoft looking to make UWP powerful enough that it stands on its own? Currently, it seems like the answer is both - but I'm wondering long term when something new and not-widely-adopted like UWP could be possibly deprecated in favor of a better Win32 stack.

JaiganeshKumaran commented 4 years ago

@prayaas-a If your projects are internal then you can already use User32 APIs with some hacks.

Poopooracoocoo commented 4 years ago

would be nice if caption buttons in title bars faded on hover like win32 buttons: https://github.com/microsoft/terminal/issues/6293

VagueGit commented 4 years ago

My concern here is - is Microsoft looking to modernize Win32 and sprinkle in innovations from the UWP world on to it so that UWP is no longer needed, or is Microsoft looking to make UWP powerful enough that it stands on its own? Currently, it seems like the answer is both

One concern I think devs share is choosing the wrong option and having to start again. Like I think @prayaas-a is saying. We would like a single model which combines the power of Win32 with the gloss of UWP. Where we develop a store app we get a subset of functionality. Where we develop for desktop we get a different subset. But both should be from the same superset of capabilities so we can easily move from one to the other without learning a new tech.

JaiganeshKumaran commented 4 years ago

@VagueGit You can actually publish desktop apps to the store not just UWP apps and can use all functionality.

JaiganeshKumaran commented 4 years ago

@pjmlp No it doesn't. Windows 8 is an OS and WinRT is just a small part of it. There a lot of things that have changed not just WinRT.

JaiganeshKumaran commented 4 years ago

@jtorjo Windows NT 6.2 is Windows 8 not WinRT. WinRT is just a technology inside Windows 8. Windows 8 brings a lot of improvement other than WinRT. They did use WinRT technology for Metro but Metro isn't WinRT and Windows 8 isn't WinRT.

riverar commented 4 years ago

@Jaiganeshkumaran @jtorjo Please take your discussion elsewhere, you're spamming folks with notifications that aren't relevant to this thread.

Felix-Dev commented 4 years ago

The recent posts not revelant to this issue should be at least marked as off-topic or really just deleted (including this comment). @rkarman FYI.

huoyaoyuan commented 4 years ago

As you are evoluting the whole UI layer, I really want you to rewrite Visual Studio with it, to prove its functionality, and improve Visual Studio's performance. UWP was bound to a security model that's unsuitable for VS. But since you are going to decouple them, I want VS to be a real-world sample of best practices.

kmgallahan commented 4 years ago

I presume this thread will just fill up with random complaints and feature requests. Is that what you want?

I really want you to rewrite Visual Studio

@riverar 😂

Feel free to add my comment to the list of those that are off-topic and deletion worthy.

nCastle1 commented 4 years ago

I know this is about the API, but I'm wondering to what degree the API changes will involve implementation changes for UWP.

There is still a lot of jank with the UWP windows that causes problems that Win32/WPF/etc. apps don't have:

  1. Apps don't always respond to Window size changes; unique to UWP and affects even built-in apps like Bing Maps.
  2. UWP apps depend on explorer.exe running in order to function properly (e.g. respond to Window size changes). This is a bizarre dependency for modern apps
  3. Built-in window components (e.g. dialogs) don't handle mixed-DPI well; I'm not sure if that's due to the component implementation or the windowing system, but I haven't seen anything like it in Win32 apps.
1 2 3
n7JDOD3T6j dmbWyeqBtv PickerHost_dfPJadTrCy

Will UWP/WinUI windows under project reunion be built on the same foundations as the more reliable Win32 APIs?

riverar commented 4 years ago

@nCastle1 Regarding item 1: That's a long standing bug. Microsoft is very aware of it, and I always remind them of it.