I had a look, you're basically fighting Qt there by using widgets (QLabel) for what is essentially content. Widgets do dynamic placement and size negotiation, and 3500 signal -> slot connections is another problem that gets you into O(N^2) territory. The canonical way would be to use an item model and only render the visible parts. Although that may still be too slow, given your numbers on emoji rendering. But it isn't a Qt problem then, per se.
I don't think this is correct. Sure, you could argue from the design perspective: we have models that are just "lists of emojis", most of them read-only, and we have "floating" views to display them, all read-only. Qt's model/view classes would be a match. But things like negotiating sizes and positions must be done anyways, it's now the job of "item delegates" instead of something derived from QWidget. Only doing that for the part that's currently visible isn't a good solution either. When the UI still allows having hundreds of emojis on screen at the same time, this will result in a lot of work when switching to a different tab. Although I never tried the model/view approach here (it's just a LOT more work, there's no view available for a floating layout of items, and adding a custom widget layout was much more straight-forward), I did some experiments trying the same (only initialize/render what's visible). As the event loop is blocked, unless you're doing dirty hacks with timers that just add a lot more overhead, even a delay of 500ms when switching tabs is very noticeable to the user and not acceptable to me. Possibly an implementation of drawing in an "item delegate" adds less overhead than QWidget does, but the problem itself remains...
In my custom code (without a toolkit, although this of course means there's a "builtin" toolkit now), all the emojis are widgets as well, so of course negotiating size/position is also part of the initialization of the UI, still it performs a
lot better. Good enough for "eager" initialization on startup, so e.g. switching a tab or scrolling happens "instantly" regardless of how weak your desktop might be. That's expected, as on the one hand, I don't need portability to e.g. win32/gdi or wayland, so I can use XRender (X11) instead of e.g. cairo, and on the other hand, my widget abstraction only needs to implement what's specifically needed for this application.
It's one thing to use it for your own limited application, and another to make it a user-extensible framework.
Actually, my implementation here
is generic, even the "type registry" works dynamically. It requires a certain amount of "boilerplate" and following conventions in each implementation of a class of course. But IMHO much more important, again: Most of the time, you should use very little inheritance anyways and just don't need polymorphism, and in these cases, implementations in C are straight forward, not requiring any "framework" at all.
Not what I meant. As explained there are hard limits to what you can express in C. But I suppose you have to encounter these situations yourself to acknowledge the limits.
I think it is what you meant, but I forgot to describe a mental step here: Whatever you "compose", in the end, what you delegate to a separate module
is functionality, which can always map to plain functions (and references/pointers to these) if you want,
but it can require adding abstractions for "generic" types. The latter is what C can't give you, short of
void *. Which doesn't make it impossible, but it's certainly ugly and very much limits what the compiler can do to help you ensuring correct code.
(and btw, before anyone accuses me of refusing to use the best tool for the job, there's a previous implementation of the same tool in C++ using Qt, and I ran into a dead end with that trying to solve some performance issue...)
