Brian Palmer wrote:
Alex,
You could very easily add this within the current framework. You had said you wanted to remove all the GUI stuff (which I took to mean all the video and graphics capabilities) and make everything call the TUI functions directly. Which I think is a bad idea.
However, if you want to keep the current UI framework, and only delete gui.c and gui.h I am ok with that. They are empty, just like you say. Then you can add this new "console" looking UI as a sibling to the TUI one. After all, that's what the abstraction is for.
It looks like there is some confusion about what we both are talking about. Can you please explain again what you propose to change?
-Brian
Hi,
When I say remove all the "GUI Stuff" I meant the abstraction layer, not the "video and graphics capabilities". One more time, I simply want a box to be drawn by TuiDrawBox, instead of UiDrawBox, which will then read the current graphics mode, and then call TuiDrawBox. It's a useless abstraction at this point.
However, I gave it a bit more thought, and if I replace this by a vtable system much like the Mach functions, then I believe we shoudl both be happy. It would get rid of ui.c, gui.h, ui.h and gui.c, leaving only tui.c. However, the calls themselves won't be TuiDrawBox, but UiDrawBox, where this will be defined to something like GraphicsTable->DrawBox, which will be initialized on startup. That way, the useless source files go away, because it's not necessary to define the Gui functions anymore. The speed impact will go away too, since we don't be checking the graphics mode each time, and if someone wants to implement a 3rd graphic mode (ie: console mode), they won't have to edit 50 UI functions to add another "if/else" case. How does that sound?
Best regards, Alex Ionescu