Introduction

In this article, we'll continue our exploration into the pygamelib's layout system, building on the progress we made in the last installment.

Additionally, I'll introduce the library's first practical widget: the LineInput widget.

And finally, this is it - the ultimate "catch-up" post! In the next article, we're diving headfirst into the most recent and thrilling (well sorta...) developments! 🎉

The GridLayout

Building upon the base layout class defined in the last entry of this series, it is now time to tackle the GridLayout. If the the BoxLayout was a nice "entrée en matière", the GridLayout is a different beast altogether. It is a much more complex layout.

So, what are the differences? Well, first and foremost, we now have widgets with potentially varying dimensions in distinct locations, and this needs to be taken into account.

For example, the layout must identify the largest widget in each row and column that limits the width or height of the entire row or column. Naturally, we'll need to compute or track the overall geometry of the widgets managed by the layout. This also hints at a considerable potential for a performance hit.

Why do I say that? Well, if you start considering the usage of such a layout, you can easily make assumptions about the potential performance impact. Let's think about the actual usage of the grid layout, which a programmer would often need:

• to know the number of rows and columns in the layout,

• like all other layouts, to know the list of widgets in the layout,

• obviously, add and remove widgets,

• manage the geometry of the layout (rows and columns size, spacing between widgets, etc.)

• and finally, render the layout and its widgets on the screen.

Unfortunately, there are multiple questionable ways of implementing these features.

If you remember from last week, one of the requirements for all of the layouts is to have a Layout.add_widget(w: Widget) method, that adds a widget to the layout without any other information. This means in this case, that GridLayout will need to be able to find an empty space or to create more space in the grid if needed. More on that later.

You can appreciate that all of these operations require logic. And logic means calculations. Calculations mean impacts on performances.

So, what architecture did I ultimately choose? Well, as usual, I aim to write the least amount of code while considering the big O complexity of my code. I prefer not to maintain internal states that ultimately amount to cached values, primarily because it places a significant maintenance burden on future maintainers. If the code is not properly documented or commented, it becomes increasingly difficult to understand.

That being said, calculating a column width involves iterating through all the rows, checking if a widget is present in the cell, determining the widget's dimensions, and storing the largest width. Performing these steps every time the layout needs to return a column width, 60 times per second, could be too taxing on performance. This is especially true when considering that multiple values need to be calculated in this manner.

Ultimately, I decided to implement a balanced approach that would optimize performance without compromising functionality: by caching the values and employing the observer system to dynamically update these cached values as needed. This method allows for efficient storage and retrieval of the largest widget widths, while also ensuring that the most up-to-date dimensions are used for calculations. By caching the values, the system avoids the need to repeatedly perform the time-consuming process of iterating through all the rows (for example), checking for the presence of a widget in each cell, determining its dimensions, and storing the largest width. The observer system, on the other hand, helps keep track of any changes in the widget dimensions and allows for the dynamic update of the cached values. This combination of techniques effectively addresses the performance concerns associated with calculating multiple values in this manner, while still maintaining the accuracy and responsiveness required for a smooth user experience.

Using the observer mechanic like that is not unlike Qt's signal/slot system (which I love a lot).

Another specificity of that layout is that it requires a row and column to add a widget. Except that, I set a rule that all layouts should have an add_widget(w: Widget) method. This means that the add_widget method of GridLayout should be able to perform correctly without coordinates. I did that by adding a quick test on the coordinates and if even one is None, I do a quick search to look for a free cell in the layout. If none is found, I just add a row to the layout. This means that:

1. The layout expands exclusively vertically for now,

2. I need to add an expansion policy for that layout.

As I previously mentioned, one of the challenges for these layouts is to constrain the rendering surface for the contained widgets. The approach that I choose is to limit the buffer that is given to the widget to render into. This way, even if the widget wants to render in a bigger space, it cannot.

In practice, it means that in the rendering loop, when it's time to defer rendering to widgets, I just give them their reserved space in the buffer and a 0,0 coordinate:

w.render_to_buffer(
    buffer[
        row + r_offset : row + r_offset + self.__rows_geometry[r],
        column
        + c_offset : column
        + c_offset
        + self.__columns_geometry[c],
    ],
    0,
    0,
    self.__rows_geometry[r],
    self.__columns_geometry[c],
)

The result is quite functional:

Here, we can see the cyan widget being resized, and the rest of the layout adapting accordingly while respecting the widgets' size constraints. For example, the white widgets have a smaller maximum width than the cyan widget. It works great.

The aspect that still needs improvement is the fact that widgets not entirely outside the layout are still rendered in their entirety.

The issue is quite evident in the previous code snippet: I allow the widget to render on the full width of the column (or height of the row). The fix is simple; it just needs to take into consideration the maximum layout's buffer size.

Another #TODO I guess 😉

LineInput: An Actually Useful Widget

The last big addition to the UI toolkit that I added through that PR was the LineInput widget. Because colored squares and rectangles are nice placeholders but at some point, I need to put some real widgets in these layouts (to avoid discovering all the problems at the same time).

If you are wondering, a LineInput widget is a user interface element that allows users to enter and edit a single line of text. It typically includes a text box where the user can type, and may also provide additional features such as a cursor for easy navigation, text selection, and built-in validation. LineInput widgets are commonly used in forms, search bars, and other situations where the user needs to input a small amount of text quickly and efficiently (like a username for example).

So I thought that an input widget would actually tick a lot of boxes in terms of pains in the a*s. Indeed it needs a couple of things that are not needed by colored squares:

• It needs to display interactive content,

• It needs to have a focus management system,

• It needs a visual cue for the user to know where he is typing stuff (like a cursor),

• It is preferable to have a history system somewhere...

That's great because, so far, the UI module lacks a focus management system, completely ignores even the concept of a cursor, and most definitely doesn't have a history management system! We're off to an excellent start!

History

So I got to work, the first thing was the history system. It needed to be generic, i.e.: can manage all sorts of objects, not exclusively strings for example.

The second design decision was to make the History class a singleton. I know that a lot of people dislike the singleton design pattern but with very little argument aside from hopping on the hype train. The only really valid cons that I agree with are the tight coupling and the lack of transparency of the pattern. However, the solutions for these are very often dependency injections. So... Tight coupling anyway, no?

I use many singletons in the pygamelib, mostly for resources that must or can (mostly depending on the user's choice) be shared between many objects and for integrity and performance reasons you will want to manage as a single instance anyway.

In most (if not all) cases, it is up to the user (as in the programmer using the library) to decide if he wants to use a global instance or a specific instance.

Let me skip ahead and give you an example, in my implementation of the LineInput widget, the constructor accepts a history parameter that must hold a History object. If it is not provided, the constructor will try to acquire a global reference to the history object. It is up to the developer to choose to use the global instance, a specific instance or none at all. Another example of a singleton is the Terminal object, this is a common resource managed by a single instance because I want to make sure that nothing else is going to change the state of my terminal while I'm using it (the pygamelib restores the terminal to its previous state when it exits).

Back to the topic, it was my first time implementing a history system \o/

I implemented it by considering an action as a point in time. And I'm moving that action (or object) along the timeline. In practice, I have 2 lists for past and future actions and a scalar for the current action. Then it's just a matter of wrapping the movement along that timeline in actions. From a developer's point of view, using it looks like this:

global_history = History.instance()
global_history.add('Hel')
global_history.add('Hello')
global_history.add('Hello Wo')
global_history.add('Hello World')
print(global_history.current)  # print "Hello World"
global_history.undo()
print(global_history.current)  # print "Hello Wo"
global_history.undo()
print(global_history.current)  # print "Hello"
global_history.redo()
global_history.redo()
global_history.redo() # This one does nothing as we called undo only twice.
print(global_history.current)  # print "Hello World"
# Now an example of reset through add()
global_history.undo()
global_history.undo()
print(global_history.current)  # print "Hello"
global_history.add("Hello there!")
print(global_history.current)  # print "Hello there!"
global_history.redo() # does nothing as the future was reset by add()

This example comes straight from the documentation.

The obvious downside of that approach is that each "action" represents a full state of the object that is tracked through the history. It is not very memory efficient...

However, this will suffice for now, as I plan to optimize it later. At least we now have a highly adaptable, generic history support in place.

Alright, one down, two to go!

Cursor (not curse, that is the question)

If we are going to have input widgets, we'll inevitably need one or more cursors as indicators for the user.

The Cursor object is not very complex, but some little traps need to be avoided.

The first one is that we need a cursor that adapts to the user's needs. This means that we need to be able to at least customize the appearance, starting position, and blinking behavior. So that's what I coded!

To get a plain, non blinking cursor you just use:

cursor = Cursor(blink_time=0)

Simple and efficient. Now, to customize the look of the cursor we just accept a Sprixel in the constructor. Easy. And a blinking delay as well:

cursor = Cursor(
    blink_time=0.4,
    sprixel=Sprixel(
        "|", 
        bg_color=config.input_bg_color,
        fg_color=Color(255, 255, 255),
    ),
)

Aside from that, we need to be able to lock the cursor's position when widgets are updating their content but want the cursor to remain in the same position. Not a problem Cursor.lock_position() and Cursor.unlock_position() are here for that. It allows for a dirty optimization: the widgets can have properties/functions that update the cursor no matter what other functions may want. A good example of that is in the LineInput widget (a bit ahead of time): the LineInput.text property, sets the cursor's position to the end of the text. It is unconditional because it cannot know when to move or not the cursor. It falls down to the user of that property to know when and where to move the cursor. Therefore, when Cursor.insert_characters() uses the text property to set the text, it first locks the cursor's position, sets the text, and finally unlocks the cursor's position to calculate the new position. This way, the text is correctly inserted and the cursor is moved to the right position.

That's 2 down!

Focus Management

The last piece of this triumvirate is the focus management system. Such a system is needed to ventilate the different user-generated events to the correct receiver.

And this is where I kind of stopped. I did not stop because I was lazy but because I had no clear idea of what to do. I started by thinking like a C++ programmer: let's create a Focusable interface that would define everything needed and then write an actual manager to handle these. Oh, and let's create an event manager/dispatcher to accurately dispatch keystrokes and other events.

But wait, I have a lot of these. There are already a lot of systems available in the pygamelib for these tasks. So, after a bit of thinking, I added a focus property to Widget and decided to leave it at that. I'm not entirely sure how I will implement a more bundled/streamlined version of a focus management system so for now I decided to experiment. And to experiment, I need to leave room for errors.

This is extremely important to me in any creative process to leave room for experimentation and error. And, unfortunately, any system that I could come up with, however light, would still start to shape my thought process. Therefore, I just implemented the one thing that I'm certain that I'll need: the focus property.

It allows for basic management through a list and an index! Have a look at that example:

# Have some global variables
focus_stack = []
focus_stack_index = 0

# Now in the update function of my program (called every frame)
def user_update(g: Game, k: blessed.Keystroke dt: float):
    global focus_stack_index
    # If the Tab key is hit, we change who's focus property is True
    if k.name == "KEY_TAB":
        if not focus_stack[focus_stack_index].focus:
            focus_stack[focus_stack_index].focus = True
        else:
            focus_stack[focus_stack_index].focus = False
            focus_stack_index += 1
            focus_stack_index = focus_stack_index % len(focus_stack)
            focus_stack[focus_stack_index].focus = True
    # And if Tab was not hit, the currently focused widget receives
    # the keyboard input
    elif focus_stack[focus_stack_index].focus:
        g.screen.place(str(k), 23, 0)
        if k.name == "KEY_BACKSPACE":
            focus_stack[focus_stack_index].backspace()
        elif k.name == "KEY_DELETE":
            focus_stack[focus_stack_index].delete()
        elif k.name == "KEY_HOME":
            focus_stack[focus_stack_index].home()
        elif k.name == "KEY_END":
            focus_stack[focus_stack_index].end()
        elif k.name == "KEY_ESCAPE":
            focus_stack[focus_stack_index].focus = False

Now that I look back at it, I actually think that this is pretty much what I would expect from a focus manager. I little more packaged so I can call a method like focus_next() for example. We'll see.

What About LineInput?

Well, now that all of this is done, LineInput is more or less just a matter of organizing all of these features. So there's nothing really amazing in that class. But it does work, and here it is in action:

Conclusion

It's very interesting to do things, just for the sake of it. Just to learn something interesting.

I'm often reminded of that while coding this module. I find this exercise intellectually refreshing. Being able to really think of solutions while not being constrained by notions like ROI, speed of implementation, etc.

As usual, I hope that you found this article somewhat interesting. Do not hesitate to give me feedback!

Have fun and keep coding!

Arnaud.

In the previous episode, we concluded with the implementation of the Widget class and numerous unanswered questions. Many of these questions revolve around the automatic management of multiple widgets.

In this installment, I will discuss the development of the Layout system.

Initially, I intended for this entry to be the final one, summarizing previous developments. However, due to falling quite ill this week, I was unable to edit the vast amount of material I have on the topic. As a result, I plan to publish one more entry before catching up to real-time. Sorry about that.

The state of things

At this point, we have a functional foundation for a widget with an effective size management system.

Here's a small program I used to test it:

from pygamelib.engine import Game
from pygamelib.gfx.ui import (
    Widget,
    UiConfig,
)
from pygamelib.constants import (
    EngineConstant,
    EngineMode,
)


def uu(g: Game, k, dt: float):
    # Get the widget (because we know where it is, obviously...)
    w: Widget = g.screen.get(1, 1)

    # Delete potential labels
    g.screen.delete(0, 1 + round(w.width / 2))
    g.screen.delete(1 + round(w.height / 2), 2 + w.width)

    # Handle key stroke to change the widget size
    if k == "Q" or k.name == "KEY_ESCAPE":
        g.stop()
    elif k == "H":
        w.height += 1
    elif k == "h":
        w.height -= 1
    elif k == "W":
        w.width += 1
    elif k == "w":
        w.width -= 1
    elif k == "d":
        w.width -= 1
        w.height -= 1
    elif k == "D":
        w.width += 1
        w.height += 1

    # Add the current widget's dimensions to the screen
    g.screen.place(f"{w.width}", 0, 1 + round(w.width / 2))
    g.screen.place(f"{w.height}", 1 + round(w.height / 2), 2 + w.width)

    # Update the screen
    g.screen.update()


if __name__ == "__main__":
    # Create the instances of the Game and the unified UiConfig
    g = Game(
        mode=EngineMode.MODE_REAL_TIME,
        player=EngineConstant.NO_PLAYER,
        user_update=uu,
    )
    config = UiConfig.instance(game=g)

    # Create a widget with
    w = Widget(30, 15, 10, 4, 60, 40, config=config)

    # Place the widget on screen
    g.screen.place(w, 1, 1)

    # Run the event loop
    g.run()

The results are mindblowing: it's a square...

But, as you can test yourself, a square with functional size management.

As observed last week, we soon began asking questions about positioning, automatic size management, and so on. Having experience with various UI frameworks (such as Qt, GTK, and ImGui), I understand that if we have a widget system, we also need a layout system. So, let's tackle that beast!

Layouts: where problems begin!

The problem

In any decent UI framework, you will find a concept of layout. These layouts are incredibly practical, as they enable much faster development of UI projects by handling many of the geometry calculations needed in various situations.

If you recall last week's installment, my goal is to solve the problem independently. I'm not interested in examining existing code, as the challenge itself is my objective. However, I also mentioned that I would loosely base my UI toolkit on Qt.

There are two reasons for this. First, I have extensive experience coding with Qt. As a result, whether I like it or not, its design philosophy will influence me. Second, I believe that Qt's architecture is the most sensible among UI toolkits. However, that is the extent of the inspiration. Drawing inspiration from the implementation itself wouldn't make much sense, as Qt is a much larger and more sophisticated framework.

That being said, the layout system must be capable of managing the standard operations of a typical layout system. That means:

• Managing sub-widgets (adding/removing widgets to and from the layout)

• Keeping count of widgets in the layout.

• Managing geometry

• Enforcing size constraints

• Guaranteeing the access to the list of managed widgets.

That is the base set of core features that all layouts will share.

Identifying the key components

For the initial implementation of the pygamelib's UI framework, I am focusing on a select few practical layouts. I prefer having a concise list of functional and useful layouts rather than an extensive list of partially implemented ones.

So, we will have:

• Layout: The foundational (mostly virtual) class that establishes the basic API.

• BoxLayout: A layout that presents all widgets in a list, either horizontally or vertically.

• GridLayout: A layout designed to arrange all widgets in a grid format (quite unexpected, isn't it?)

• FormLayout: a layout to quickly create a form-type complex widget. It will organize the widgets one by line and each line has a label (a line/row is composed of a label and a widget).

Let's get coding!

Creating a basic Layout class

For the Layout class, I went with something very simple. It is an instantiable object (as Python does not really support pure virtual classes), but only a handful of properties are implemented (as it should be the same requirements for all the layouts). We have:

• parent [property]: store and return the parent widget.

• spacing [property]: store and return the spacing between widgets. Note that some layouts may need more detailed spacing information (like vertical or horizontal) but again: this is the bare minimum.

• and, obviously, a basic constructor.

For the virtual methods, we need to think a little about what is common to all the layouts. Quite simply, all layouts will need the ability to:

• Add widgets.

• Remove widgets.

• Count how many widgets they are managing.

• Return a list of widgets that they are managing.

• Return their total height (including spacing and potential padding).

• Return their total width (also including spacing and potential padding).

• Render to the frame buffer.

Padding is not supported or even on the roadmap for the first version. But it'll come!

Now as I write that and look at the code, I realize that there is no Layout.remove_widget(w: Widget) method in Layout... That is a problem. But I know why it's like that: it's because it feels useless!

Let me elaborate. In most UI frameworks, there is usually some sort of remove function that allows you to remove a widget based on its pointer or reference. Interestingly, I have never actually used it!

In a box or form layout, I use the widget's index. In a grid layout, I use the row and column coordinates. I understand that I shouldn't impose my own practices on other programmers, but it seems even more pointless than this entire project! Why? Because, obtaining a widget's reference when a user clicks on it is simple, yet maintaining the focus stack in a keyboard-based terminal interface will inevitably lead to using indexes or coordinates.

Nonetheless, I will add a TODO note to implement a virtual method in Layout.

The documentation is already available on Readthedocs: pygamelib.gfx.ui.Layout.

The BoxLayout class

Same as Layout, the documentation is already available: pygamelib.gfx.ui.BoxLayout.

I'm sure that I don't need to be explicit about that but, I also mean that the code is on GitHub.

The BoxLayout is quite simple to conceptualize: it essentially consists of a list of widgets. These widgets are rendered either horizontally or vertically. Unsurprisingly, I initially believed that implementing it would be a walk in the park...

To be fair, the first iteration was easy: add widgets, render them vertically. Easy, peasy. Then, take into consideration the spacing. Not very difficult.

Then things started to go south... Adding orientation management is not that hard, but it is taxing to check on the orientation every frame. I came up with a solution that, for the moment, feels like the least of many evils.

I maintain 2 offset variables during the rendering loop: one for the row and one for the column (the terminal coordinate system), and I increase only the correct one depending on the orientation property. It limits the tests to just one if. I then simply render the widget at the coordinate plus the offset. It is basic geometry but it works fine.

Adding size constraints becomes more interesting. At first, and it is the current implementation, I just deferred all of the work to Widget! Remember, Widget does that very well already.

So I decided that the solution was easy: when the user changes the size constraints of the layout, pass them down to all the widgets. Easy!

The code look like that:

 @size_constraint.setter
 def size_constraint(self, data: constants.SizeConstraint) -> None:
     if isinstance(data, constants.SizeConstraint):
         self.__size_constraint = data
         for w in self.__widgets:
             w.size_constraint = data

And it does the job perfectly. Not only that, but it is also efficient as we update the constraints only when necessary. Job done, thank you very much, and push to production!

But wait... There's just one small problem: what about widgets that are added after a change? Well... Then it just doesn't work. And that is another TODO note that I need to add to the code following this article... In that case, you would have widgets with different size constraints that lives in the same layout. It's not hard to fix, it does not even need a comparison or anything: when a widget is added, we need to overwrite its size constraint with the layout's one.

Aside from that minor inconvenience, I'm quite pleased with the progress of this layout system. Thus far, it appears to be versatile enough. The API is also fairly straightforward, as I extensively utilize Python's properties for setter and getter methods. This makes assigning a layout to a widget as simple as:

# The number in Widget's constructor are: width, height, minimum_width,
# minimum_height,maximum_width, maximum_height.
my_widget = Widget(30, 15, 10, 4, 40, 20, config=config)
my_widget.layout = BoxLayout()

# And then simply add widgets to the layout using add_widget()
my_widget.layout.add_widget(
    Widget(6, 3, 3, 1, 8, 4, bg_color=Color.random(), config=config)
)

# Orientation and size constraint can be set with simple properties
my_widget.layout.orientation = constants.Orientation.VERTICAL
my_widget.layout.size_constraint = constants.SizeConstraint.DEFAULT_SIZE

And despite its simplicity, it works pretty well! I'm sure that you're dying for more screenshots of colored rectangles so here it is!

The current BoxLayout handle orientation changes with and without spacing between widgets:

Without spacing

And with spacing

It also gracefully handles adding non-trivial widgets, i.e: widgets that are already a composition of multiple widgets held into another layout (layout-ception!):

Finally, I have also incorporated culling into the render loop to prevent rendering sub-elements that are no longer within the frame. This completely skips the rendering of elements that are entirely outside the rendering surface.

Oh, and I realized that there was no way to remove any widgets (even using their IDs) in the BoxLayout class... So I guess that's one more TODO...

Closing word

This entry is already quite long, so we'll wrap things up for today. As I mentioned in the introduction, the next entry will be the last about the past before we switch to the PR, I'm working on right now.

Next time we will talk about the GridLayout and an actually useful implementation of a Widget: the LineInput widget.

I hope you find this somewhat interesting. Do not hesitate to give me feedback!

Have fun and keep coding!

Arnaud.

A bit of context: I've been working for some years now on a Python library called the pygamelib. A not-so-small library to write games and applications in the terminal in Python. If you are wondering, it has nothing to do with Pygame and I realized way too late that people would mistake the 2... Sorry, I guess?

This library was originally developed for the kids in the coding classes that I'm giving for fun to young kids from 6 to 15 years old. It started as a rough bundle of classes to make simple games in the terminal (to keep the kids interested).

But it got out of hand... Seriously out of hands.

First, I started to be interested in the algorithmic problems and many optimization issues raised by the needs of such a framework.

Then I got interested in game engine theory (read Game Engine Architecture if you're interested in that) and soooo many more things...

Many years later, here I am, starting a brand new module in the library: the pygamelib.gfx.ui module.

This series is about the challenges and my approach to developing that UI module.

I'll start with my philosophy about this whole endeavor and I'll try to have regular entries about my progress and frustrations.

Philosophy: Embracing the Futility

Let’s start with a harsh truth: what I'm building is utterly unnecessary. Established Python libraries like curses, urwid, picotui, and my personal favorite, Textual, have already mastered TUI (Terminal User Interface) frameworks.

So a new one is not only not needed, but more importantly a dilution of the development effort toward a solid TUI (Terminal User Interface) framework.

So of course I embarked on this exercise in futility! Because: why not?

Before I began, I set some ground rules:

1. I want to solve the problems myself. I'm doing that for fun and to learn, so there's no point in looking for answers.

2. Errors are ok. I will mark that module as alpha code for a loooong time. So let's fail!

3. Obviously, contributions and feedback are accepted and even encouraged. However, there are probably very few people who have the same weird drive to implement stuff just for fun.

4. I like the Qt framework so I am loosely going to get inspiration from it.

PR #221: The Beginning

Well... Not really.

Ok, it's kinda dramatic to call it the beginning because there was already a first draft of a UI toolkit before that PR (Pull Request), and it could already do very nice things:

This is the pygamelib sprite editor (yes: we have a sprite system and even a sprite editor!). Obviously, the library is already capable of having menus with floating displays, dialogs, panels, etc.

The issue is that all of these elements are independent and not really working together. It is functional but not really nice. So let's build something that can help bring all these elements together!

PR #221 is actually that beginning.

The basics

The pygamelib has a fairly simple rendering loop, we have a Screen object on which we can place stuff (game board, UI elements, text, etc.) and Screen.update() take care of triggering the rendering loop (if needed). Each object placed on the screen must either be a printable character, a Sprixel (like a pixel but for the terminal), or implement a render_to_buffer(...) method. All of that is rendered into a frame buffer, and finally, update() just push all of that buffer to the terminal's screen.

Obviously, the UI module needs to integrate into that system and take it into consideration. As a matter of fact, it will be crucial in the future when we talk about geometry... But let's keep that for the next issue.

At first, I was very enthusiastic about the amount of work needed, it did not look like it was going to be horribly difficult. The boldness and pretention of that thought...

For a little context, I started to work on PR#221 on the 19th of November 2022 (well, a bit before that, it was the first commit), the PR was merged on the 11th of October 2023! Admittedly I got distracted along the way but 4025 additions and 54 commits later, I kind of realized that it was not going to be a quick endeavor.

The first thing that I implemented was the Widget class. When rendered on screen it's not much, barely a colored rectangle. But when you look at its logic it's more interesting. So the goal is that the Widget class is going to be the base of almost all elements in the UI module. Therefore it needs to be very generic and keep its logic to the minimum. And that it does, the Widget class does only a limited amount of things:

• it manages its own geometry (max/min height and width, current height and width),

• it manages the size constraint policies (à la Qt),

• it keeps track of its parent,

• it keeps track of its children,

• it possesses attributes to manage some internal states (like the focus),

• finally, it can hold a layout (more on that later).

Navigating through default behaviors set by the user was as smooth as finding a cookie jar in a kid's room. Nothing hard, but I have a newfound respect for all the people who give us such sensible default values in the libraries that we use daily...

Now here I am, ending up proudly with a square on my screen... cool cool...

Not underwhelming but far from exceptional. The code to get there is fairly straightforward:

from pygamelib import engine
from pygamelib.gfx import ui

# Create instances of the game engine and the UI configuration
g = engine.Game.instance()
uic = ui.UiConfig(game=g)

# Place some stuff on the screen
g.screen.place("Here is a widget!", 2, 2)
g.screen.place(ui.Widget(widht=10, height=5), 3, 2)
g.screen.place("Woohooo...", 9, 2)

# Update the screen
g.screen.update()

Now, immediately a certain amount of questions arise:

• What if I want to put multiple widgets on the screen and have them organized (but I don't want to spend my time calculating height, width, and positions for each and every one of them)?

• What if I want to build complex widgets with widgets inside widgets?

• What if I want something else than a bluish square?

All of these are very valid questions, I know: that's the questions I asked myself ;)

We'll talk about that in the next installment!

Conclusion (for now)

This initial installment serves as an introduction, offering context and a glimpse into the inception of my UI module venture. The next article should offer a more technical dive into the details of this development.

Clearly, I'm documenting a year-long development process, so I'll summarize certain aspects and present it more as a report.

In the meantime, I'm noting things in my coding diary for future articles. I hope that this will be an entertaining window into the hobby of a coder for fun and why not: maybe have little interactions with like-minded people along the way!

Have fun and keep coding!

Arnaud.

PS: I used AI to reformulate some parts (sorry but I am not a native English speaker). Tell me if these parts are obvious ;-)

Hello Hashnode, I am a new contributor to the platform. As this is my first article, let's take a moment for a brief introduction.

I'm a not-so-young-anymore developer and entrepreneur. Not so young, but I like my age: I'm 42 years old, which means that I always have the answer 😉.

I like to mention that I began contributing when freshmeat.net was still in its infancy (I recall the early days, even the unreal ones...) about 20+ years ago (I know: 20++). Anyway, let's just say it wasn't yesterday. Over the years, I've contributed to numerous open-source software projects, some big and some small. I've also started and abandoned even more projects!

Today my main project is a Python library called pygamelib. It's a little framework to make 2D games and applications in the terminal. It's fun, mostly useless but fascinating to develop nonetheless.

Why Hashnode?

Well, I sort of rage quit WordPress... There are a few good reasons for that, but mostly it saddens me to see one of the largest open-source successes transform into a greedy company with predatory practices. Don't get me wrong: I'm not an idealist, and I understand that companies need to make money, but hiding meta tag modifications behind a $25/month paywall is a bit excessive. Just a bit...

Hashnode appears to be a more appealing alternative, offering a less cluttered, more efficient, markdown-based platform, along with an enticing free tier that encourages you to support them rather than compelling you to pay for basic features.

The community also appears to be quite interesting.

My Interests

I am a seasoned developer with a strong background in various programming languages, including Python, C++, Perl, and Java. My experience with the Qt framework has allowed me to create robust and efficient applications across multiple platforms.

I dabbled in many things from system/kernel programming to game development, with a detour into microservices and highly redundant databases. A lot of fun!

At the moment, I'm not coding professionally, so I can indulge in what I enjoy doing rather than what I'm obligated to do! As a result, you'll find a plethora of information on the pygamelib, my insatiable passion for algorithms and applied mathematics (including AI), game development, and any other subject that captures my interest at the moment. In short, just an old man rambling 😉.

Oh, and I can be quite opinionated.

Apart from programming, I am an avid Science-Fiction reader, a passionate amateur astronomer, and a technical scuba diver. Who knows, this may influence some of my articles.

What to Expect?

Well, I plan to write several articles per month. I've begun a series documenting my journey in developing a user interface framework for the pygamelib, and I hope it will provide engaging content!

I am considering writing vulgarization articles about some algorithms that I enjoy. Perhaps a bit of AI basics, just to assist those who believe they know everything there is to know about AI in understanding what an activation function is 😈.

I also want to share tutorials and how-tos about topics I enjoy and wish to share with others.

You won't find any "industry analysis" or "case studies" here. This is my personal blog and I want it bullshit free.

Upcoming Content

The upcoming article will be the first installment in my series, "Building the PygameLib UI SDK: A Coding Odyssey." I hope you find it interesting.

Over time, I would be happy to get feedback from the community!

Conclusion

I am deeply grateful for the opportunity to embark on this exciting journey, sharing my knowledge and experiences with the community. I look forward to connecting with like-minded individuals, learning from each other, and growing together as we explore the ever-evolving world of technology.

I invite you to connect with me on Mastodon at @8bitscoding@floss.social, where we can continue our discussions, exchange ideas, and collaborate on projects. Let's build a strong and supportive community together in the realm of open-source technology and beyond.

Until next time. Keep coding, keep having fun!