Text is working!! We have text in containers now! It wraps the text properly and avoids messing up words when breaking up lines, when it's possible to print at least one whole word in the available space.
o>>===============================(pq)==============================<<o v v H +...............................+ 87777777777777777777777777777778 H H . . 7 7 H H . Crazy? I was crazy once. They . 7 Whoever is in charge, can 7 H H . locked me in a room. A rubber . 7 the container to my left 7 H . room. A rubber room with . 7 *please* be moved somewhere 7 O . rats. A rubber room with . 7 else 7 O O . RUBBER RATS. Rubber rats?! I . 7 7 O . hate rubber rats!! They make . 7 7 H . me CRAZY. CRAZY...? I was . 7 7 H H . crazy once!... . 7 7 H H . . 7 7 H H +...............................+ 87777777777777777777777777777778 H ^ ^ o>>===============================(pq)==============================<<o
It took me longer than it should have, because I kinda tried to start by the hardest part at first. I mentioned in an ealier update that I wanted text to also react to the limits of sibling containers floating over it; the text inside a big container would wrap around the limits of any floating sibling containers overlapping with it, allowing for some interesting designs. I had ideas on how to implement that and was excited to try them, so I spent two, three or so days trying that before I even had any text printing at all. None of my ideas were working, so I ended up deciding to get the basic text printing at once.
Getting it to work was easier than I thought it would be. I remember trying to program text printing with proper line breaking like this long ago in another project, and doing it very stupidly. Pretty sure I looped over each character in the string, separating it into words by finding empty characters, and printing the words one at once after checking if they fit in the line.
I did something infinitely better this time, don't know if it's the best approach, but anyways: I just take the full string we want to print, and get a slice from it, this slice's size being the length of the available space we have to print (in this case, the width of a container). If either the last character in that slice or the character that comes right after it in the full string are an empty space, that means the slice ends between two words and we can safely break the line there. Else, if neither of those two characters are an empty space, that means the slice ends in the middle of a word; in that case we just move back until we find an empty space, which would be the beginning of the word, and break the line there instead. If we can't find a space anywhere, that means the space is too small to even print a full word; at that point we just accept splitting the word and break the line wherever is needed.
Basic simple thing, but it's always satisfying to come up with a better method of doing something than the one you once used.
As I said in the previous update, I was using two almost identical functions for separated things; one for rendering the containers to the terminal, one for rendering them into a file. Well, that is fixed now. I have one single function that does all the rendering, both to a terminal and to files. Yay. Now, finally, to the text... I would say it won't be too hard but I don't want to jinx it. Hopefully I'll get it at least partially working soon.
I haven't even started to implement the text yet. Rather, I spent a few days working on a small feature to make sharing progress easier. Since the whole project is about text based UI, I give preference to sharing it in the form of text rather than using screenshots. But, I was having trouble copying the output of the program from the terminal. I would always inevitably select and copy not only the columns I wanted from the rows I wanted, but the whole rows, including the empty spaces to the sides, and I had to remove all of them, line by line, on a text editor. I'm sure there was a practical easier way to deal with that, but I solved the problem by making a system to render the containers into a buffer and write said buffer to a file, kind of a text screenshot, so now it'll be extremely easy to share the program's rendered pages. I don't have interesting screenshots to show though. Visually, nothing has changed, I just have a better way to share whatever I make in the future.
I had to make the system for creating the buffer and writing to it, which was pretty fun, annoying at times, but very satisfying in the end. But it brought a few problems; I basically have two very similar functions, wich the same logic for drawing containers, only one draws a container to a TermCL window, and the other to a buffer and then to a file. And I realized that having to sync them whenever I updated one of them would probably be a pain. They are actually kinda big and clumsy already too, and I'll have to implement texxt soon... maybe I'll take some time before starting to work on the text to make them more modular. Split them into smaller procedures that draw a part of a container each, ones that can output both to TermCL's window and to whatever buffer I want them to. That would be handy.
I also forgot to share a possible name for the markup language: PTML, for Pure Text (or Terminal?) Markup Language. Not creative, but I'm using it for now in the project's folders.
Well, I think that's all for now. Next update will prbably be text printing in containers, or improvements to code (most likely). See you!
(sorry if the text sounds weird or has mistakes. I didn't sleep yesterday or today)
So I have a basic container system working. A container is just a rectangle that can contain other containers (child containers) inside it. Dynamic resizing seems to be working well, we have content margins and content spacing, and two layout modes for child containers.
Child containers can define how they'll be laid out in their parent. They can choose between `flow` mode, or floating mode: in the first, they are arranged side by side, vertically or horizontally according to the parent's layout direction; in the second, the child defines its position and size as fractions of the parent's area, so they can float anywhere they want. A floating container can be, for example, positioned at 0.25 of its parent's area and define its size as 0.5 of the parent's. That gives you a container that is always a quarter of its parent's size, and always positioned at the center of it.
AND we also have motifs working!! Motif is the collection of text patterns used for drawing a container on screen. For now, a container can have:
with these, you can easily give containers pretty edges! Here's an example:
o>>==========(pq)==========<<o v v H H H H H H O O O O H H H H H H ^ ^ o>>==========(pq)==========<<o
By the way, in the HTML file for this page, in order to show this example I had to replace all the '<' characters with <. That's another part of the reason for making all this, instead of simply using HTML.
For another example, I have a container with content margin & content spacing set to 2; inside it there are two child containers in flow layout mode, organized side by side, and a container in floating mode, with relative position and size set to 0.25 and 0.5, respectively:
o>>========(pq)=======<<o v v H +........+ 877777778 H H . . 7 7 H H . XxxxxxxxxxX 7 H . x . 7 x 7 O . x . 7 x 7 O O . x . 7 x 7 O . x . 7 x 7 H . XxxxxxxxxxX 7 H H . . 7 7 H H +........+ 877777778 H ^ ^ o>>========(pq)=======<<o
I thought the content margin of 2 wasn't working for a second, but I remembered those 2 spaces include the parent container's very edges. A parent container with content margin set to 0 will have its children's edges drawn right over its own edges, so it's natural that a content margin of 2 leaves only one empty space between parent and children's limits.
Only thing I think I should fix about the container right now is their transparency. I could probably do it in a smarter way, but the first thing that comes to mind is overhauling the way I'm drawing them.
When I'm finished fixing those things, I guess the next feature to implement is text in containers. First, basic text that respects a container's limits and correctly wraps lines. Then, I should find a way to enable text to wrap around the limits not only of its parent container, but also of overlapping floating sibling containers, which would open way for much cooler page designs; though I don't have a good idea of how to do that yet. We'll see later.
The markup laguage itself will probably be worked on only after the system for drawing the pages is working. But if I have any ideas worth mentioning, I will.
Well, I think that's all I have to say for now. Until the next update then.