I really wish we had open-sourced the UI framework we built for the Pebble firmware.
I really wish we had open-sourced the UI framework we built for the Pebble firmware.
TFA boasts RAM usage of 9kb. That's something you can run on almost a literal potato, and I'd be frankly astonished if Qt devs have been able to go as low.
On the other hand, you can build a somewhat nice system with graphics already with a Cortex-M4 and 512 kb of RAM. That sounds something that Qt just might be able to reach, which would be quite awesome.
OT Aside, but important to me: I was super excited about the Pebble Time and with it being marketed a "geek watch" expected a super open device I could program with custom haptics, use the microphone, get replacement parts etc and was super disappointed when I discovered none of this was possible.
(Bonus aside: If you found yourself agreeing you might be interested in Rebble and the Pine Time)
QT is GPL and LGPLv3.
My comment on the license was from an embedded perspective - if you do a bare metal product I believe adhering to *GPL becomes difficult since you have to proved the ability to update QT. Sure, there are ways to allow this but it’s not straight forward.
I’m not sure why I got downvoted for my previous comment - I mean, I just posted the license types.
It only makes a difference if you alter the library. If you plan a proprietary fork, LGPL is not for you.
When people say "embedded" they usually mean devices that run on low end bare metal hardware without an operating system (or even a memory controller!), which means nothing to provide dynamic linking, let alone the kind of end user control that the GPL philosophy is meany to promote. The vast majority of embedded software is statically linked by design so even the permissive parts of the LGPL don't apply.
Using static linking requires you to provide program object files which can be relinked (and re-uploaded I'd presume). This allows the user to modify the LGPL file, and then relink the original program to the updated version.