Gui.cs: ConsoleDriver: Should it really be abstract?

[tig]

There is a LOT of common code across the three (now four with Fake) Drivers.

I was just thinking about how to fix bugs related to non-printable chars causing rendering issues on some terminals. For example, in Windows Terminal and Fluent if AddRune gets called with \n it does this:

The fix is to modify AddRune to look for non-printable chars like this, that may cause the underlying console to take action and replace them with the right glyph. E.g:

However, it's stupid to do this 4 times. Instead the base should implement the least-common-denominator functionality.

Right?

[BDisp]

Right. @migueldeicaza want to do all this stuff in the View, so drivers doesn't have to be magic. The Viewmust send the right format to the AddStrand AddRune.

[tig]

What if we did this:

• Gave View a Text property. Default Redraw would draw Text using TextAlignment
• Refactored Label such that it was nothing more than a renaming of View
• Refactored Button, etc... to leverage all the text handling in View.
• Window would need to leverage this too.

???

[BDisp]

I agree. We also have to redirect the Driverproperty to the Viewitself in order to deviate all the call to the Driver.AddRune and Driver.AddStr to the Viewand avoiding the views derived from Viewdo call Application.Driver.
I think that this have to change to another way:
public static ConsoleDriver Driver { get { return Application.Driver; } }
to like:
public static ConsoleDriver Driver { get { return View.Driver; } }
But I'm still studing. More thoughts???

[migueldeicaza]

I think this makes sense.

The abstract capability is more of an indicator that some holes need to be plugged by concrete implementations, but we could move common code here.