proposal: MachConsole #1057

New issue

Open

opened 2023-10-06 07:48:11 +00:00 by mateli · 1 comment

mateli commented

2023-10-06 07:48:11 +00:00

(Migrated from github.com)

Required for this is a fast rich text component capable of displaying terminal graphics. Some other graphical components may be needed in order to make this software useful. Such as rendering a window inside of the application (when embedding it as a component) similar to JInternalFrame, buttons, checkboxes etc for settings.

There are several similar projects written in other languages but they are usually limited in what platforms they support.

This would be exceptionable useful when running directly on a framebuffer that cannot easily be shared by other applications. Then one would want a Mach application to embed a simple desktop environment so alt-tabbing between the main application and a console is possible. Same goes for any full screen application. In many cases it is of course possible to alt-tab between a game and a desktop application but we all know that it sucks.

Having a terminal window inside the game would be way more smooth than having to switch back to the main desktop environment if there even are one. Having to game the DOS way and quit a game to get back to the terminal is the norm on Raspberry Pi.

What would be a lot smoother is to compile several games into a single application and include MachConsole and a simple desktop environment. On Raspberry Pi or any other framebuffer system it would be a lot better than having to quit games. And systems that have a desktop manager it would still be cool to have such a solution.

As a minimum viable product create a hardware accelerated text based terminal emulator that works on all target platforms including web browsers. And more importantly it can be embedded as a component into other Mach applications that need it. Required for this is a fast rich text component capable of displaying terminal graphics. Some other graphical components may be needed in order to make this software useful. Such as rendering a window inside of the application (when embedding it as a component) similar to JInternalFrame, buttons, checkboxes etc for settings. There are several similar projects written in other languages but they are usually limited in what platforms they support. This would be exceptionable useful when running directly on a framebuffer that cannot easily be shared by other applications. Then one would want a Mach application to embed a simple desktop environment so alt-tabbing between the main application and a console is possible. Same goes for any full screen application. In many cases it is of course possible to alt-tab between a game and a desktop application but we all know that it sucks. Having a terminal window inside the game would be way more smooth than having to switch back to the main desktop environment if there even are one. Having to game the DOS way and quit a game to get back to the terminal is the norm on Raspberry Pi. What would be a lot smoother is to compile several games into a single application and include MachConsole and a simple desktop environment. On Raspberry Pi or any other framebuffer system it would be a lot better than having to quit games. And systems that have a desktop manager it would still be cool to have such a solution.

foxnne commented

2023-10-12 17:42:00 +00:00

(Migrated from github.com)

I think this also brings me to ask a tangential question: since mach-core is mostly feature complete for its scope, is the intent that Mach itself be modular enough that mach-core users could pull in individual pieces of mach?

I think something along these lines would be great for the interim before Mach has a GUI solution. I'm currently moving my other project (aftersun) to Mach-core and this time I'm leaving zgui behind. In the meantime, it would be awesome to have something I could easily add to my project for debugging: i.e. being able to write console commands to trigger different in-game functions. I think it would also serve as a great way to showcase text rendering as an example. I think this also brings me to ask a tangential question: since mach-core is mostly feature complete for its scope, is the intent that Mach itself be modular enough that mach-core users could pull in individual pieces of mach?