Well seems that it needs to emit model's layoutChanged() to do what I need. I created new class which inherits QListWidget and there I connected signal to layoutChanged signal of model() object and it worked.
There's a Qt Canvas 3D module in Qt 5.5 that provides WebGL-like interface to hardware accelerated 3D. It is layered on top of existing Qt's OpenGL support.
As for non-QML stuff, on WinRT Qt uses ANGLE, so if you stick to functions provided by Qt (e.g. QOpenGLFunctions) and not try to talk to the driver directly it should work just fine cross-platform.
Well yes, but you're painting that color with alpha over whatever widget is under the button, since the event filter is called before paint event of the button and you return true from it so the button's paint event is never actually called. To see the button painted underneath you need to actually call the paint event of the button manually before you overpaint it with your color.
You seem to have a very bad habit of just casting types with a C cast to whatever you think you need at the moment. I'm referring to the QWidget *widget = (QWidget *)object; cast in the eventFilter. If I used any non-widget QObject derived type with your class it would compile successfully and crash at runtime. There's a isWidgetType() method on a QObject that you can test with before casting. Also please don't use C style casts. It's just plain evil and you will cause bugs with it. Either to yourself or other people that use your classes. There's a lot safer qobject_cast for QObject derived types that will return nullptr that you can test for if the type can't be cast.
Painting in response to a timer with interval of 10ms makes no sense on almost any of user's machines. The typical display is ticking at 60Hz (i.e. little over 16ms) so anything lower than that is just giving Qt more work in filtering out the update requests you are flooding it with. Displays with a higher refresh rate are still very rare and even on them there's not gonna be a noticeable difference if you stick to 60Hz animation.
Using == operator on a floating point numbers is on borderline of being a bug. You should practically never do that unless you're actually testing floating number stability, which is like super rare. Use non-strict comparisons (< and >) or just stick to fixed point integers for steps like that.
Well I might have not been entirely truthful saying a layout has no size. After all it is a QLayoutItem and, as you pointed out, it has a setGeometry method. What I should have said is you shouldn't think about a layout in these terms.
There is rarely a case where you would manipulate a size of a layout directly or care about it at all, unless you're for example implementing your own layout, which is rare. You either change the size of the parent or the children and the layout with its (let's call it "virtual") size is a sort of bookkeeping mean to calculate the dependencies of parent and children. You can think of it as sorta "the magic that needs to happen", but I personally treat it as a publicly documented implementation detail :)
Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.