Feedback on interoperability

[KaruroChori]

Just my two (three) cents on how this XML solution can be maximally useful without affecting your funding structure (too much).

• There should be a clear XML schema definition for all the basic widgets and the rest of the glue components, either as RelaxNG or any alternative supported formats. These schemas should be freely distributed for interoperability.
• Support for namespaces. Ideally here should be an optional lvgl/lv explicit xml namespace so that we don't end up with interference of symbols as many of these names are very generic.
• The transpiler from xml to c code should be free, regardless of tiers or licenses. And possibly distributed as a lightweight standalone unit capable of headless execution.
  I agree that designing and editing custom widgets should be locked down with licenses if that is your objective, but keeping the basic usability of custom widgets one has already developed behind a paywall would be an instant deal-breaker for me.

[kisvegabor]

Hi,

Thank you for the feedback!

There should be a clear XML schema definition for all the basic widgets and the rest of the glue components, either as RelaxNG or any alternative supported formats. These schemas should be freely distributed for interoperability.

Our idea is something similar:

• Describe the API of the widgets/components in XML in simple way. E.g. this.
• Automatically generate a schema from the XML APIs. RelaxNG could be good language for the schema.
• The schema contains all widgets/components.
• Validate all XMLs against the schema.

Having syntax highlight and error checking is very basic feature so it will be available in the free version and probably we will add an CLI for it too.

Support for namespaces. Ideally here should be an optional lvgl/lv explicit xml namespace so that we don't end up with interference of symbols as many of these names are very generic.

I was thinking a lot about it and realized that it's not really required. For example the builtin button widget is called <lv_button>. If you create a new button component or widget you can name it like <button>, <my_button>, <ui_button>, <dashboard_button>, etc. So the component libraries won't collide as you need to name the components correctly. I think being so explicit about the names is better than having XML name spaces. What do you think?

The transpiler from xml to c code should be free, regardless of tiers or licenses. And possibly distributed as a lightweight standalone unit capable of headless execution.
I agree that designing and editing custom widgets should be locked down with licenses if that is your objective, but keeping the basic usability of custom widgets one has already developed behind a paywall would be an instant deal-breaker for me.

Of course, exporting C code for components will be available in the free version. However we consider the custom widgets an advances use case, where we assume that the user is making money with the help of the UI editor. So it makes sense to draw the line here. Where would you draw the line? Which features would you put behind the a paywall?

[KaruroChori]

I was thinking a lot about it and realized that it's not really required.

I was more worried about keywords like widget, api, prop ... (ref https://github.com/lvgl/lvgl_editor/blob/master/examples/widgets/dark_slider/dark_slider.xml). But yes, this extends to lvgl components too, as the idiomatic way to handle this problem in XML is not by scoping like one would do with C exported symbols, but with namespaces.

Why does it matter? Because it is XML 😄 !
It would be bad to prevent interoperability with external workflows just for something this minor.
For example, one might want to use XSLT to transform xforms into lvgl components.
Or to embed custom data as XML within the UI itself.
And probably much more right now I cannot envision.
My point is that it is very hard to know in advance how something will be used (and possibly abused) if it not there yet.
Still, part of the "beauty" and added value XML offers is the ecosystem of tools, and the pipelines it enables.
An idiomatic use of namespaces avoids self-locking out of those.

Which features would you put behind the a paywall?

I am afraid I cannot answer this question. This is clearly a balancing effort to make sure stakeholders are happy, your company financially fit, and the ecosystem is not negatively impacted.
I just lack context to answer this properly, and to be honest I don't envy you for having to make this choice at some point 😄 .

Still, my main problem, and what others I am confident would perceive as well, is future proofing any work being done using your product. If one allocates paid hours to train their employees on it, and buy licenses for their developers, the last thing they want is 10 or 15 years from now to be requested for a minor revision by a client, or a new build just to target a different architecture/os version, and have to figure out how to do that if not in a best case scenario.
What would happen if your product is no longer sold?
Or the new versions are not backwards compatible, and older builds are no longer offered?
Or the cost of a licence a decade after, for that task only, is not financially viable.
I am just making up a couple of scenarios, but it is not like something like that has never happened.
Now their fancy files are useless, as they cannot reproduce the original build, and everyone is extremely unhappy.

That is why I was suggesting that paywalls and arbitrary limits on the active features users are supposedly requiring during development are totally reasonable.
But working on a complex project with custom widgets today and not being able to transpile them fully tomorrow is a serious concern.
As much as I hate them, digital signatures in this case would at least mitigate this problem. You could at least sign XML widgets to ensure they have been constructed with a properly licensed product. And if the transpiler is able to validate that signature, no matter how long ago it was, that component can be transpiled, since it was clearly developed while being licensed.

I am just throwing ideas, as I have no idea if you are planning to have a fully standalone installation which does not phone home, or some hybrid application requiring people to work in your cloud system. So it is hard to determine what can be reasonable and what is not. But I hope I made clear where I would try to draw the line if it was up to me.