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

Share Qml tools between creator designer, and Qt



    • Type: Epic
    • Status: Withdrawn
    • Priority: Not Evaluated
    • Resolution: Out of scope
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: QML: Tooling
    • Labels:
    • Epic Name:
      Shared Qml Tooling libs


      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.


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



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



                Gerrit Reviews

                There are no open Gerrit changes