Proposal: Add point array helper function to make LVGL line widget easier to use with Berry

[markusdd]

This is not a 'bug' but an improvement proposal of the LVGL API in berry for Tasmota based on some Github Discussions and the Discord:

Problem Statement:

Using the line widget is very verbose right now in berry because of the object oriented notation which requires to create an empty point object and then seperately set x and y of the point.
For more complex lines this becomes very clunky very quickly. In C, this is implicitly solved by casting. You can just write down a list of lists with either coordinates or lv.pct() values and the point setting function takes care.
This makes for much more condensed and elegant code.

Hence, I would propose the following helper function:

def list_to_point_arr(point_list)
    # expects a list of lists, where the inner
    # lists have an exact length of two with constant
    # integer values or are of type lv.pct() to describe
    # the points to be drawn
    #
    # returns a list of length 2, with list[0] being the
    # lv.point_arr that was generated and list[1] contains
    # the length of this array
    #
    # typical use case would be:
    # my_line_points = [[10,10], [10,50], [50,50]]
    # point_arr = list_to_points(my_line_points)
    # my_line.set_points(point_arr[0], point_arr[1])
    var i = 0
    var lv_point_list = []
    for p: point_list
        lv_point_list.push(lv.point())
        lv_point_list[i].x = p[0]
        lv_point_list[i].y = p[1]
        i += 1
    end
    return [lv.point_arr(lv_point_list), i]
end

This will allow a complex line widget to be created as follows (example from my app where I stumbled across this issue, this draws a complete map of a basement):

# this will draw the walls of the basement in which we will
# position the light switches, so this is all rendered, no
# picture is being loaded
line_basement = lv.line(ui_Screen1)
top_y = 90
bottom_y = 390
left_x = 80
right_x = 720

line_basement_points = [
    [left_x, top_y],               # top left origin
    [left_x + 450, top_y],         # north wall
    [left_x + 450, 190],           # outer door wall Nordkeller
    [left_x + 450, top_y],         # outer door wall Nordkeller
    [right_x, top_y],              # north wall
    [right_x, 250],                # east wall
    [right_x - 50, 250],           # outer door wall Waschkeller
    [right_x, 250],                # outer door wall Waschkeller
    [right_x, bottom_y],           # east wall
    [right_x - 50, bottom_y],      # south wall
    [right_x - 50, bottom_y - 30], # south door
    [right_x - 80, bottom_y],      # south door
    [left_x + 300, bottom_y],      # south wall
    [left_x + 300, 250],           # wall Hauptkeller
    [left_x + 300, bottom_y],      # wall Hauptkeller
    [left_x, bottom_y],            # south wall
    [left_x, 250],                 # west wall
    [left_x + 20, 250],            # outer door wall Einmachkeller
    [left_x, 250],                 # outer door wall Einmachkeller
    [left_x, top_y],               # west wall
    [left_x + 80, top_y],          # move cursor
    [left_x + 80, 250],            # inner wall Einmachkeller
    [left_x + 50, 250],            # inner door wall Einmachkeller
    [left_x + 200, 250],           # inner wall Heizungskeller
    [left_x + 200, 220],           # door Heizungskeller
    [left_x + 230, 250],           # door Heizungskeller
    [left_x + 450, 250],           # inner main wall
    [left_x + 450, 220],           # inner door wall Nordkeller
    [left_x + 450, 250],           # inner door wall Nordkeller
    [right_x - 80, 250]            # inner door wall Waschkeller
    ]
result = list_to_point_arr(line_basement_points)
line_basement.set_points(result[0], result[1])

The result of the function can then be directly passed into the set_points function.
This saves the preallocation of empty point objects and counting the entries, which set_points requires.

If you are willing to take this in, I would need some guidance as to where to add it, then I can turn this into a PR.

hope it helps.

[Jason2866]

@s-hadinger

[s-hadinger]

Thanks for you suggestion. I would propose to extend it with the following:

• accept a flat list of 2*n values, because creating lots of nested lists consomes a lot of memory.
• accept a list of flat arguments

It means that the 3 alternatives would be valid:

# option 1 - as above
list_to_point_arr([ [1,2], [3,4] ])

# option 2 - flat list
list_to_point_arr([ 1,2, 3,4 ])

# option 3 - flat arguments as lists
list_to_point_arr([1,2], [3,4])

# option 4 - flat arguments as numbers
list_to_point_arr(1,2, 3,4)

# and mixing
list_to_point_arr( [1,2], 3,4)

[markusdd]

I have to say that I really like this idea a lot.

Obviously this even extends beyond what the line widget in LVGL does itself, but it is a very efficient way of drawing some more complex figures. And I think especially in Tasmotas context it makes a lot of sense because you usually will have some type of schematic on the screen (be it rooms, an arrangement of valves, switches, solar panels, whatever) and then you place the interactive stuff within it.

The proposed linemaker object could then either be fed with a list or list of lists on construction, immidiately returning the drawing, or if left empty, you can build piece by piece like you demonstrated.

[sfromis]

BTW. One nice pattern for builder classes is to have each method return self, allowing chained coding like:

var line_basement = linemaker()
  .to(left_x, top_y)          # top left origin
  .to(left_x + 450, top_y)    # north wall
  .to(left_x + 450, 190)      # outer door wall Nordkeller
  .build()

[markusdd]

True. This is e.g. how egui works in Rust, which I like a lot.

Of yourse what we dicussed now is a bit of a larger changeset than just the function, so where would we put this?

I would work on a PR for it but it will take me some time to do that on the side.

So: Where would this go?

[sfromis]

My starting point for that type of helpers would not be to perceive a "need" for integrating it in the base binary, but instead create a module which can be imported as any other, after copying it to the file system. That could even be in a .tapp file which will be automatically loaded after boot, and seamlessly do the import to have the feature directly available.

And then considering whether to have it a solidified part of the native build would come later. Sure, this would provide the benefit of not needing to use RAM for the dynamically loaded code. However, as you should already have PSRAM available for LVGL usage, the ceiling is not badly low for such.

[markusdd]

I think that makes a lot of sense.

Have some family matters to attend to right now but I will then open a draft PR where we can continue this discussion. I think this will make a nice useful addition.

Thanks for the input