4. QML Layout

QML Layout

  • M

    Das Problem ist, dass ich bei QML den grundlegenden Aufbau einfach nicht verstehe. Mir ist nicht klar, wie das alles konkret zusammenspielt.
    Ich hatte schon mit so vielen GUI Frameworks zu tun, und jetzt hab ich endlich eins gefunden, das ich nicht kapiere...

    Ich hab dein erstes Beispiel genommen, das funktioniert so.
    Dann ersetze ich das ListModel wieder durch container.settings (ein QStandardItemModel) und es funktoniert nicht mehr, kommt in der Konsole, dass er name und paramNames nicht kennt. Warum? Das hat doch vorher mit meinem kaputten Layout auch funktioniert. Wo ist der Unterschied?

    Das ist auch genau das, was mich an QML stört. Ich finds einfach undurchsichtig und komm nicht dahinter, wie das funktioniert. Und da ist so viel Code und Dynamik dazwischen, dass man da auch schlecht reindebuggen kann (außer, man weiß schon, wie das funktioniert, und was man debuggen muss).

    0
    L
     1 Antwort
  • L

    Dieser Beitrag wurde gelöscht!
    0
  • L

    @Mechanics Kannst du mal dein Model zeigen?

    0
  • M

    Den eigentlichen Code würde ich ungern zeigen...
    Die roleNames setze ich, bzw. habe ich überschrieben. Ansonsten werden QStandardItem´s erstellt und ins Model gehängt (und die haben Daten unter den entsprechenden Rollen).

    Was interessant ist, in roleNames kommt er nicht rein. Wenn ich das auf meinen ursprünglichen Aufbau reverte, kommt er in roleNames rein.
    Das geht schon vorher beim Binding schief...

    Das property settings wird aus einer anderen Qml gesetzt. Da gebe ich objectName in der Konsole aus, das ist auch das, was ich erwarte.

    0
  • L

    Basierend auf deinen Beschreibungen kann ich nicht sagen, woran das jetzt genau liegt. Ich würde das ganze mal vereinfachen.

    Wenn du Zeile 28 - 37 mal auskommentierst, also die ListView in der ListView klappt es dann? Oder meckert er, dass er immer noch das "name" in Zeile 25 nicht kennt?
    Sollte er da meckern, würde ich "name" in Zeile 25 mal durch einen statischen String ersetzen und gucken, ob es dann funktioniert, um schon mal sicher zu sein, dass er das model lädt.

    0
  • M

    Bin ich blöd 😞
    Ich hatte noch ein Element dazwischengeschoben, damit war mein property settings auf dem falschen Element deklariert.

    Jetzt klappt das, aber mit displayName hat er noch ein Problem. Das ist eine QVariantList, und die Element da drin sind QGadgets. Muss aber eigentlich wieder ein anderes Problem sein, hatte ja auch schon geklappt.
    Aber das schau ich mir morgen an.

    0
  • L

    Deine Kritik kann ich trotzdem unterschreiben, das debuggen fällt mir bei QML auch schwer. Meistens läuft es auf ein Ausprobieren hinaus ... schrittweises auskommentieren bzw. beim entwickeln einfach anfangen und direkt immer testen, um Probleme frühzeitig zu entwickeln.
    Sobald ich dann mal ein Code Schnippsel umschreibe, funktioniert es oft genug nicht und man sucht lange nach dem Fehler.

    Zusätzlich vermittelt QML auch den Eindruck, man müsste keine Ahnung haben, was man da macht ... so deklerativ kann ja jeder und so. Bei QML kommt man aus meiner Sicht nicht drum herum zu lernen wie es wirklich geht.

    1
  • M

    Ja, vor allem ist mir der Aufbau auch tatsächlich nicht klar. Selbst bei WPF (und das dürfte nochmal komplizierter sein) fand ich das logisch und gut nachvollziehbar, wie was aufgebaut oder aufzubauen ist. Bei QML erschließt sich mir vieles einfach nicht und schaut dann nach Black Magic aus.

    Ich debug das jetzt seit zwei Stunden und kapiere immer noch nicht, warum das mit der QVariantList und den Q_GADGETS nicht geht.
    Alles was ich bisher angeschaut habe, geht. Er holt aus dem QStandardItemModel die QVariantList raus, konvertiert die Liste und alle Elemente in der Liste (Q_GADGET) in QJSvalue Objekte.
    Dann kommt QQuickItemView::setModel, er bekommt ein QJSValue rein und macht wieder eine QVariantList draus, wo die richtigen Objekte drin sind.
    Alles total umständlich mit vielen unnötigen Kopien usw. Aber es geht.

    Dann kommt QQuickListViewPrivate::addVisibleItems. Und das createItem hier geht schief:

    if (!(item = static_cast<FxListItemSG*>(createItem(modelIndex, incubationMode))))

    Und das ist nicht mehr lustig zum Debuggen.

    Das ist der Callstack von createItem bis zu der Exception:

     	Qt5Qmld.dll!QV4::ExecutionEngine::throwReferenceError(const QV4::Value & value) Line 1200	C++
 	Qt5Qmld.dll!QV4::Lookup::resolveGlobalGetter(QV4::ExecutionEngine * engine) Line 135	C++
 	Qt5Qmld.dll!QV4::QQmlContextWrapper::getPropertyAndBase(const QV4::QQmlContextWrapper * resource, QV4::PropertyKey id, const QV4::Value * receiver, bool * hasProperty, QV4::Value * base, QV4::Lookup * lookup) Line 356	C++
 	Qt5Qmld.dll!QV4::QQmlContextWrapper::resolveQmlContextPropertyLookupGetter(QV4::Lookup * l, QV4::ExecutionEngine * engine, QV4::Value * base) Line 478	C++
 	Qt5Qmld.dll!QV4::Moth::VME::interpret(QV4::CppStackFrame * frame, QV4::ExecutionEngine * engine, const char * code) Line 641	C++
 	Qt5Qmld.dll!QV4::Moth::VME::exec(QV4::CppStackFrame * frame, QV4::ExecutionEngine * engine) Line 511	C++
 	Qt5Qmld.dll!QV4::Function::call(const QV4::Value * thisObject, const QV4::Value * argv, int argc, const QV4::ExecutionContext * context) Line 69	C++
 	Qt5Qmld.dll!QQmlJavaScriptExpression::evaluate(QV4::CallData * callData, bool * isUndefined) Line 211	C++
 	Qt5Qmld.dll!QQmlBinding::evaluate(bool * isUndefined) Line 209	C++
 	Qt5Qmld.dll!QQmlNonbindingBinding::doUpdate(const QQmlJavaScriptExpression::DeleteWatcher & watcher, QFlags<enum QQmlPropertyData::WriteFlag> flags, QV4::Scope & scope) Line 245	C++
 	Qt5Qmld.dll!QQmlBinding::update(QFlags<enum QQmlPropertyData::WriteFlag> flags) Line 187	C++
 	Qt5Qmld.dll!QQmlBinding::setEnabled(bool e, QFlags<enum QQmlPropertyData::WriteFlag> flags) Line 552	C++
 	Qt5Qmld.dll!QQmlObjectCreator::finalize(QQmlInstantiationInterrupt & interrupt) Line 1385	C++
 	Qt5Qmld.dll!QQmlIncubatorPrivate::incubate(QQmlInstantiationInterrupt & i) Line 345	C++
 	Qt5Qmld.dll!QQmlEnginePrivate::incubate(QQmlIncubator & i, QQmlContextData * forContext) Line 91	C++
 	Qt5Qmld.dll!QQmlComponentPrivate::incubateObject(QQmlIncubator * incubationTask, QQmlComponent * component, QQmlEngine * engine, QQmlContextData * context, QQmlContextData * forContext) Line 1097	C++
 	Qt5Qmld.dll!QQmlDelegateModelPrivate::object(QQmlListCompositor::Group group, int index, QQmlIncubator::IncubationMode incubationMode) Line 1081	C++
 	Qt5Qmld.dll!QQmlDelegateModel::object(int index, QQmlIncubator::IncubationMode incubationMode) Line 1115	C++
 	Qt5Quickd.dll!QQuickItemViewPrivate::createItem(int modelIndex, QQmlIncubator::IncubationMode incubationMode) Line 2292	C++

    Ich hab da auch nicht so ganz gerafft, was er mit den Daten aus dem Model macht. Das createItem muss ja erstmal ein Text Item erstellen. Und der Zugriff auf das displayName erfolgt erst innerhalb vom Text Item. Aber wie das jetzt durchgereicht wird, habe ich erstmal nicht gesehen. Hab jetzt aber erstmal wieder keine Lust mehr. Ich dreh noch durch damit...

    Fällt jemandem mit den Informationen vielleicht noch was offensichtliches auf, wo ich mich vertan habe? Es muss ja eigentlich was offensichtliches im QML Markup sein.

    0
  • F

    Ohne vollständiges minimales Beispiel wird dir wohl keiner helfen können.

    0
  • M

    Ok, habs jetzt noch schnell durch Raten hinbekommen, es geht mit modelData (modelData.displayName).

    Finde ich vom Namen her auch nicht abwegig, nur verstehe ich das nicht ganz. In der Doku steht:

    "Models that do not have named roles (such as the QStringList model shown below) will have the data provided via the modelData role. The modelData role is also provided for models that have only one role. In this case the modelData role contains the same data as the named role."

    Das würde erklären, warum name und paramNames gehen, die kommen aus einem QStandardItemModel und ich habe role names definiert.

    D.h. im Endeffekt, das geht wirklich nur mit Models und roleNames, und ein QObject oder ein Q_GADGET (die auch auslesbare Property Namen haben) brauchen immer ein modelData?

    @firefly : Mimimalbeispiel wäre das:

    Das settings ist dabei ein QStandardItemModel, und paramNames (der Name macht wenig Sinn, hatte Leon in seinem Beispiel besser genannt) ist eine QVariantList mit Q_GADGET Objekten. Die haben ein Property displayName und damit hatte ich eben Probleme, bis ich versuchshalber modelData dazugeschrieben hatte.

    Pane {
        Layout.alignment: Qt.AlignTop

        ListView {
            width: contentItem.childrenRect.width
            height: contentItem.childrenRect.height

            model: container.settings

            delegate: Column {
                Text {
                    text: name
                }
                
                ListView {
                    width: contentItem.childrenRect.width
                    height: contentItem.childrenRect.height
                    
                    model: paramNames
                    
                    delegate: Text {
                        text: modelData.displayName
                    }
                }
            }
        }
    }
    0
  • L

    Ja, siehe https://doc.qt.io/qt-5/qtquick-modelviewsdata-cppmodels.html#qobjectlist-based-model.

    Es hält dich grundsätzlich aber keiner davon ab ein Model in einem Model zu verwenden (passend zu deiner View in einer View). In dem Artikel oben kannst du ja auch nachlesen, was die Vorteile davon sein könnten. Da kommt es halt auf deinen Anwendungsfall an.

    0
Anmelden zum Antworten