[Development] Question about Qt's future

[Roland Winklmeier]

>
>
> > > If I want to access this methods from QML I would have to derive them
> > >
> > > > from QObject and register it in the QML context.
> > >
> > > Not necessarily, depends on what you want to do.
> > > However, it is true that it would be nice to have something similar to
> > > QtScript's binding facilities.
> >
> > Agree with Roland.  Must.  I MUST have "Cytometer" and "Laser" and
> > "Wavelength" exposed to QML.
> >
> > In only the "simplest-of-toy-applications" could we pretend that a
> > "QmlCytometer" exposed to QML has a vector-of-double values to represent
> > the "several-wavelengths" that might be associated with that "cytometer".
> >
> > In our system:  We code-gen to wrap everything.  "Wavelength" is now a
> QML
> > exposed property of "Laser", which is a QML exposed property of
> "Cytometer".
>
> What I meant was: what kind of operations in QML do need access to these
> compond types?
>
> For example in a widget based UI you wouldn't have a standard widget [1]
> that
> knows how to display or enter a Wavelength, right?
>
> You would have some adapter code that will take a Wavelength object and
> then
> process it into something a standard widget can handle.
>
> Why does the adapter code no longer suffice?
>
> Since I don't know about your data types let me try a different example.
>
> If I had the need to display width/height/depth of an image I would likely
> have a widget that has three labels or read-only spinboxes, neither of
> which
> can read the image properties themselves.
>
> So I would have adapter code that takes a QImage and accesses its width(),
> height() and depth() methods and put those into the widgets.
>
> As far as I can tell I could use the exact same adapter code if the UI was
> in
> QML.
> For additional declarative niceness I might be inclined to expose the
> wrapper
> in the form of a type with an image property for input and three
> appropriately
> named integer properties for output.
> But the actual adapter code would be the same.
>

What you are saying is correct and I'm not an expert in GUI design (sorry
if my explanations violate any Model-View theorems), but here is a real
world example.
Lets say we have a UI to display the Com and NAV frequency settings of your
aircraft. The whole aircraft is encapsulated in a CAircraft which looks
similar to this

class CAircraft
{

public:
    CComDevice getCom1() const;
    ....
private:
    CComDevice m_com1;
    CComDevice m_com2;
    CNavDevice m_nav1;
    CNavDevice m_nav2;
}

class CComDevice
{
    enum Unit
    {
        MHz,
        kHz
    };

    CFrequency getFrequency(Unit unit) const;
    ....
private:
     CFrequency m_frequency();
}

In a C++ QtWidget environment I'm now able to do the following to display
the frequency in a widget:

dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();

The main points are that at the time of writing the C++ model I don't know
which unit the user might select during runtime - MHz or kHz. So I need to
invoke getFrequency or call it from a wrapper.
In general I don't know what a GUI designer might need.
The second point is that the C++ data models are nested a lot and they are
easily accessible in C++ code because C++ of course knows how all these
data classes look like. The idea behind that is, the GUI designer can
choose what he wants to display and how. This is transparent to the C++
models.
Ideally I can to the same via QML by accessing the property hierarchy. This
would mean my data models are decoupled from my QML view implementation:

dataModel.aircraft.com1.frequency.string

but that requires of course that all classes are known in the QML context
which is not possible (if they dont subclass QObject).
As you said I can of course create C++ wrappers specific to a view, add the
line
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
into it and transfer the result as a QVariant, but that also means QML is
limited to what the wrappers provide. This is a loss of flexibility
additional to the effort writing the wrapper. This is of course possible
but not nice. Widgets are a lot more flexibel. If I want to display
different data in my view, I have to add/change only one line C++.

I'm missing this flexibility in QML to walk through my nested objects and
display in QML whatever I like. Having that, I would be a fan of QML :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140422/96ea1dab/attachment.html>