mdtauk commented 4 years ago

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

Templates for common UI scenarios, make it easier to develop or port app UIs
Common Templates will help maintain a consistent UI from day one.
Existing Win32 apps included with Windows, once moved out of the OS into the store, can gradually replace GDI UIs with WinUI Xaml versions. Having these as common templates makes this process easier.

Scope

Capability	Priority
Templates for common UI be included to maintain consistency	Must
Top Level objects allow for customised UIs where necessary, such as Ribbon apps	Should
Explore popular Win32 apps and scenarios and decide how WinUI should interpret these	Should
Examples of Win32 apps ported to use WinUI to replace legacy UI could be ready for WinUI 3.0 launch, acting as best practice examples for modernising UI	Could

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

lukeblevins commented 4 years ago

Referencing my question about CoreWindow specifically. https://github.com/microsoft/microsoft-ui-xaml/issues/1215

hansmbakker commented 4 years ago

Referencing my proposal for borderless windows with transparent background #1247

lukeblevins commented 4 years ago

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.

jesbis commented 4 years ago

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 SplashScreen APIs? That's currently part of the UWP app model and not the Xaml framework/WinUI per se. Is better splash screen support something you'd want to use for win32 apps as well?

lukeblevins commented 4 years ago

@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.

jesbis commented 4 years ago

@marb2000 FYI for the win32/desktop splash screen scenario

shaheedmalik commented 4 years ago

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 SplashScreen APIs? That's currently part of the UWP app model and not the Xaml framework/WinUI per se. Is better splash screen support something you'd want to use for win32 apps as well?

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.

mdtauk commented 4 years ago

Our approach is that WinUI 3 will use CoreWindow when running in UWP and Win32 Window(HWind) when running in Desktop (Win32).

WinUI 3 in UWP apps will be able to use AppWindow APIs. For Desktop, there will be needed to come out with something similar. We are still designing this, so I don't have more details so far. @marb2000

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)?

lhak commented 4 years ago

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?

Felix-Dev commented 4 years ago

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.

clarkezone commented 4 years ago

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.

Felix-Dev commented 4 years ago

@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.

lukeblevins commented 4 years ago

@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.

lhak commented 4 years ago

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).

Gavin-Williams commented 4 years ago

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.

ryandemopoulos commented 4 years ago

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

microsoft / microsoft-ui-xaml