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