Skip to content
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: Add labels like [UWP] and [Win32] for easier issue grouping #19

Closed
Felix-Dev opened this issue May 19, 2020 · 7 comments
Closed

Comments

@Felix-Dev
Copy link

"Project Reunion" targets both UWP and Win32 and we are already seeing issues for both app types. As such, for easier grouping and filtering of issues, it could be useful to have labels like "UWP" and "Win32" to clearly indicate which proposal/question is targeting which app type.

@mdtauk
Copy link

mdtauk commented May 19, 2020

What about issues that are aimed at both platforms? Include both labels?

@Felix-Dev
Copy link
Author

@mdtauk Would make sense to me, yes.

@jonwis
Copy link
Member

jonwis commented May 19, 2020

Ideally, Reunion targets both Win32 and UWP. Anything we add should support both - Reunion aims to be identity, packaging, isolation, and lifecycle transparent.

Can you give an example (maybe using the current set of issues) of which tags you'd put on items, and why?

@mdtauk
Copy link

mdtauk commented May 19, 2020

Ideally, Reunion targets both Win32 and UWP. Anything we add should support both - Reunion aims to be identity, packaging, isolation, and lifecycle transparent.

Can you give an example (maybe using the current set of issues) of which tags you'd put on items, and why?

In the WinUI repo there is a discussion about different types used for things like Rect and Point - so if one API behaves oddly in either Win32 or UWP - then the issue would be asking for a fix for one over the other.

@Felix-Dev
Copy link
Author

Felix-Dev commented May 19, 2020

@jonwis I was hoping "Project Reunion" would also cover APIs like AppWindow V1/V2 for UWP, to provide a similar powerful experience like the Win32 Windowing APIs. (Not all win32 features might be brought over due to the sandbox.)

The File I/O issue #8 for example is really just relevant for UWP as it "already works" for Win32 apps.
The Startup issue #10 for example seems mainly aimed at unpackaged win32 apps and thus would probably not be relevant for UWP.

As such, it seems reasonable to me to differentiate between UWP and Win32 issues here as I imagine many (future) issues will be about bringing APIs from one side to the other (Win32 to UWP or vice-versa).

@jonwis
Copy link
Member

jonwis commented May 19, 2020

Can you add a specific "feature request" for "AppWindow-like Win32 window positioning support"? Helping HWND based apps go full-screen or picture-in-picture or "move to the left monitor" and others are definitely useful bits of functionality for even non-UWP apps.

Thanks for the suggestions - we'll noodle on ways to organize "make X thing available to Y" in tags.

@jonwis
Copy link
Member

jonwis commented May 21, 2020

Thanks, I added the UWP (support for UWP apps) and Win32 (support for Win32 packaged and unpackaged) apps labels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants