[Spec] Naming updates

[PureWeen]

Naming Updates

Current Name	Old Repository Location	New Name(space)	New Repository Location	Package Names
Xamarin.Forms	src/Forms/src/	Microsoft.Maui.Controls	src/Controls/src/	Microsoft.Maui.Controls
Xamarin.Forms (test)	src/Forms/test/	Microsoft.Maui.Controls	src/Controls/test/	N/A
Xamarin.Forms.Maps	src/Controls/Maps/src	Microsoft.Maui.Controls.Maps	src/Controls/Maps/src	Microsoft.Maui.Controls.Maps
Xamarin.Forms.DualScreen	src/Controls/DualScreen	Microsoft.Maui.Controls.DualScreen	src/Controls/DualScreen	Microsoft.Maui.Controls.DualScreen
Xamarin.Essentials	src/Essentials	Microsoft.Maui.Essentials	src/Essentials	Microsoft.Maui.Essentials
Xamarin.Platform.Handlers	src/Platform.Handlers	Microsoft.Maui	src/Maui	Microsoft.Maui
Xamarin.Forms.Platform.*	src/Platform.Renderers	Microsoft.Maui.Controls.Compatibility.*	src/Compatibility/Renderers	Microsoft.Maui.Controls.Compatibility
Xamarin.Forms.Material (old)	src/Controls/Material	Microsoft.Maui.Controls.Compatibility.Material	src/Compatibility/Material	Microsoft.Maui.Controls.Compatibility.Material
Xamarin.Forms.Material (new)	src/Controls/Visual	Microsoft.Maui.Graphics	src/Graphics	Microsoft.Maui.Graphics

Additional library clarifications

Xamarin.Forms

All libraries that are being brought forward (Maps/DualScreen/Xamarin.Forms) will just become Microsoft.Maui.Controls

Xamarin.Forms.Platform.(iOS/Android/etc..)

These will all move to a Microsoft.Maui.Controls.Compatibility and will be packaged into compatibility packages that are built against NET6. This will allow users to still use older style renderers if they have custom renderers. Legacy renderers will shim into the handler architecture with minimal changes

Xamarin.Forms.Material

The material libraries are going to be replaced with drawn controls so the current renderers using google sdks aren't going to be brought forward to Maui. The existing ones will be packaged into a Microsoft.Maui.Controls.Compatibility.Material package

The new Material will just be a set of handlers that can be used by other UI Frameworks and will have no dependency on Forms. Currently we are calling this library Microsoft.Maui.Graphics but that name is subject to change

Package Dependency Tree

• Microsoft.Maui.Controls
  • Microsoft.Maui.Essentials
  • Microsoft.Maui
• Microsoft.Maui.Controls.Maps
  • Microsoft.Maui.Controls
  • Microsoft.Maui
• Microsoft.Maui.Controls.DualScreen
  • Microsoft.Maui.Controls
  • Microsoft.Maui
• Microsoft.Maui.Essentials
  • Microsoft.Maui
• Microsoft.Maui.Controls.Material
  • https://github.com/jsuarezruiz/GraphicsControls
  • Microsoft.Maui
• Microsoft.Maui.Controls.Compatibility
  • Microsoft.Maui
  • Microsoft.Maui.Essentials
• Microsoft.Maui.Controls.Compatibility.Material
  - Microsoft.Maui.Controls
  - Microsoft.Maui
• Microsoft.Maui

[Redth]

src/maui -> src/Maui 😬

[Redth]

Do we need the src subfolder within Controls and Maps?

[davidortinau]

Could you expand this to the artifact name changes as well? The assembly and/or NuGet package (where applicable) names.

[Redth]

Perhaps a dependency tree map of the packages included in that too

[AmrAlSayed0]

Xamarin.Forms.Material

The material libraries are going to be replaced with drawn controls so the current renderers using google sdks aren't going to be brought forward to Maui

Drawn controls? What does that mean? From scratch? Like on a canvas?

[Cfun1]

Drawn controls? What does that mean? From scratch? Like on a canvas?

https://github.com/jsuarezruiz/GraphicsControls

[PureWeen]

@Redth

src/maui -> src/Maui

Fixed

Do we need the src subfolder within Controls and Maps?

I added another row to the Maui.Controls row for clarity. Right now there are two folders that represent the content for Controls which is the src and the test

https://github.com/dotnet/maui/tree/main/src/Forms

Maps maybe? It's sort of future proofing it for the case where we are going to add a test folder to maps for more platform tests. It's basically just following the format of the other projects

[PureWeen]

@davidortinau I added a column with package names

@Redth I added a package dependency tree

[sacdevops]

@PureWeen Since you've entered material, isn't fluent and Cuppertino missing? https://github.com/jsuarezruiz/GraphicsControls is not just material.

Now I'm a little confused about the structure. Found the first names much more understandable when they were announced.
It was planned
Xamarin.Forms -> System.Maui
Xamarin.Essentials -> System.Devices

[PureWeen]

@sacdevops I didn't add Fluent/Cupertino because the main first focus will be to have a replacement for Material. I'm not sure what state Cuppertino/Fluent will be in for the first release

Xamarin.Forms -> System.Maui

This was never really the plan. System.Maui was always going to be the root namespace but then Forms would be under a different namespace because it's a UI paradigm on top of Maui

Xamarin.Essentials -> System.Devices

Yea this plan changed :-)

[domagojmedo]

I Like System.Maui more. Something about namespace starting with System gives me more confidence in it, makes it sound like it's mature and here to stay 🙂

[dotMorten]

I don't like Maui in the root namespace and it goes against naming guidelines. I'd suggest Microsoft.Maui.
Also don't like Xamarin.Forms is not being renamed even if it is considered legacy.

[vhugogarcia]

I like the idea from @dotMorten . By having the namespace Microsoft.Maui. So they may end up like:

Microsoft.Maui.Controls.Maps
Microsoft.Maui.Controls.DualScreen
Microsoft.Maui.Controls.Essentials

Additionally for the other I'd suggest to change the "Material" to something more generic, due to at the end of the day GraphicsControls are about User Interface:
Microsoft.Maui.Controls.UI

Let me know your thoughts. I just wanted to share my grain of salt.

[saint4eva]

• Maui

• Maui.Controls.Material

  • https://github.com/jsuarezruiz/GraphicsControls
  • Maui

• Xamarin.Forms.Legacy

  • Maui
  • Maui.Essentials

• Xamarin.Forms.Material.Legacy

  • Maui.Controls
  • Maui

• Maui

What about the System.Devices and System.Graphics?

[saint4eva]

Xamarin.Forms.Material

The material libraries are going to be replaced with drawn controls so the current renderers using google sdks aren't going to be brought forward to Maui

Drawn controls? What does that mean? From scratch? Like on a canvas?

Similar to Skia and Flutter drawing

[sacdevops]

Personally, I don't find the Microsoft.Maui namespace appropriate. Maui is supposed to be more of a multi-platform, so the name Microsoft would not fit as a namespace. The word System is neutral and would be more in line with the other established namespaces. Shouldn't be an outsider.

Stop bullying namespaces. 😄 😄

[saint4eva]

@sacdevops I didn't add Fluent/Cupertino because the main first focus will be to have a replacement for Material. I'm not sure what state Cuppertino/Fluent will be in for the first release

Since GraphicsControl support the three visuals, why relegating other design visuals?

Xamarin.Forms -> System.Maui

This was never really the plan. System.Maui was always going to be the root namespace but then Forms would be under a different namespace because it's a UI paradigm on top of Maui

Which Form are you talking about?

Xamarin.Essentials -> System.Devices

Yea this plan changed :-)

It is going to bring some confusion.

[saint4eva]

Personally, I don't find the Microsoft.Maui namespace appropriate. Maui is supposed to be more of a multi-platform, so the name Microsoft would not fit as a namespace. The word System is neutral and would be more in line with the other established namespaces. Shouldn't be an outsider.

What about AspNetCore? Microsoft.Maui is still appropriate for a namespace than Maui.* being a root name. Bye the way, I do not know why Xamarin.Form is littering the entire namespace - I thought we are getting rid of Xamarin.Form?

[dotMorten]

Maui is supposed to be more of a multi-platform, so the name Microsoft would not fit as a namespace.

Hence why I said Microsoft not Windows.

The naming guidelines state this for namespaces:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

[sacdevops]

@dotMorten You are right. It makes more sense to use Microsoft also. 👍

[dansiegel]

I tend to agree... Maui as the root is a terrible idea and really does seem to break naming guidelines.

I do not think that the root necessarily makes the most sense to have uniform across all products. For instance, Essentials really should have a System root, and be decoupled from Maui as it is still something you may find yourself using while building a fully native app.

For Maui itself, there are good arguments for why it should be System, and why it should be Microsoft. For instance, Wpf uses the System root for System.Windows, and there is a degree to which it would make a lot of sense that a core built into the System namespace is a Multi-Application-UI framework. At the same time, there are a number of valid arguments that this should be under the Microsoft namespace, as we've already seen in this thread...

[Paul-Schroeder]

I think @dotMorten is right that it should be Microsoft and I'm glad to see @sacdevops concurs after additional consideration. Also, @dansiegel makes a good point about using the "System" root for Essentials. Finally, using "Microsoft" will lend the same confidence/maturity that @domagojmedo is looking for in the above comment.

[mattleibow]

@saint4eva the System.Devices name is not very accurate as there are many more things that have not much to do with the device. Technically, the sensors are not devices. Or, Auth. That is not device things. Maybe essentials is not perfect, but devices is limiting.

However, essentials is too vague I would say.

[sacdevops]

@Paul-Schroeder Did you want to win the hearts of all of us with one sentence? You succeeded, you chamois. 😂 😂 👍

[dotMorten]

@mattleibow sensors are devices in the way System.Devices are used today. I think that's a great place to put that.

[KSemenenko]

If we're talking about namespaces, I don't like MAUI at all.
I've noticed several times that some of my colleagues and clients don't understand how to pronounce it.
It also sounds like Mowgli.

I also think that Microsoft will be better.
For example as well as
Microsoft.AspNetCore.Http.*

[sacdevops]

@KSemenenko I'm also not a friend of the name Maui, so I started a discussion

#340

Make your offer, how you would name it.

[serkonda7]

I don't think you should discuss the namespace spec as long as #34 is not resolved.

[sacdevops]

@serkonda7 That is one of the reasons why I started a discussion for a rename. You can share your opinion their too.

[dotMorten]

@Happypig375 Not sure why you think we aren't being listened to. The Xamarin team are probably the most proactive in that regard, but majority rule doesn't trump API reviews. The .net team has been very clear on that before. That's a good thing and why .net APIs generally are so consistent.

[Happypig375]

@dotMorten You are only saying this because you agree with their decision.

[sacdevops]

@Happypig375 Not sure why you think we aren't being listened to. The Xamarin team are probably the most proactive in that regard, but majority rule doesn't trump API reviews. The .net team has been very clear on that before. That's a good thing and why .net APIs generally are so consistent.

Okay that is not true with most proactive, but I support dotMartens answer @Happypig375 . We have other problems that has to get fixed. At least it's just a name and is not disturbing your coding.

We have bigger problems like it's a TextBox not Entry! 😂 So please. Don't fight anymore about the name. System.UI would not work, because System means that every feature method in this is a part of the system self. But we're using Drawing Controls, means we're using a third party library not the native UI of a OS. Microsoft.Maui or Microsoft.UI is enough and I think this issue should be closed for discussions. Create a discussion and we can talk their more about this.

[Happypig375]

@sacdevops Does #161 look like there is official adoption? That is the catch-all for control name alignment and no progress is being done.

Also, it's been made clear that native controls will continue to be available like in Xamarin Forms. So I don't know what you're talking about.

[sacdevops]

@Happypig375 Yeah native controls will be supported, but we will have non-native controls also. So make is more sense to put them all in Systems, where non-natives be not a part, or in Microsoft.Maui e.g. where both be acceptable.

System.UI makes no sense for me. We can put System.Web.UI into System.UI and maybe some animated gifs also and we get a Fiesta 🎉.

Why it should be a problem when it called Microsoft.Maui and not System.UI? Where are the pro's when we call it System.UI? Will developers get high coding skills? I mean you dont write the namespaces also not per hand. Visual Studio makes it for u. 🤷🏻‍♂️ I don't see any added value in here. There will always be people who won't like it. You can't please everyone.

The original problem, why I also commented on it here, is that only Maui.Controls, for example, is not appropriate and it should be under System or Microsoft. Whether it is under System or Microsoft is irrelevant. These are children's toys to be discussed about something else.

I am probably the youngest here and even I can see that there are unnecessary discussions.
As I said, and that applies to everyone, whether Communit member or part of the team, there are discussion areas and you can continue it there. Thanks.

[Happypig375]

@sacdevops
Whether something is "native" or not should not be a determinant on whether to put in the System namespace.
System.Net.Http.HttpClient has a managed implementation. It is still put in the System namespace because it is widespread enough. WPF is also built on the .NET Framework and is managed by design, but it uses the System.Windows namespace.

System.UI makes no sense for me. We can put System.Web.UI into System.UI and maybe some animated gifs also and we get a Fiesta 🎉.

System.Web.UI is for ASP.NET Web Forms which is deprecated and not even ported to .NET Core.

Why it should be a problem when it called Microsoft.Maui and not System.UI? Where are the pro's when we call it System.UI? Will developers get high coding skills? I mean you dont write the namespaces also not per hand. Visual Studio makes it for u. 🤷🏻‍♂️ I don't see any added value in here. There will always be people who won't like it. You can't please everyone.

The reverse is also true. You didn't bring up any argument for Microsoft.Maui. But, System.UI already has mass support in #41, unlike Microsoft.Maui.

I am probably the youngest here and even I can see that there are unnecessary discussions.

As you bring up unnecessary side comments on age.

As I said, and that applies to everyone, whether Communit member or part of the team, there are discussion areas and you can continue it there. Thanks.

I am writing in the thread for namespace renaming and your control renaming should go to #161.

[MichaelRumpler]

IMHO #34 and #41 should be clarified and closed first - that should have been done last summer. In fact I thought that was already settled and I'm surprised these issues are still open.

Apart from that I'd also prefer Microsoft.Maui. Maui alone could be from any company.

IMHO System.Windows for WPF and Windows.UI for UWP were mistakes because those frameworks were not THE only ones on Windows. The name of the framework should be in the namespace. That's also why System.UI is the worst name I can think of. Reserve that for the last UI framework which will work everywhere and be better than anything there ever was or will be.

Essentials is also difficult. It is not about UI so it should not be under Maui.Controls as somebody proposed. But System.Essentials or Microsoft.Essentials could be anything, so I'd go with @PureWeen and put it under (Microsoft.)Maui.

[filipoff2]

Maui is supposed to be more of a multi-platform, so the name Microsoft would not fit as a namespace.

Hence why I said Microsoft not Windows.

The naming guidelines state this for namespaces:

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-namespaces

if we fallow this logic :
https://stackoverflow.com/questions/35329402/system-web-mvc-vs-microsoft-web-mvc

If No System or Microsoft in namespace than Maui looks extremely weak as another preview, experiment ....

[Happypig375]

IMHO System.Windows for WPF and Windows.UI for UWP were mistakes because those frameworks were not THE only ones on Windows.

But they are the officially endorsed and promoted frameworks for Windows in the C# world, unlike other frameworks.

That's also why System.UI is the worst name I can think of. Reserve that for the last UI framework which will work everywhere and be better than anything there ever was or will be.

Then we will never use that namespace because we will never agree on "better than anything there ever was or will be".

[MichaelRumpler]

IMHO System.Windows for WPF and Windows.UI for UWP were mistakes because those frameworks were not THE only ones on Windows.

But they are the officially endorsed and promoted frameworks for Windows in the C# world, unlike other frameworks.

Nevertheless, I would have chosen different namespaces. E.g. System.Windows.WPF (as System.Windows.Forms was already used for WinForms) and System.Windows.UWP, Windows.UWP or Microsoft.UWP for UWP.

That's also why System.UI is the worst name I can think of. Reserve that for the last UI framework which will work everywhere and be better than anything there ever was or will be.

Then we will never use that namespace because we will never agree on "better than anything there ever was or will be".

Exactly! System.UI sounds like THE universal UI framework - which IMHO will never exist.

[mattleibow]

I see back and forth about System.UI and not and why not to use System. Not even the WinUI framework is using System anymore. They are Microsoft.UI. Since we are building on top of WinUI, we can't actually be System.

In fact, we have to be careful not to cause some issues with Microsoft.Maui and Microsoft.UI...

[hartez]

We have bigger problems like it's a TextBox not Entry! 😂

😂

Says the person who literally just entered non-text into a similar control. 😀

[knuxbbs]

What about the System.Devices and System.Graphics?

System.Device is already in use.

[mackayn]

@dotMorten Get's my vote. Microsoft.Maui.

[pictos]

I'm not sure if the Maui.Essentials is a good name for a namespace that will have platform APIs. It makes sense in the context of Xamarin.Essentials, but in Maui that loses its context.
I'm terrible with names, but I can think in

• Maui.Devices
• Maui.Tools
• Maui.Services

As mentioned by @mattleibow Maui.Devices couldn't be a good name but is better than Essentials

[andrewBezerra]

I think this namespace (Maui.Essentials) can be spliced into two at least, one called Maui.Sensors and the other Maui.OsInterop

[pictos]

@andrewBezerra good catch, and even more namespaces based on the groups of APIs, like Connectivity (for Bluetooth, wifi, etc), Sensors (GPS, accelerometer, etc), and so on.

[francoistanguay]

You could argue that Essentials has nothing to do with UI and therefore shouldn't be prefixed with Maui. The original plan to move to System.X made sense to a certain extent. Moving into a Microsoft.X could also have made sense.

Furthermore, Essentials being moved to something non-MAUI related, would not only clarify its intent, it would make it equal in terms of layer/concept to .net for iOS/Android, and would make it more likely to be reused/extended by other apps/platforms that don't need or want to have a dependency on Maui.

[pictos]

@francoistanguay good point, TBH I didn't think about the prefix. And since the .net will the xplat framework, makes sense to essentials belongs to another namespace outside Maui.

[MichaelRumpler]

Essentials has a dependency on Maui, it cannot exist without it. Therefore it doesn't make sense to move it out of the Maui namespace.

[francoistanguay]

Forgive my ignorance but what is the dependency? Infrastructure or actually related to interfaces in Maui's realm?

Can they be inverted or abstracted so to make Essentials more cohesive and less coupled?

[mattleibow]

It will probably become more connected than it is now. Right now there is a fair bit of duplicate functionality.

[jonlipsky]

I'm not sure Maui.Graphics is the best name for the Xamarin.Forms.Material code. Could I suggest Maui.Drawable? As someone who does graphics work, there is a difference between a graphics library and libraries for drawable controls.

[saint4eva]

I'm not sure Maui.Graphics is the best name for the Xamarin.Forms.Material code. Could I suggest Maui.Drawable? As someone who does graphics work, there is a difference between a graphics library and libraries for drawable controls.

Microsoft.Maui.Visuals

[francoistanguay]

Somebody asked me today why Xamarin.Forms "had to" be renamed to Maui.Something and why it "had" to cause this breaking change. Answer was obvious when/if moved to System.Something but now that this isnt happening, what reason should I give to existing XF devs as to why their stack changed namespace for no "apparent" reason?

Since efforts will be made to keep Maui as backward compatible as compatible, even if theory, you could argue that it makes sense to keep it in the Xamarin.Forms namespace, with acknowledged breaking changes between XF5 and what really is XF6.

Is it just to properly align with the marketing efforts around Maui or is there a more fundamental reason?

Don't want to stir an already lengthy debate but would like to have an official answer to share with some of our customers if there is one.

Thank you!

[PureWeen]

xamarin/Xamarin.Forms#13847