Den 13-03-2012 12:04, Sven Anderson skrev: > Hi Andre, > > On 13.03.2012 08:47, André Somers wrote: >> Op 12-3-2012 12:33, Sven Anderson schreef: >>> if I implement QML types in C++, all slots are invokable from QML. >>> Usually I don't want that, because the slots are for C++ internal >>> communication. I found out (see older mail), that declaring the slots as >>> private makes them inaccessible from QML, but I can still connect to >>> them in the C++ world. My question is: can I rely on this, or is this an >>> unsupported feature? And a second question is: are there other good ways >>> of hiding slots from QML? >>> >>> Thanks and best regards >>> >> You could define a proxy QObject who's only purpose is to expose the API >> you want to expose to QML, and nothing more than that. All it would do >> would be forwarding the needed signals and slots to the real C++ >> implementation, that can be as complicated as you want as you don't >> expose it outside of the C++ context. This is also basically how you >> expose an interface for scripting, or for DBus. > > 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. If you don't receive an answer, you should probably interpret that as "I need to make my problem clearer". > So, you mean similar to a PIMPL pattern, like having a backend QObject, > that is created pairwise? Having two QObjects sounds quite heavy for a > simple QML item. And also the "proxy" Object would have to instantiate > the backend Object, not the other way around, since it is directly > instantiated by the QML engine. So it seems a bit weird to me. But it is the only way to truly control what is exposed. We had the same problems, questions and answers years ago with QtScript. 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. >> I would not recommend making slots private just to hide them from QML. >> While you can still connect to those slots from within that class, you >> can no longer connect to it from outside the class itself. That may hurt >> the API of that class. > > Huh? I can perfectly connect to private slots from outside the class. I > just tested it to be sure. 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. Bo Thorsen, Fionia Software. -- Expert Qt and C++ developer for hire Contact me if you need expert Qt help http://www.fioniasoftware.dk _______________________________________________ Qt-qml mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt-qml
