Qt for MCUs is definitely interesting, but I wonder if they are able to go quite as low resource-wise as these other lite-graphics libraries (like Littlevgl mentioned in another comment).

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.

Could you share some details about the Pebble's UI framework and the general firmware (assuming Fitbit doesn't care that much)?

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)

What's the obstacle for making the Pebble framework open now that Pebble is gone?

Fitbit bought the company and presumably the IP (what else is there to buy?) so it would be up to them.

LittleVGL is MIT licensed.

QT is GPL and LGPLv3.

QT for MCUs is proprietary

BSD vs GNU/Linux market share.

You’re going to have to dumb that one down for me, if you care to explain.

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.

LGPL does not prevent you from using the library in a closed-source product, and recompile your software with a newer version of the library.

It only makes a difference if you alter the library. If you plan a proprietary fork, LGPL is not for you.

Correct me if I'm wrong but all of that only applies to LGPL if you dynamically link the libraries and it doesn't apply to GPL proper at all.

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.

No the LGPL has a clause for dealing with static linking [1]. It's more difficult to do (as the comment above us mentions).

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.

1: https://www.gnu.org/licenses/gpl-faq.en.html

I wish you had too! The Pebble Round was still my all time favourite gadget, and I loved the UI that had been built