Revisit Terminal.Gui namespaces

[tig]

Historically there's been a lot of debate/discussion about our namespace.

Right now, almost everything is very intentionally under Terminal.Gui.

I think we can do better.

One reason is the API docs are cluttered and hard to navigate:

Easy stuff:

• ConsoleDrivers - except for types directly exposed to Application and View almost all ConsoleDriver related types should be internal. These won't show up in API docs. But the rest, should probably be in Terminal.Gui.ConsoleDrivers
• Application - We've made great strides in decoupling Application. I think it can go in Terminal.Gui.Application.
• View - We've made great strides in decoupling View. I think it can go in Terminal.Gui.View.
• Configuration - Should it be in Terminal.Gui.ConfigurationManager?
• ... etc...

I get confused about all this and I know I go back and forth.

What do other contributors think?

[BDisp]

I get confused about all this and I know I go back and forth.

What do other contributors think?

Namespaces are great to ordering API's but when a oficial release version is published it's needed very careful about moving them to another folders, supposing that namespaces representing the real path in the solution, causing breaking changes.

[tznind]

Application - We've made great strides in decoupling Application. I think it can go in Terminal.Gui.Application.

We should make sure to avoid naming a namespace the same as a class e.g. Application as it causes lots of annoying things - like having to fully qualify type name.

For the drivers and Application, I think you can probably just lump them together under
Terminal.Gui.Internals or Terminal.Gui.Engine or even just Terminal.Gui.Drivers.

You can mostly solve this with adding an 's' e.g. Terminal.Gui.Views.

That said I don't know that we want to put the views in seperate namespace. If you think about the most basic use cases for Terminal.Gui its:

• Create an application
• Show some controls
• Register some event handlers

If you have to import 2 namespaces to do this (Terminal.Gui and Terminal.Gui.Views) then it is extra work.

I think the primary goal of a namespace is to split different areas of the library that the user might be interested in. So we should identify these use cases and split accordingly.

Like if there are a lot of classes to do with Drawing then make that a seperate namespace as most people will not be customising that and it confuses the main namespace with low level classes.

[tig]

How's this?

Proposed Namespace Structure for Terminal.Gui v2

Terminal.Gui.Core

• Application
• View including
  • Pos
  • Dim
  • LayoutStyle
  • LayoutEventArgs
  • Orientation
  • etc...
• Clipboard

Terminal.Gui.Views

• Button
• Label
• CheckBox
• TextField
• Window

etc...

Terminal.Gui.Input

• Command
• Key
• KeyBindings
• MouseEventArgs

etc...

Terminal.Gui.Drawing

• Cell
• Point
• Size
• Rectangle
• Thickness
• Attribute
• VisualRole
• Color
• Scheme
• LineCanvas

etc...

Terminal.Gui.Text

• TextFormatter
• RuneExtensions
• StringExtensions

etc...

Terminal.Gui.Drivers

• IConsoleDriver
• ConsoleDriver
• WindowsDriver

etc...

Terminal.Gui.Configuration

• ConfigurationManager
• SourcesManager
• SettingsManager
• ThemeManager
• SchemesManager

etc...

Terminal.Gui.Resources

• GlobalResources

Terminal.Gui.FileServices

• IFileOperations

etc...

[tig]

That said I don't know that we want to put the views in seperate namespace. If you think about the most basic use cases for Terminal.Gui its:

• Create an application
• Show some controls
• Register some event handlers

If you have to import 2 namespaces to do this (Terminal.Gui and Terminal.Gui.Views) then it is extra work.

I think the primary goal of a namespace is to split different areas of the library that the user might be interested in. So we should identify these use cases and split accordingly.

Yes, and there's a desire (at least by me) to be able to PROVE that built-in Views do not use internal APIs. Putting all built-in Views in a Terminal.Gui.Views namespace will (I think) also make it trivial to test this?

[tig]

Latest in #4109