Now I know you may want to continue writing an OS from scratch...
...
I have to say the truth now; yes, I do!
Nah, no, would be cool, but there are
only so many hours a day. Yet I want to have a version of the GUI which can be
used from a bootloader. So for the time being I try to keep everything a bit
simpler than necessary. All the things you can see for now could equally be
displayed from a bootloader by simply using the BIOSs setpixel function (which
is hell inefficient) or by writing straight into the video buffer (assuming
you know the geometry (CRTC registers)).
But there will be a point from where on it won't make any sense doing so any
longer, computational wise. One can build much more sophisticated GUIs using
different rendering methods like scissoring and/or rendering into back- or
index buffers etc. It's possible, of course, but doing so in software over a
slow bus will degrade performance quite a lot. The turn-over-point is
essentially where you want to start doing GUIs utilizing composite effects. If
you go back in time a little then you will see that composite GUIs require
hardware acceleration since otherwise it becomes a dead slow "experience".
Upon reaching said turn-over-point, I will freeze the GUI and put it into an
archive for the time being. This version then will be the most independent one
and should serve me when tinkering around with some embedded devices I follow
some interest in. A similar version will be build for non-embedded devices
serving as a simple GUI for any program who has a needed for it. And then
there will be a version relying on much more advanced systems used for
sophisticated programs and, well, video games.
... But, may I suggest Freetype 2 (
http://www.freetype.org/freetype2/index.html)? It supports TTF and OTF fonts, is open source, can be used in most anything, in theory ported to most anything, and most importantly for you it should provide low-level access so you could do your own rendering, (I think?) do extra processing on the paths, or whatever. However, it would save you approximately a billion hours doing the actual font format and glyph-handling side of things.
Yeah, there is sort of a hell in there in rendering TTFs with all their quirks
like hinting and such. Freetype 2 was gone through it, twice! xD Well, I don't
want to write another true TTF render. This would take way too much time as
you said. If anyone would require me to have TTFs in my GUI, I would use
Freetype 2 immediately. No problem. However, I have a natural interest on the
subject. Font rendering is sort of a stepchild in rendering and is most often
excluded in any book on rendering just for the simplest case, i.e. bitmapped
fonts. And since I want to gain some more proficiency on the subject, I will
do some experiments on my own. That's it.
What data structure are you using for efficiently storing and editing the text in your text boxes? I simply allocated two equally sized buffers (one containing all the characters before the caret, and one containing all the characters after the caret) that behave like stacks. Worked pretty well for my purposes.
Sounds good. I have a sort of a computational version. I don't use any data
structures with the exception of a char array for holding the whole string, of
course. The cursor is maintained independently of the text. Editing is done
while computing the cursor's position within the string. The rest is simply
string concatenation.
