Hi Bo, On 13.03.2012 16:11, Bo Thorsen wrote: >> Thanks a lot for your answer. I'm used to getting ignored on this list >> most of the time. ;-) > > No, not ignored. But sometimes people just don't have answers here. QML > is still quite new and it's so complex that few people truly understand > what's going on when a problem becomes very involved.
Sure, I was not really serious here as the smiley indicates. I fully understand that it's my subjective perception when I have the impression that I hardly get any reaction (even when I answer questions) while others get reactions immediately. But I think it's a fact, that the responsiveness of the QML community is a lot lower than that of the general Qt community, which makes it sometimes hard to find solutions. I always thought, Qt Quick is a hot topic and very popular. So, maybe we can improve the interaction somehow? Someone on #qt-qml even believed, that this list doesn't exist anymore and suggested moving it to lists.qt-project.org. > It's so rare that you really need to control it, that you have to use a > facade pattern or proxy object for it. It doesn't make any sense to try > and add something like "Q_INVOKABLE NON_QML_EXPORTABLE" for those few cases. Is it really so rare to have QML and non-QML slots in one QObject? I thought it's even the normal case? Or do you mean it's rare, that the exposure of the non-QML slots is not acceptable? > Just because it works doesn't mean it's a good idea. Slots can be called > as any other methods, so making it private has different meanings too. > Use public, private and protected as you would in a non-Qt C++ class and > live with the QML exposure. > > Personally, I've never accepted that you can connect to private slots > from other objects, but that's a different (and not worth having again) > discussion. The problem is, that the semantics of the access modifiers are only clear for the case of the direct call (pure C++), as you can see at the confusion. As soon as you bound these semantics to other call systems (metobject calls, calls from JS, ...) you run into problems, where you don't want the same access rights for all call systems. To solve this in a clean way you would have to introduce access keywords for each system, like Q_PRIVATE, Q_PUBLIC regarding QMetaObject::invoke() and Q_JS_EXPORT for JS/QS/QML calls. That way I could avoid a slot to be called directly by declaring it 'private Q_PUBLIC' (behavior at the moment), or have a real private slot with 'private Q_PRIVATE'. But probably that would be over-engineered. Cheers, Sven _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
