[Interest] qml desktop corner
416365416c at gmail.com
Thu Jun 27 22:09:29 CEST 2013
On Tue, Jun 25, 2013 at 4:48 AM, Rutledge Shawn
<Shawn.Rutledge at digia.com> wrote:
> On 25 Jun 2013, at 10:55 AM, Damian Ivanov wrote:
> 5) yes Alan wants to add something like anchors eventually, so then this example could be done elegantly; but it's not done yet, and it's not easy to do because a Window is not an Item, so the existing anchors attached property cannot be reused as-is. In an ideal OO language, there should have been an inherited class (or interface or mixin) which specifies rectangular geometry without assuming that it's a renderable thing like an Item, and then pointers in anchors and other places should use that type instead of QQuickItem *. But we always use single inheritance because only the top class in the inheritance chain can inherit QObject. The point of putting the rectangular geometric accessors in a mixin would be to have them be properties too; but moc only looks at the properties that are declared in the header that it's looking at. (Somebody correct me if this is actually possible somehow.) QQuickWindow inherits QWindow which inherits QObject; and QQuickItem inherits QObje
> ct. They are in different modules, too. So that's why it's hard to have a common inherited interface which the anchors could use, even though they are both just rectangles from the anchors' perspective. This is the situation that Interface is good for in Java.
You forget that we have a meta-object system built on top of C++. We
could have the C++ typing require only that the target is a QObject,
and then do a runtime check on the properties available, and then
access the properties through that interface. Kinda breaks how half
the point of anchors was to be more efficient than property bindings,
but maybe that can also be solved under the covers...
More information about the Interest