I’m not sure that is a good use of GSoC time. The idea of GSoC is that you can spend a lot of continuous time focusing on a specific problem. Working on many smaller ports does not need that, it is something that can be done with a few hours here and there.
So, the project would get boring and repetitive, and would not use the opportunity to learn as much.
We don’t plan to use SDL in app_server. We probably need to implement something similar, tying harfbuzz and freetype (and maybe fontconfig) together.
But I think the rendering of text is the easy part in that project. That is just following the examples (in SDL3 or other places) and the documentation of the libraries to use.
What gets more interesting is things like cursor and selection management, handling of partial redrawing, and also good adaptation of the user interface for right-to-left text.
When you have text full of ligatures or combined characters, what happens when you try to select and copy parts of it? When you move the cursor accross? When you backspace a character and retype it? A lot of the text handling in Haiku is built around the assumption that one unicode codepoint = one glyph, which of course isn’t the case at all. For example, our API allows you to do this:
DrawString("this stuf");
DrawString("f is hard");
And you should get the same result as:
DrawString("this stuff is hard");
To achieve this, the BView API keeps a notion of an internal “drawing position” that advances as text is drawn. And it’s also possible for applications to retrieve, save, restore, and move that position.
But what if the “ff” is replaced by a ligature? This cannot happen in the first case, because the two parts are drawn separately. It may seem silly in this simple example, but this could happen, for example, if a view is trying to optimize things and redraw only a small part of the text that was exposed by another window being moved out of the way. So, how is that supposed to work? How do we determine a “safe” part of the string to redraw?