-
Notifications
You must be signed in to change notification settings - Fork 674
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: New Top Level concepts for WinUI 3.0 (Window, ToolWindow, Taskbar Flyout, etc) #1323
Comments
Referencing my question about CoreWindow specifically. |
Referencing my proposal for borderless windows with transparent background #1247 |
I think the Window object, in particular, would be an excellent idea because this would allow developers using the new WinUI 3.0 Desktop app template to easily extend their app content into the titlebar. (Which is more difficult to do in Win32) The Window object should also provide an easy property to enable/disable the splash screen on a per-Window basis. |
Yeah, easily extending content into the titlebar is something I think UWP does fairly well and is definitely something we're keeping in mind for future windowing support in WinUI. @duke7553 do you mean the UWP |
@jesbis Yes, I'd like to see better splash screen support because the UWP concept of having a Window appear as soon as you invoke the app is likely better for usability. This aspect of the UWP app model should be part of WinUI Desktop when the Window object is developed. |
@marb2000 FYI for the win32/desktop splash screen scenario |
It needs to. I hate how even though Gears 5 is a Store app (Win32), it doesn't follow the UWPs use of splash screens. |
So CoreWindow will be contained within the UWP runtime, and WinUI Desktop will use the HWind interfaces. What does this mean for C# development, and other managed runtime languages? Will there be new APIs developed which offer the same CoreWindow experience (extend into title area, acrylic, window control re-colouring)? |
I just noticed that it is currently impossible to handle the taskbar back button if I use an AppWindow (the SystemNavigationManager API only seems to work for the main view). Additionally, no AppWindow related improvements seem to have been done for the last release (19H2) and even the next release (20H1). Why? |
AppWindow V1 has been in preview roughly a year already and still no change in sight. AppWindow/UWP Windowing V2 was briefly shown at Build 2018 (!), yet nearly two years later, nothing publicly is happening on that front. I recall at Build 2019 it was said AppWindow/UWP Windowing (V1/V2) would ship following WinUI 3, so for V2 we might still have to wait a year or even longer. Talked about at Build 2018, if we are lucky we might get UWP Windowing V2 before Build 2021....seems like another major API improvement was pushed back significantly which is very unfortunate. (See this talk from Build 2018, starting at 37:40 - When can I....) Also pinging @rkarman (who might still be working on the future of windowing in Windows) to share an updated roadmap with us if possible. Edit: Adding @clarkezone as well. |
Sorry for the delay in replying. AppWindow remains the forward looking strategy as witnessed by the fact it’s the primary way native windowing works on 10X but we are certainly behind where we wanted to be advancing it beyond v1 since the 10X project has taken all our dev cycles. We will hopefully have an update to share in the build timeframe. |
@clarkezone Thanks for the reply. Yeah, would be nice if you guys will be able to share an updated roadmap about AppWindow in a few months then with us. |
@clarkezone That's certainly understandable, and it's always delighting to hear those little tidbits about 10X. It sounds like a massive undertaking that all of the greatest Microsoft engineers are working on. (like yourself) You can bet I'm counting down the days until the availability of the 10X emulator! No rush at all, because I think we all appreciate the development effort going into these new top level WinUI components. |
The issue is that the AppWindow implementation has been left incomplete for a long time while the alternative (using multiple ApplicationViews) is basically broken (see bug #802). |
There are many problems with the application/window model on Windows, different frameworks and languages have different API's and behavior. Features are missing in one or the other. This stuff is way overdue. Some serious issues have existed from the start of UWP. Don't think it's just one thing or another. There are many issues that all need to be fixed. |
Note: During our last community call, Miguel Ramos mentioned that he's working on a Windowing spec for WinUI that will introduce proper types/concepts for application & window objects. The spec should be made public soon; he showed off parts of it on the call. Link: https://www.youtube.com/watch?v=tasbSc3771A&feature=youtu.be&t=2370 |
Proposal: New Top Level concepts for WinUI 3.0
Without the restrictions of the WinRT lifecycle and sandbox - there is a chance you could introduce new XAML elements for the App Window. Tool Windows that the new Windowing APIs make possible. For creating Task Tray Flyouts, and other common Win32 app scenarios that telemetry indicates is being developed and installed.
Rationale
Scope
Important Notes
WPF has the concept of a Window Object, and it should be possible to customise the window controls, frame, etc in a way that does not require recreating windowing behaviours and functionality, so mostly visual and templateable controls.
Open Questions
The community should contribute suggestions as to what kinds of core UI presentation they need, with examples of legacy apps they would like to move over to XAML UI. As well as App ideas that are prohibitively difficult to achieve today with WinRT/UWP
The text was updated successfully, but these errors were encountered: