v8.2 discussion

[kisvegabor]

v8.1 is released so I open this issue to plan v8.2. In order really have a "Planning phase" for the next release I'm about to leave this issue open until 31 December and focus on implementation after that.

I add my current ideas here (see explanation in the next comment), please comment if you also have some features ideas in mind or share your opinion about the planned features.

Rendering

• Abstract render layer More flexible custom drawing interface #2733
• Widgets to image buffer
• 18/24 bit color format support

Features

• Scenes
• Add/Subtract/exclusive mask types arc obj:color display error when color opa was used #2668 (postponed for the next release)
• Style components
• Overflow:visible e7ac0e4
• Hover
• More grid features

Others

• New drivers architecture New driver architecture #2720
• Markup language Markup Language for LVGL #2428
• Unit tests Writing unit tests for core widgets #2337
• Fix scripts (postponed until there is real need for complex backporting)
• Release scripts
• SVG support
• Platform independent benchmarking
• ffmpeg support add ffmpeg decoder to extra/libs #2805
• font fallback support Supports Freetype fonts in SDL Driver #2796
• add monkey test feat(others) add monkey test. #2885
• add gradient dithering support Gradient dithering #2872
• add cmsis-pack support feat: add cmsis-pack for lvgl #2993
• add lv_gridnav Add grid navigation feature #2911

[kisvegabor]

The initial list and the features ideas are not written into stone, please tell what you think about them.

Fix/Release scripts

IMO it has the highest priority. I meant these:

• a CI action to merge commits with fix* message to staging/v8.* branches
• a CI or script to merge staging/v8.* to release/v8.* periodically or triggered manually
• add CI to port to automatically update submodules and conf files and minor and patch releases
• add a simple build CI test to the port projects

Widgets to image buffer

Make possible to buffer widgets with all children into a single image to

• speed up rendering at the cost of memory usage
• allow transformation on any widgets (rotate, scale)

Scenes

It's a brand new concept about how a UI can be managed. It's a very simple but very powerful thing. Each widget has an int scene_active field and there is an lv_obj_set_scene(obj, secene_id) function which sends LV_EVENT_SCENE_UNLOAD, saves the scene_id and sends LV_EVENT_SCENE_LOAD to the widget. In other words, the scenes can be considered as "states" of the widget (I do NOT mean pressed, focused, etc style states here).

Use cases:

• There is a parent that can display 3 types of content, each is considered a scene. On scene load/unload you can hide/unhide, fade, etc between the possible contents
• There is a screen with "error" and "normal" scenes: on error, some styles are changed, and an error message is displayed. On "normal" these are reverted.
• A list has 2 scenes: hidden, visible. On scene load instead of hiding/unhiding, any complex animation can be started.

The gist is, this way the widgets encapsulate their scenes and there is a uniform API for changing scenes. As the current scene is saved it can be automatically unloaded. Without this feature, the user needed to keep track of the current state to know what to unload, but now it'd be backed into the widgets.

Add/Subtract/exclusive mask types

Now the masks of LVGL can only subtract from an 0xff filled mask. It'd be great to allow "building back" parts too.

Style components

Right now it's a little bit cumbersome to manage differently looking versions of the same widget type. E.g. button, error button, warning button, border only button, border only error button, rounded button, rounded error button, etc. To manage it effectively there should be btn, btn_border_only, btn_rounded, btn_error, btn_warning styles. The combination of these styles needs to be added manually to the created buttons. It's possible to create btn_error_create() and similar functions but it's also cumbersome. If the "role" of the button changes meanwhile, it's also hard to manage now (i.e. remove styles and add new ones). The idea to solve it looks like this:

uint32_t ERROR_BTN_ROUNDED = lv_component_create_from(LV_COMPONENT_BTN);
lv_component_add_style(ERROR_BTN_ROUNDED, &error_btn_style, LV_PART_MAIN);
lv_component_add_style(ERROR_BTN_ROUNDED, &rounded_btn_style, LV_PART_MAIN);

lv_obj_t * btn = lv_btn_create(parent);
lv_obj_set_component_type(btn, ERROR_BTN_ROUNDED);

lv_obj_set_component_type can be called any time to change the type and ERROR_BTN_ROUNDED can be updated anytime too, and all objects will be updated.

The implementation is quite simple: If functions like lv_obj_style_get_bg_color don't find a style on the object, they check the styles assigned to the component ID too.
It will save memory and give more performance because the styles with the same selector can be merged in ERROR_BTN_ROUNDED and only the component ID needs to be saved in the object, instead of many styles.

Overflow:visible

Same as in HTML

Hover

Same as in HTML

More grid features

I'm specifically thinking about repeat(auto-fill, minmax( <value> px, 1fr)) but ideas are welcome

SVG support

See thorvg/thorvg#1014

[lishaoenxm]

@kisvegabor I've created a new issue #2800. Could it be added in this version?

[guoweilkd]

Modify qrCode lv_qrcode_delete() interface, replace it with lv_obj_del().In other words, rewrite Qrcode using obj template.

[kisvegabor]

@lishaoenxm
I'll comment in the opened issue.

@guoweilkd It's quite straightforward, so I've just updated the qr code widget. See 318edd8

[embeddedt]

Sorry for the delay in replying here. Here are my thoughts:

a CI action to merge commits with fix* message to staging/v8.* branches

I think it might be safer to check for the word "backport" in the commit description, otherwise the CI will end up cherry-picking fixes for a v8.2 feature into the v8.0 and v8.1 branches, which is not what we want.

add CI to port to automatically update submodules and conf files and minor and patch releases

Are we moving lv_drivers into lvgl for v8.2? That would allow us to have only a single submodule per port, which is ideal, otherwise we have to keep the two repositories working with each other.

Style components

It seems to me that all that is needed here is a way of linking styles to a parent style. This is what I'm envisioning:

static lv_style_t btn, btn_rounded, btn_warning, btn_error;

static lv_style_t error_btn_component;

lv_style_init(&error_btn_component);
lv_style_add_child(&error_btn_component, &btn_rounded);
lv_style_add_child(&error_btn_component, &btn_error);

Now error_btn_component can be used just like any other style, but has no properties of its own.

[kisvegabor]

No problem 🙂

I think it might be safer to check for the word "backport" in the commit description, otherwise the CI will end up cherry-picking fixes for a v8.2 feature into the v8.0 and v8.1 branches, which is not what we want.

True, although it can happen that the part being fixed already changed in v8.2. But, I agree "backport" is safer and probably will result in fewer issues.

Are we moving lv_drivers into lvgl for v8.2?

I think we should.

It seems to me that all that is needed here is a way of linking styles to a parent style. This is what I'm envisioning:

As styles don't store part and state e.g. a complete slider can't be described this way where there are main, indicator, and knob parts with any combination of states.

[C47D]

18/24 bit color format support

How hard could it be to add this feature? I'm interested in helping out with this one.

Should we also consider gray scale support?

New drivers architecture New driver architecture #2720

I'm also working on this, we had a couple of really busy weeks at work, I'm continuing with the new drivers architecture next weekend.

[kisvegabor]

How hard could it be to add this feature? I'm interested in helping out with this one.

I suggest waiting a little with it. We started to work on abstracting the drawing enginesand therefore the all drawing parts will be hugely refactored and rewritten. So it should be added once the architecture is stabilized to avoid complicated merging.

I'm also working on this, we had a couple of really busy weeks at work, I'm continuing with the new drivers architecture next weekend.

Awesome! It might be also related to the abstraction of drawing. See #2803 (comment)

[C47D]

I suggest waiting a little with it. We started to work on abstracting the drawing engines and therefore the all drawing parts will be hugely refactored and rewritten. So it should be added once the architecture is stabilized to avoid complicated merging.

Sounds fair, I will focus on the drivers.

[puzrin]

Scenes

It's a brand new concept about how a UI can be managed. It's a very simple but very powerful thing.

IMO this looks like mixture of CSS cascading & transforms animation. I would implement more classic features instead of invent new ones.

Style components

Right now it's a little bit cumbersome to manage differently looking versions of the same widget type. E.g. button, error button, warning button, border only button, border only error button, rounded button, rounded error button, etc.

I don't understand the problem. https://getbootstrap.com/docs/5.1/components/buttons/ twbs is ok with mixins.

If you need syntax sugar - leave it to CPP wrapper, instead of balloon C api. It's normal to add multiple styles (modifiers) to widget.

Hover

That's very expensive thing & not available on touch interfaces. IMO added value does not worth efforts. I'd suggest to postpone that as much as possible.

Markup language

IMO that's standalone project, described as "GUI creator tool with code generator". I'm skeptic about inventig/promoting new languages. Sugar can be partially solved via CPP wrapper. And visual gui builder is usually faster to create with js/html (electron and other).

Anyway, i'd prefer this thing separate from lvgl core. It may take too much efforts and slow down other development.

---

Also, it would be nice to temporary pause with adding new features & focus on pending tails - true RGBA support in styles, benchmarks infrastructure, CPP wrapper and so on.

[kisvegabor]

IMO this looks like mixture of CSS cascading & transforms animation. I would implement more classic features instead of invent new ones.

It's more than that and it's new only in LVGL. It's inspired by QT. See here.
It helps to make otherwise public states private and encapsulate them into a component resulting in a much-much cleaner implementation. The transition can be part of it, but it's "just" a tool to organize your UI in a much cleaner way.

I don't understand the problem. https://getbootstrap.com/docs/5.1/components/buttons/ twbs is ok with mixins.

It's possible but not convenient. E.g. a React button component is much more powerful where the component's style and logic are encapsulated into one object. My suggestion is not about logic only styles though.

If you need syntax sugar - leave it to CPP wrapper, instead of balloon C api. It's normal to add multiple styles (modifiers) to widget.

The problem came up while I was working on several UI projects. It's just tedious to manage styles as they are now. And if it was inconvenient for me, I suppose it's problematic for others too.

Of course, the idea can be polished, I just wanted to raise the topic and a possible implementation direction.

That's very expensive thing & not available on touch interfaces. IMO added value does not worth efforts. I'd suggest to postpone that as much as possible.

I'm personally interested in it because we are planning to support desktop app development too with EdgeLine so, it will come in handy. It needs to be designed in a way to not be expensive. 🙂

IMO that's standalone project, described as "GUI creator tool with code generator". I'm skeptic about inventig/promoting new languages. Sugar can be partially solved via CPP wrapper. And visual gui builder is usually faster to create with js/html (electron and other).

I consider having a markup language very important. I can't mention exact use cases due to NDAs but the need for a platform independent textual UI description came from many sources. It's will also help to find illogical parts in LVGL's UI, and clean it up as much as possible.

Also, it would be nice to temporary pause with adding new features & focus on pending tails - true RGBA support in styles, benchmarks infrastructure, CPP wrapper and so on.

RGBA, would be also a new feature. 🙂 I don't consider this as high priority task as it just joins to properties into one (color+opa). Cpp wrapper is on its way, but the development slowed down a little in the past month.
Benchmarking would be great, but some contribution would be also great with it. I add it to the list

[embeddedt]

Let's discuss the topic of managing old & new releases.

I think what we are thinking of right now (assuming 8.2 is the next release) is the following:

• master is the most bleeding-edge branch and has new features, bugfixes, etc.
• staging/v8.2 is identical to master.
• staging/v8.0 and staging/v8.1 accumulate any backported bugfixes from master.
• At release time, release/v8.0 is fast-forwarded to staging/v8.0, and the same for v8.1.

@kisvegabor You and I had discussed before the idea of requiring every commit to master to be a PR with approval.

This could work for automating backporting as well, as I could make an action which tries to backport to a specific branch when someone with appropriate privileges writes a comment like "@lvgl-bot backport v8.0" in the PR.

However, it means that every commit (including simple ones like these) would need a PR opened. I suppose it would ensure that CI passes on master all the time, so maybe it's a good step?

[kisvegabor]

Meanwhile, I was thinking about if it's really worse the effort to establish a complex backporting system. After v8.0 was released I manually backported some fixes but not that much. As I haven't heard complaints about bugs in v8.0. What if we say that if someone reports a problem in v8.0 (or an older release) we manually fix that problem. Seemingly there won't be too many cases.

We can find a proper solution if there is a real need for massive backporting (maybe never 🙂 )

What do you think?

[embeddedt]

True. The majority of the backporting only tends to be needed across major version boundaries, because a decent majority of users will upgrade to the latest 8.x release if asked.