2014-04-24 22:42 GMT+02:00 Dominik Holland <dominik.holl...@pelagicore.com>:
>
> I like that idea, but couldn't we do something like this ?
>
> qRegisterWrapper<MyWrapper>(qMetaTypeId<YourType>())
>
> MyWrapper is a QObject based class which can whatever you want and gets
> YourType as reference or per value.
>
> It would mean you create your wrapper once for all your Types of your
> Interface and afterwards the QmlEngine will create the Wrapper
> automatically for every object which is exposed to QML.
>
> I could also think of having some automatically created wrappers for
> QList<YourType>.
>
>
> The wrapper itself gives you the flexiblity to decide whether you can
> support changedSignals of what functions you want to expose to QML.
>
> In the end it would also be great to register the Wrapper as a own QML
> Type to be able to create the object in QML.
>
> Dominik
>
>
This is similar to what I had in mind in first place. I don't have
experience with the Qt script engine and how powerful it is, so I cannot
really comment on it.
To my knowledge QObject wrappers are the only solution atm to expose type
safe variables, because signals and slots require the QObject base class.
QQmlValueType is a good starter. It needs for sure some improvements and
careful thinking, but it is the easiest way of doing it.
Unfortunately it produces a lot boiler plate code, cause you have to write
a wrapper for each non-QObject class you want to expose. In an ideal world
we could register them without any wrapper (although I don't know how we
would bind their methods then). In a nearly perfect world we would have a
generator for this wrappers, similar to moc. You for example mark your
custom class with some macros and a generator creates the wrappers for you
during compile time.
class MyValueClass
{
VALUE_PROPERTY( int value READ value WRITE setValue )
VALUE_PROPERTY( int anotherValue READ anotherValue WRITE
setAnotherValue )
public:
MyValueClass();
~MyValueClass();
int value() const;
int anotherValue() const;
setValue(int value);
setAnotherValue(int value);
private:
int m_value;
int m_anotherValue;
};
Doing wrappers manually is a bigger maintenance effort to keep both in
sync, an automatic step would reduce the burden.
The explanations regarding QVariantMap were really interesting and for
smaller projects this is for sure a good idea. But as others already said,
it has several drawbacks. In general, however, you explanations about MVC
made sense.
The line
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
can for sure moved into a model/controller class dedicated to a specific
view. But in this case i still need to transfer a CFrequency object to QML
and no QString. The reason is simple and you immediately see it if you look
into the API of CFrequency:
class CFrequency
{
public:
enum FrequencyUnit
{
Hz,
MHz,
kHz,
};
double getValue(FrequencyUnit unit);
...
private:
int m_siValue;
};
It has only one private member, but the returned value from getValue
depends which Unit you want to have and is automatically calculated during
runtime. Imagine a class CTemperature, which has the value in celsius but
someone wants it in Fahrenheit getValue(TemperatureValue::Fahrenheit);.
Which values would you put into QVariantMap? The SI value or all of them?
The design of this classes is, that you can decide during runtime, which
value you want to display depending on the application settings.
Theoretically I could create a controller class doing this step for me. So
the view class provides the unit as user input and the controller class
updates the QVariantMap. But this would mean, I have a stupid view class
and have to do all the logic in C++. This is fine if I use plain QML, but
as soon as I want to do some logic in JS, the engine needs to know the
types.
So to summarize, we are discussing two different concepts:
* In order to use plain QML, QVariantMap can be sufficient. QML as the view
implementation does not need to know the data structure.
* As soon as someone wants to move some logic from C++ into JS, JS needs to
know the data type.
According to my understanding it is the second one we are discussing here.
Roland
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
