AndrewAPrice wrote:
A GUI takes more effort because even after you're in the video mode itself, you need to deal with drawing fonts, navigation, layouts, etc. While a raw text mode CLI is the easiest thing because you just printf whatever and display it sequentially. For this reason, most OS's here start with a text mode CLI and most OSDev tutorials start by printing Hello World to 0xb8000.
Yeah. Designing a good GUI toolkit takes a lot of planning, and even bad ones have lots of features which need implementing. On the other hand, here's an opinion I don't let out very often: I think hardware text modes were obsolete by 1990.
I should probably try to come up with a tutorial on the simplest possible text rendering to graphical framebuffers if there isn't one already.
AndrewAPrice wrote:
The fact that a TUI uses the graphics device's text-mode is an implementation detail.
My thoughts exactly!
AndrewAPrice wrote:
Likewise with graphical CLIs (terminal emulators, Mathematica, etc.) that are command-line but are implemented with a video mode.
Not my thought in the slightest!
All that matters to me is the way you use it. If you type commands, it's a CLI. If you point or navigate to active areas, it's a GUI. I've used one program which is a true hybrid between these two definitions: the Acme text editor from Plan 9. It's powerful.
AndrewAPrice wrote:
until I get the basics of my microkernel down with regards to messaging and drivers, I'm keeping with a CLI because it's easy to debug.
That is true, especially if you have a CLI on a serial port for several reasons.