Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-88798

Share Qml tools between creator designer, and Qt

    XMLWordPrintable

Details

    • Epic
    • Resolution: Out of scope
    • Not Evaluated
    • None
    • None
    • QML: Tooling
    • None
    • Shared Qml Tooling libs

    Description

      Qml tooling currently uses partly an old code model, partly command line tools, and an internal library in QtDeclarative (QmlDevTools).
      Command line tools are nice because they are loosely coupled to the libraries, and can be used mostly independently from them.
      Here the language server will bring more use case toward the command line approach.
      Still libraries are useful, and keeping them up to date is tricky.
      The current code model did split and get out of date because
      (1) symbols need to be different from those in qtdeclarative to be able to link everywhere without problems (static builds, 2 level namespaces can help, but it stays tricky).
      (2) the external version cannot be used in Qt

      Now with a Cmake build it becomes easier to have a library in Qt, and keep it compilable against earlier Qt versions.

      This is still some work, it is relatively easy if this tool library builds against QtDeclarative, and tries to limit the use of internals.
      Moving things into QtDeclartive will add some extra pain, but we get two things
      1) guaranteed to work with latest version
      2) extra work is to keep previous version working, this is a better place than the opposite (old version working, extra work to use the latest) because it will stay relevant, and compatibility will be done depending on need.

      Simply always using whatever Qt ships is (especially initially, but I think also longer term not really a good option because the newest Qt is often not stable enough, but the tool improvements of the latest one are applicable even to older versions.
      The library in Qt + buildable against old Qt has the correct incentives to be sustainable.

      Aside the technical compilation/linkage a kind of stability in the API is required.
      At least for uniform access I think the Dom can give that in a way that could be made public API exposing a small subset of the inner workings.

      So the plan is to have this library replace (even progressively) the older one, and consolidate more code into the qmldom library.

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            ulherman Ulf Hermann
            fawzi Fawzi Mohamed
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes