Hi Artur, On 17. juni 2010 16:59, ext Artur Souza (MoRpHeUz) wrote: > Hi all, > > I have a set of methods in a class that has overloaded versions. In > order to export them to QML I needed to create a QObject with one slot > for each overloaded version. For example, one of my set of methods is: > > - i18n > - i18nc > - i18np > > Each one of these methods have a second overloaded version of them, to > accept more parameters for example. Just making the overloaded methods > being slots does not solve the issue and overloading slots has some > problems like breaking badly with default arguments. > > At this time, to export this to QML I needed to create a QObject with > 6 slots (one slot for each overloaded version of the method). > > - i18n > - i18na > > - i18nc > - i18nca > > - i18np > - i18npa > > In the past, as I have QtScript bindings for the same methods, I could > properly handle this use case on the binding code (users on QtScript > side just call the function and I check the number of arguments given > and call the proper method, etc...). >
If overloaded slots and/or QtScript's handling of them is busted, then we'd like to know about it. "Check the number of arguments given and call the proper method" is what QtScript should do already. You will get ambiguity errors if QtScript's argument conversion can't uniquely determine what overload to call though; is that what's happening? What are the signatures of these methods, and how do you resolve which overload to call from your QtScript binding? > The problem is that currently there is no way of having access to the > QML's script engine or even setting my own, what would solve all this > issues and would enable me to even share more code and avoid > duplication in my code base. > The use of QtScript in QtDeclarative is currently an implementation detail, which is also why we don't expose it. QObjects are supposed to be the one way to interact with native stuff (in the scope of 4.7, at least). It does indeed suck that you can't reuse bindings that use the QtScript API. But the QML JS environment is not a "normal" QtScript environment; everything is done via scoping (per declarativecontext, per component, per binding). The Global Object is read-only, so you couldn't expose the bindings there. Even if you could get at the QScriptEngine, I'm not sure how you would be able to add anything to it (in a non-hackish way, i.e. that's not going to break when QML internals are changed). I _think_ you should be able to get the engine by creating a C++ slot that takes a QScriptValue as argument, call that slot from QML, and call QScriptValue::engine() on the argument. If thats works, it effectively means we do already expose the QtScript API in public, but not with the intention to use the full API (e.g., it should be fine to call toNumber() on the QScriptValue, but not, say, installing a custom QScriptEngineAgent on the engine()). Hmm, taking this idea further, did you try subclassing QScriptable? Then you could get at the arguments and thisObject() too. :-) Best regards, Kent _______________________________________________ Qt-qml mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-qml
