Has a graphical mode ever been considered ?

[thradams]

By graphical mode, I mean, for instance, on Windows a render that uses GDI. (No changes in the concept)

The I way I think it could be done is cloning the console functions used by Turbo Vision implementing these functions using Windows GDI.

I personally would prefer to use Turbo Vision in that way, as normal app I think it could bring some advantages.

[ziotom78]

I am just a user and not the leading developer. Still, I want to share my two cents: This would make Turbo Vision no longer portable on Linux and Mac and barely usable over an SSH connection, making the project much less appealing to me.

If you are interested in graphical applications, have you tried Lazarus?

[okbob]

út 12. 11. 2024 v 15:24 odesílatel Maurizio Tomasi @.***> napsal:

I am just a user and not the leading developer. Still, I want to share my two cents: This would make Turbo Vision no longer portable on Linux and Mac and barely usable over an SSH connection, making the project much less appealing to me.

If you are interested in graphical applications, have you tried Lazarus https://www.lazarus-ide.org/?

or maybe another solution - this port of Turbo Vision can be executed over ncurses. There are fork ncurses, pdcurses, that support execution as GUI application. But the look looks the same.

I don't think the execution of Turbo Vision in GUI makes any sense. It is designed for DOS text interface - it expects regulat char width, so there are a lot of issues to redesign it as a framework for GUI. For C++ there are a lot of modern or widely used frameworks for GUI.

— Reply to this email directly, view it on GitHub https://github.com/magiblot/tvision/issues/167#issuecomment-2470674146, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO47PF6PHJQEDXKB3EKT2AIFR3AVCNFSM6AAAAABRT6SNZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZQGY3TIMJUGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[thradams]

I don't think the execution of Turbo Vision in GUI makes any sense. It is designed for DOS text interface - it expects regulat char width, so there are a lot of issues to redesign it as a framework for GUI.

My suggestion was to keep the font size and keep it monospaced etc. 1-to-1 initially. (A way to change the font size in runtime could be useful, but this is optional)

[okbob]

út 12. 11. 2024 v 18:41 odesílatel Thiago Adams @.***> napsal:

I don't think the execution of Turbo Vision in GUI makes any sense. It is designed for DOS text interface - it expects regulat char width, so there are a lot of issues to redesign it as a framework for GUI.

My suggestion was to keep the font size etc. 1-to-1 initially. (A way to change the font size in runtime could be useful, but this is optional)

Then what is an expected benefit? Today almost nobody uses real text mode, and almost all users uses terminal - so at the end, the GUI is used

— Reply to this email directly, view it on GitHub https://github.com/magiblot/tvision/issues/167#issuecomment-2471180589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFO477RLF5ONEL7WOY4PT2AI4UFAVCNFSM6AAAAABRT6SNZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZRGE4DANJYHE . You are receiving this because you commented.Message ID: @.***>

[magiblot]

Hi @thradams!

If I understand you correctly, you are talking about the same which SET's port of Turbo Vision does by default on Unix: to have a graphical window where the application gets rendered using a monospace font. Thus, the application is still text-based but it interacts directly with the native windowing system.

Although since I started this project my focus has always been on making Turbo Vision work as a regular terminal application, I took care not to make any assumptions in the source code that would prevent such an approach from being implemented as well. It is technically possible and it is not exclusive of the current behaviour.

However, I see some important disadvantages to it. Unless you put a lot of work into it, you miss the ability to customize the font, the font size and the color palette which is already provided by terminal emulators (including Windows' built-in console, which since Windows 10 has become far more usable than it used to be). Because of this, I never intended to implement such a thing myself.

[thradams]

Thanks for the reply.

Thus, the application is still text-based but it interacts directly with the native windowing system.

Exactly.

I took care not to make any assumptions in the source code that would prevent such an approach from being implemented as well

I was wondering how much work. I have the knowledge to implement this kind of stuff on windows but I don't know the details about what interface I need to implement. and also don't know how many hours I need. But I wanted to know opinions about it.

I can see several advantages. It opens the door for many other implementations. It could run in browser for instance. It could have animations, shadows (everything keeping the concept of text based as I said before). This kind of stuff can be optional if someone wants "retro effect". Zero screen flickering. (at least on windows where I tested) It also would remove the "Tab" I can see on windows, leaving just the app name (like normal app)

I like Turbo Vision, I think it should have a modern version of it but keeping the "retro" felling. For instance, for a text editor we could have font squirrels in a modern version of it.

[magiblot]

Hi,

There is not a public API for this, so if you want to give it a try I suggest you start by adding your code to the library's internals. If the results are good, we'll later find a way to integrate it properly.

You have two options:

1. Rewrite the Platform class from the ground up and implement just your use case.
   • It is used directly by THardwareInfo.
2. Keep the current Platform class and just add another implementation of the ConsoleAdapter class.
   • On Windows, the current implementation of Platform relies on WaitForMutipleObjects in order to wait for input events.
   • Currently, the Platform destroys the ConsoleAdapter when the application gets suspended (when going into the shell). This behavior is likely not fit for your use case, but you can ignore it for now.
   • You would have to change the Platform::createConsole function so that your ConsoleAdapter is used.

In either case, you will have to provide an implementation for Platform::charWidth, which returns 0 for combining characters, 1 for normal characters or 2 for double-width characters. See the Platform::initEncodingStuff function.

Do not hesitate to ask for help if you need it.

Cheers.

[thradams]

Thanks for the details. (I think this issue can be closed)