Suggestion: rectangle_t and rect_t typedefs

Reporter: time-killer-games  |  Status: open  |  Last Modified: August 25, 2020, 05:03:15 pm
Basically, a lot of programs use a string formatted in the form of WidthxHeight+X+Y to represent screen coordinates forming a rectangle. One example of a software that does this, the output of xrandr displays. This may also be used by the engine internally to set the rectangle of kdialog to a custom size & position provided by the developer. There are a lot of other use cases for it.

Basically, idea is to make a special typedef for std::string and call it rectangle_t. This data type can have its values parsed with functions we could provide in enigma_user, something like this: (but those calls to exit(1) and cout/endl can be replaced with a DEBUG_MESSAGE with M_INFO severity). Then, there could be yet another data type we could add that doesn't use strings but rather a typedef of a struct with the name rect_t. This one could be used for more common tasks that don't require the slow string parsing. The members of the rect_t struct would be an unsigned int width/height and a signed int x/y.

I wanted approval of this idea before making a pull request. The pull request will be split into two parts. The first one will add the string parsing logic functions to estring.h along with the string typedef rectangle_t. Then I'll add to that pull request the struct rect_t someonewhere else, probably wherever we put our math related functions in universal system.

The second pr will be slightly unrelated but on a similar topic - I will do some general type fixes to our window related code, the first thing that comes to mind is we are using a signed int for width/height in some places when it should be unsigned. That may or may not be the only thing to do with the latter pr. Anyway, what are your thoughts on this guys?


I've just started upgrading the syntax checker. I upgraded it a few years back to use a proper tokenizer; now I'm updating it to use a proper AST.

This will put us in a position to support complex structure types. Now is indeed the time to start talking about what we would like rect_t, vec2_t, vec3_t, vec4_t, quaternion_t, matrix_t, polygon_t, array_t, etc, to look like, and how they should play with the existing API.

It would not be good to use a string for these types. Serializing numbers to/from string would be very expensive. However, we can discuss serialization logic for printing, IPC, RPC, etc.

@JoshDreamland I could simply add those rectangle string parsing functions without the typedef, does that sound any better?

I was actually going to use this for my video player extension for video_set_rectangle. I've noticed using std::map with integer values will sometimes give some random number as the default value when uninitialized, (instead of zero), outsize of the reasons i listed for adding this already, I was going to use these functions as a workaround to that issue by using a string in the std::map instead. If you don't like that idea I'll see if I can find a better approach.

That would cause the map to grow every time you tried to look up a number in it. I recommend using atol.
@JoshDreamland that's why I have video_delete() so strings that are no longer used can have their entry removed from the map.
Please sign in to post comments, or you can view this issue on GitHub.