Is it possible to officially support optional CPP api?

Feature request
#1

While LVGL is super-universal due C99 support, this does not means users MUST stay with C99 only. I suspect, many people will be ok to use something more advanced.

With CPP it would be possible to use chained calls, especially useful for:

  • describe layouts
  • fill (CSS) classes with style properties
  • implement some things of reactive frameworks

I’m not going to promote OOP. I mean nice syntax, impossible with C (unfortunately).

No idea about maintenance cost. Sorry, if question looks naive.

What do you think?

1 Like
#2

LVGL has micropython binding that allow all that.
The micropython binding is automatically generated from LVGL headers.

With some work, you could automatically generate C++ headers to wrap LVGL API with the same technique.

#3

My question is, can this be supported “officially” as out of box option? Or, at least, can this be considered seriously? If yes, then we could follow to details, and thinking how to minimize support’s cost.

I’m not one of lvgl core devs. May be they have different vision about lvgl future and priorities.

#4

Do you already see what is required to achieve this?
E.g. converting every object into classes?

#5

I did not analyzed too deep. At first glance:

  • facade classes, without state, with reference to lvgl object.
    • this should allow almost zero cost casting of lv structs to classes
  • some methods should return this for easy chaining.
    • no idea what to do if error happens (may be something like get_last_error + exceptions for debug builds)
  • may be some CPP specifics for copy/move/forward constructors

In other words, first step is to simplify data fill when you describe layout of your app:

  • add multiple childs to parent
  • add multiple styles to object
  • add multiple properies to style
  • (?) set multiple params for object

Then it will be more easy to understand where to move next:

  • May be some sugar for events, to beautify subscribe & handlers.
  • May be use methods overload to simplify names.
  • How to simlify object extend & custom data assign

I have no abstract demands for 100% OOP API. Only for concrete well-known use cases.

#6

To keep the core LVGL lib lightweight and simple it can be added as an extension. (similarly to micropython as an lv_binding_cpp)

It seems the script written for the Micropython binding can be used here to generate classes.

If someone is interested in working on it, please open an issue on GitHub.

#7

It’s not principal for me, if CPP wrapper will be in the same or in separate repo. Question is about maintenance of next versions. Who will be responsible for that? Micropython binding is alive only until maintainer “exists” (thanks to @amirgon for his great work).

I could try to create CPP draft, but:

  • I don’t like to become maintainer.
  • I have skills of software architect, but no experience with CPP - code quality will be very intermediate. So, i could care about methods/signatures, but this needs someone more experienced to finish properly.
#8

Theoretically maintaining a ninging like this shouldn’t be so complicated if choose wisely which parts should be converted to CPP.

@amirgon
How much effort does it take to maintain the MP binding repo if there are no major (MP breaking changes)?
It seems to me answering questions take more time. Is that correct?

#9

The Micropython binding is generated automatically from lvgl header files, so as long as changes don’t break anything - it’s zero effort to maintain it.

On the other hand, building the binding script on the first place - was a big effort.
Migrating to v.7 required many discussions and additional effort.

In case of C++ binding, it would take some effort to bring it up, but less than Micropython because C and C++ play nicely together (easy to call C from C++, can use C structs on C++, no need to handle memory garbage collection, etc.)
If the C++ binding would take the same approach as the Micropython binding and be generated automatically from lvgl headers, it would take zero effort maintaining it for non breaking changes once it’s stable enough.

1 Like
#10

Is in possible to collect info about “Are LVGL users ok to use CPP”? I understand, some projects have strict C99 requirements. But how much %?

Just interesting, how popular CPP extension could be.

#11

I’d be also curious. Just created this vote: [VOTE] With which language(s) do you use LVGL?