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

Port (Framework)Extensions #6

Open
31 of 40 tasks
niels9001 opened this issue Mar 20, 2023 · 8 comments
Open
31 of 40 tasks

Port (Framework)Extensions #6

niels9001 opened this issue Mar 20, 2023 · 8 comments
Assignees

Comments

@niels9001
Copy link
Collaborator

niels9001 commented Mar 20, 2023

TODO

Base Porting Checklist

  1. niels9001

Extensions

Known issues

No tasks being tracked yet.

Future improvements

No tasks being tracked yet.

Notable Changes

@michael-hawker
Copy link
Member

@niels9001 originally we did a big push in 7.0 to flatten the namespace and remove 'extensions' so they were all consistent across the package for easy usage.

Context:

We could have the component/package maybe be called Extensions if we change the scope of what's inside it, but may want to think about still having a base namespace for some of these things?

@Sergio0694 thoughts?

@Sergio0694
Copy link
Member

Heyoooooo I see a new repo 👀👀👀

@michael-hawker Yeah, if we went back and added "Extensions" back it'd be a bit weird.
FWIW we also don't use "Extensions" in the .NET Community Toolkit.

@michael-hawker
Copy link
Member

Looking at the template that Niels copied I think he may have just used Namespace to mean package/component name? But will clarify in a quick-sync tomorrow. 🙂

@niels9001
Copy link
Collaborator Author

@Sergio0694 @michael-hawker Oh yeah, I basically just replaced the last bit of namespace from the previous template. So please ignore / update 😄!

@michael-hawker
Copy link
Member

Haha, yeah, I guess that line was a bit more specific to the Converters as they are in their own namespace anyway. (Maybe that's a separate discussion as to if they should remain there.)

Anyway, all good. We'll sort it out and can update these issues all together at our next sync.

@michael-hawker
Copy link
Member

#4 also needs the WeakEventListener and DispatcherQueue extensons. So we should port those over as well into the general base helpers/extensions place.

Should we have the extensions and helpers together as like a common folder/component name?

@michael-hawker michael-hawker self-assigned this Mar 22, 2023
@michael-hawker
Copy link
Member

We have some extensions in the base Microsoft.Toolkit.Uwp package merging those in with the extensions of Microsoft.Toolkit.Uwp.UI package here.

Then will create a separate Helpers component I think that contains most of the rest?

@michael-hawker
Copy link
Member

michael-hawker commented Mar 22, 2023

Currently have not brought over:

  • ApplicationViewExtensions
  • TitleBarExtensions
  • ScrollViewerExtensions.MiddleClickScrolling
  • WebViewExtensions

I believe the top two work differently in UWP vs. WinAppSDK, so probably need to look at more closely if it makes sense to have them. Also, I believe @niels9001 has some thoughts about Titlebar helpers in general we should investigate for a revamp, especially with the platform doing work to better enable custom titlebars, see microsoft/microsoft-ui-xaml#8137

The Middle Click Scrolling extensions are dependent on Windowing APIs, Input APIs, and Cursor APIs, which all work very differently between UWP and Windows App SDK, so not porting for now, as I don't think they work for Windows App SDK at the moment, so probably need more attention.

With WebView2 now, we should figure out if we need to remap these extensions or how that should work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 👀 In review
Development

No branches or pull requests

3 participants