Un-cplusplus-ification of the window system

In an attempt to make software plain C only, and considering that the window system is very complex to handle, this issue consist in converting the classes in plain C and simplify the window system.

There could be massive modification. There are many ideas related to this issue

  • Using a window stack and draw all window each time, to remove the need to clear the screen, backup windows content, etc.
  • Simplify the use of menu, load from arrays, make them bound to windows immediately.
  • Remove the need to sprintf before copying into windows string of information
  • Use text stream windows to create generic data window instead of the string dat method
  • Standardize the positionning of instructions to prevent the need to constantly move the window position.
  • Maybe integrate the maze drawing as a window to remove the need to backup the screen every time. Still, maze should be the only exception.

UPDATE - DESIGN NOTE - Data Dialogs: This is becomming a very complex puzzle. First genericity has been increased by using a buffer of text in a window to hold the information. This way, you just display a buffer of text and you are done. Unfortunately, even data window sometimes get their information updated ( for example, seeing item stats when shopping). So there must be a way to update that information. And that could mean requirering the information.

Now I could use specific methods like DatProc methods, but that would require a method for each window which could be annoying to implement even with the improvements from using a standard text buffer. Else, I could use a template with an array of variables created from a query. The process is indeed very complex, but possible. I am just not sure of the speed necessary to requirery, and rebuild the data stream.

There is also some issues where certain windows were used to display images. In that case, a buffer of characters will not be necessary to allocate. Considering it does not occur often, I could ignore the wasted space.

DESIGN NOTE - Generic Dialogs: Since we are going to manage a stack of windows or dialogs, it is important to have a form of genericity to be able to handle, data windows, menu windows, questions, distributors, etc. This is the second level of genericity, but unfortunately, I will have to use different procedures to handle each type of dialog, since they are not all the same thing.

So here, I would need to have some sort of inheritance of a base type that I could stack. It's hard not to use object orient programming because of the variable amount of dialogs that will be open with their variable data content.

The problem is that the data requirement is not the same for everybody. So I could design a data structure with all possible fields and only use those I need. Else I need a union of each dialog type that will contains not only data, but pointers toward functions that will print the data, read the keyboard, update the information, etc. In the end, I would get 1-3 proc per dialog type.

UPDATE - NEW APPROACH: I just have the idea that I could use Entity-Component-System philosophy in the design. A similar design could be to have a huge structure will all possible required field, and each dialog will use them differently. The maximum number of dialog could also be a fixed array of 16-32 dialogs as I don't think more dialogs open at the same time will be necessary. The only thing dynamically allocated will be variable length like text buffer, number of elements, etc. There could also be a structure for elements of all types of dialog.

Then there will be a drawing system that will draw in order each window. There will be a system to requery the data if necessary. There is also an input system that will read the input of the last window. Possibly I won't need to do some type check. If the left right button are not used, then it will modify values it has no impact on the dialog, so I don't need an exception case for each type of dialog or data which simplifies greatly the code.

Finally, using ECS programming will improve my experience which such system. I could really separate the large structure in separate components and allocate each component dynamically. A null pointer would indicate that the component does not exists. But I think it will be just to heavy to handle for some gain in memory that is not that much necessary.

New Follow up ideas: IN fact, windows and dialog could use a fixed amount of ram as characters, the maximum that can possibly be used by a window. Then according to the window size, only use a portion of it. The other objective of the characte rbuffer is to allow extrating information from the database and having a place to store it as raw character, instead of dynamically allocating strings received from the database. i wan to reduce dynamic allocation to a minimum and only at startup.

That implies that I will need methods in the printf style format, that will take a query from the SQL database and print it according to a format passed in parameter. That should make it very easy to populate menu and list. Anything printed outside the window buffer of characters is simply discarded.

Related to issue #17

Move most of the ideas in this issue into the Glymmer side project.

Edited by Eric Pietrocupo