Click here to Skip to main content
15,844,152 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more: , +
I wrote a graphics library for IoT - htcw_gfx and I'm thinking of writing some sort of WYSIWYG UI widget editor that generates code for a UI such that you can visually craft your user interface and it produces the code for you sort of like Winforms in .NET.

Here's the deal though - this is IoT and I am loath to whip the heap because we're dealing with only 10s of KB sometimes so fragmentation management is a challenge.

I have two approaches for doing this.

Approach A: This would be much like .NET winforms in that there is an object model, and controls derive from "control" and the code generation simply instantiates the object.

Approach B: This would generate code to do direct draws of things like buttons, and would not abstract them into an object model.

I'm inclined toward approach (B) due to the memory issues mentioned above. Also it would just generally perform better, and yet the generation itself is more complex, and the generated code takes a lot more cognitive load to navigate and more effort to maintain. One of the reasons is despite its drawbacks, it may be the only realistic way to run the UI on platforms with very little SRAM.

Approach (A) would generate much more maintainable code, and the generation process is easier but also requires a ton of upfront effort to produce an object model, and has its own maintenance problems because I have to maintain code in 3 places instead of two every time I add a new widget to the generator: The designer, the generator code, AND the object model. It also would whip the heap hard enough that it wouldn't be realistic to run on certain platforms.

Anyone have any opinions or suggestions in terms of what I should do?

What I have tried:

Not applicable here since this isn't a how to question.
Updated 29-Aug-22 4:38am
CPallini 26-Aug-22 9:54am    
Have a look at what Nextion did and do the opposite.

Maintainable code ist most important goal, esp when it is a longer running project. It is normal that building the model is a lot of work.
It is best practice to use some libraries which avoides a lot of common pitfalls and basic testing and bugfixing. Also update and portability problems are more professional and you may get better sample code or help for it.
Share this answer
honey the codewitch 26-Aug-22 10:52am    
That's good advice for desktop apps, but "general purpose library" and IoT are generally at odds with each other. Every abstraction costs, and when you're dealing with 80kB of RAM and < 100MHz sometimes it matters. Also, projects can't be very large on most devices.

I'm wondering if there isn't a way I can separate the generated code from application code that uses it, sort of like Microsoft's code-behind paradigm. That might give me the best of both worlds.
KarstenK 29-Aug-22 2:00am    
You cant have all. Normally library which are targeting a system are suitable for it. That also includes size. Maybe it has some release or compact mode.
Dont waist your time on incidental issues. You will loose!!!
honey the codewitch 29-Aug-22 11:16am    
I can't have it all, but I can endeavor to have the important stuff. I have a pretty solid instinct for when the design crystalizes and I can move forward with development, and I just haven't banged on this design enough yet. I'll figure something out that gives me everything I actually need, and I have the time to drag this out if it means getting it right.
KarstenK 30-Aug-22 9:18am    
your instinct will evolve with "experience". That is telling me my 20+ years instinct ...
honey the codewitch 30-Aug-22 9:19am    
Yeah. I've been coding since 1986, professionally since 1996, so I hear you.
It sounds like your analysis has more or less ruled out (A), in which case you're stuck with (B).

Some things that could help make (A) possible are
- a simple object model that only supports a limited number of widget types
- using field widths to pack member data
- adding widgets to an array that allows them to be accessed by an index instead of a pointer
- implementing memory management that uses fixed-size blocks (see my Object Pools article)
Share this answer
honey the codewitch 29-Aug-22 11:13am    
You're not wrong. In fact, I was thinking about a fixed scheme like you mention, and on reflection I realized that I would know how many widgets there were in advance. But runtime modification of said widgets is where I run into trouble. For example, as soon as I make it so you can change the text on a label at runtime, the complexity gets much higher. The reason being is I have to switch from laying things out on a screen by screen basis, to an "window/control" by "window/control" basis, and that means computing dirty rects and stuff, or using a painters algorithm on a godawful slow device.

At least that's where I'm at with my thinking now. I still haven't decided, because I'd prefer (A) if there was a good way to skin that cat, but (B) seems to be what I am leaning on in absence of that better way, so maybe I just need to spend some more time thinking about (A)

Edit: Hahaha I even swore in my comment. Now you know where my head is at.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900