Impossible to create a custom ConsoleDriver

[veeman]

Hello guys, currently I need 24 bit color support for my console application.

In the past there was an attempt to bring this feature to Terminal.Gui (see pull #103).
But the code never get into the main branch.

So I thought I can just create my own ConsoleDriver with the source provided there and use the Application.Init to serve my class. However, this is impossible.

Although the abstract base class ConsoleDriver is public, you cannot derive it from outside the library because the Contents field is defined as internal abstract.

Moreover there are several such things where classes and field are defined internal making them inaccessible from outside.

To name some of them:

• internal class NetDriver
• internal class WindowsDriver
• internal static View Application.mouseGrabView
• internal static View Application.wantContinuousButtonPressedView

Due to the internality of the Application fields which also used by the ConsoleDriver
you get a second level of restriction which makes the whole thing unusable outside.

I would like to appreciate if the internal fields get defined as public as most as possible.
So everyone who wants a custom implementation of a class can access the required structures.
This would also improve feature testing and development outside the library more convenience.

[BDisp]

Why about implementing in the current ConsoleDriver and make available for all drivers and submit a pull request?

[veeman]

Im going to do this.

But im not sure what caused the already existing pull request to make it not into the main source code.
Are they any requirements to get a succesfull pull merge?
Or just no addaitional dependencies and running on all supported platforms?
Currently i can evaluate only on windows and mac machine.

Anyway the above issue persists. The implementation suggests an open interface that is not a real one.

[BDisp]

I think @migueldeicaza will not allowed that. The existing pull request was not an overall solution for all drivers. It's necessary creating the necessary abstracts properties and methods on the ConsoleDriver and implementing in each derived drivers. If you can evaluate on windows and mac machine, the WindowsDriver platform has solution and the mac machine, which probably you'll using ncurses, then the CursesDriver has solution too. If you can evaluate in both platforms, then the NetDriver will have a solution too. The best solution is using the RGB for all drivers.

[tig]

I am not sure @migueldeicaza had an issue with the PR in question. I think the PR just died because of a lack of interest (not from users, but the original PR author).

I looked at adding 24 bit way back when and found some things fairly deep in how color info was stored. I don't remember the details but I remember thinking "thar be dragons!".

think it's awesome @veeman is going to dive into this. Please let us know how we can help!.

[migueldeicaza]

Hello,

Generally I dislike exposing internal details because it ties our hands in the future.

I much rather incorporate true-color support directly into the library, which achieves the stated goal, but also gives us the freedom to change the internals in the future, without breaking any existing code.

[migueldeicaza]

Btw, I am liking this new notification system. I was overwhelmed by GitHub comments before and could not even keep up with anything. So this is great progress from the app/notification settings.

[BDisp]

With the PR #1770 is now possible to create a custom ConsoleDriver that can enjoy all the Terminal.Gui features. I think this issue can be closed.