Should we give and/or this library more generic?

[tuyen-vuduc]

At the moment, the library's name and description both target MAUI as the primary use. However, there are well-known or trending libraries/frameworks out there can benefit as well -- AvaloniaUI, UnoPlatform and even just .NET Android, .NET iOS, etc.

IMHO, this library should be a generic .NET libraries which can be used apps built with any libraries/frameworks as mentioned above, regardless of using MAUI or not.

Please share your thought.

[pictos]

@tuyen-vuduc,

In resume, we would say we don't want to take this huge responsibility to support all those UI frameworks...

The long answer and I don't speak for the rest of the team, it's only my point of view.

I would say that this is an amazing idea. I already ported some features to Uno and in most is just a matter of copy/paste and changing the shared layer, and I can see a lot of value in that idea... But the reality is: This project is maintained by passionate people that (first) trust on .NET MAUI, and we (core team members) do that in our spare time, and we don't receive any money for it. So, we have our regular jobs, our life, and free time, and still, we dedicate some time here. And to support a lib. like that we will need to spend even more time.

So, what I can say is, our project is under the MIT license, the most permissive OSS license (AFAIK), and with that, anyone can grab our code and re-implement it for any UI framework (just be aware to give us the credit for the code).

[tuyen-vuduc]

@pictos Thank you a lot for sharing your view.

Yeah, I agreed that this is the community contribution with MAUI passionate. I am also maintaining a set of binding libraries with and without paid, I understand your point. I agreed that this library is released un MIT license, hence anyone can make change and/or copy the source code. However, I believe if we can make non MAUI dependent parts to its own space, and make an extension point for the dependent parts so others can easily make use of this amazing effort the team made. Then if we can come to an agreement, we can set a timeline to make it happen.

Cheers.

[pictos]

Are you from Naxam? Wow, I used your work as a reference for some of my old apps. Thanks for that <3

Well, I can promise anything but let's see what others have to say (:

[tuyen-vuduc]

Yes, I am the main contributor from Naxam :) .

[VladislavAntonyuk]

I like the idea.
Option 1. The changes will be only in CommunityToolkit.MAUI.Core library. And as we extract something to another library there won’t be a lot if breaking changes (only namespaces).
How would you name the library?)

Option 2. To keep it simpler for us we can only reorganize the code and move all maui dependent code to CommunityToolkit.Maui repo. We won’t follow maui repo structure in that case.

Option 3. Can existing frameworks like Uno and Avalonia use core library? If yes, we should keep our library untouched.

[pictos]

I think that I'll play the Devil's Advocate here...

Isn't that easy... Everything in this project is Maui-oriented since our goal is to promote features to the main framework. Changing it to a general library will change this goal. But this is more a philosophical discussion I would say, but changing that will imply creating an entirely new lib.

If we talk about controls, we do everything Handler-oriented, Uno and Avalonia (not sure about Avalonia) use another approach, that's drawing controls instead of using the native ones. With that neither the interfaces we will reuse.

Talking about Essentials like APIs, we will need to support more platforms, because, Uno, for example, targets more platforms than Maui (wasm (isn't Blazor), WPF, macOS (besides mac-catalyst), and Linux) and we will need to implement (and maintain) code for that. And even if we do that, we still need to think in an abstraction that will make sense for all 3 which isn't easy to do.

Again, the idea is nice but the execution isn't, I think the best this lib can do is provide solid features and anyone that want to port it to another UI Framework will be able to do it

[VladislavAntonyuk]

we can still focus on Maui, just because our repo call CommunityToolkit.Maui and throw not supported exception (like we do for Tizen). Then community can implement that functionality.
The main issue with Linux support in .NET MAUI, is that it is not released as a workload. from my point of view, we should provide as many target frameworks as possible to allow users to install the library. Then it's up to them how to implement the interface or just use our implementation.

[pictos]

not supported exception (like we do for Tizen). Then community can implement that functionality.

Well, if I'm not wrong, we always ask the user or Jay to provide an implementation for Tizen, if it's possible. So, we don't throw for Tizen by default. And, IMHO, it shouldn't be done for others targets (it should only happen if the target doesn't support it). And again, if the team agrees to make it more generic, we shouldn't think about Maui just, but all platforms, so if one implements Linux, the lib should have a Linux implementation for that feature.

Also, we know that community, in general, doesn't engage in PRs... Relying on it isn't a good practice.

[bijington]

Is the proposal to make a generic toolkit for other UI frameworks in order to provide UI specific functionality (e.g. a Popup that works for all frameworks)? Or more underlying things like helping with MVVM setup, etc.?

I ask as we have the .NET Community Toolkit which covers the latter.

As for the former it sounds like a potentially huge undertaking to design something generic that can support all the different platforms/frameworks/paradigms. We struggle enough with the current workload so adding to that would not be a good idea in my opinion.

With that being said if there is a concept which we could follow in order to define a core library which others could use as the generic definition and provide implementations for other frameworks I wouldn't be against it. I agree it could be great as it could provide a common surface area for devs working on any of those technologies.

Perhaps the next step would be to provide some level of design to determine how this could fit across the multiple frameworks. Most likely just take a single control or feature and show how it could work.

[CliffAgius]

Closed as per the Community Stand-up discussion here: https://youtu.be/N9wMcBP4jtg?t=2889