Qt Contributors Summit 2019 Program/Qt for Python and beyond

Following the notes from the Qt for Python session

- Continuation of the plenary session
- Right now status is same as PyQt
- What can we do to make a difference and improve on QtfP
- Tooling
   - Around pyside and…
   - Make it easier to mix C++ and python
       - Currently a lot of black magic
       - Pyside2config etc…
- Using it from the outside it is too complicated
    - Xml descriptions unclear, even with documentation
    - Proposal: Create generators for type system
    - Going through widgets as an example
    - The code is the documentation right now
- What about editing the type-system, not only one-time generation?
    - Does it need to be a graphical solution?
    - Whatever it is, auto-completion is important/beneficial
    - Whatever happens, keeping C++ API and xml description in sync is troublesome and should be addressed
- Embed the export information into the cpp?
- Doesn't need to be xml, could be changed
- Adding annotations for all Qt classes is not what we want
    - Developers will not learn/use it, there needs to be automatism
- Proposal: Be not as verbose in the xml description
    - Use sane defaults and only annotate corrections
- What is the amount of changes needed
    - Ownership is a good example, needs to be read from the documentation and manually adapted in the xml
- We want to encourage users to start using Python extensions
- What about using the metaobject system for auto-exposing to Python?
    - Currently not the case
    - But what about adding items which can be introspected?
    - Basically re-use Q_PROPERTY, Q_INVOKABLE,…
- Tooling around python development?
    - Comparison to Rust: Cargo
    - Creates projects, manages compilation, deployment etc
    - Cookiecutter in python, which creates base templates
    - Idea: Add tools to create project templates
        - Potentially extract what Qt Creator does in the template
    - Have it create a folder structure including src/tests/….
    - What about creating a template for cookiecutter instead of writing a new tool?
    -  Cookiecutter maintainer is in Berlin as well ,potentially meet
- Modules
    - Would there be any feedback on modules to add?
    - What about new pure python modules within the Qt context?
    - Example: Interaction with other python types, getting "python data" into QAbstractItemModel
    - Example: dataframes
    - Generally adaptors for existing python solutions
        - Does it have marketing reception impact? Qt moving "away" from C++?
    - Could be a separate solution, like Qt Lottie. Not part of the core product, but existent
    - Does this need to be associated with PySide?
        - If new modules are created which uses Qt/QtfP, why does it have to be in Pyside itself
        - And not standalone
    - Talking about the other way around
        - Qt Charts has its limitations
        - Use Qt / C++ for the heavy work and  Figure/Canvas from matplot to visualize
- Improvements to python itself
    - C++ components in Qt exposed to Python?
         - Generally a C++ module exposing a "pythonish" API using Qt to do the work
         - Integrate into PySide then
    - Why not improve Cpython?
         - It's open source after all
    - Getting sidetracked
         - Project based approach, if a project needs improvement let the project identify where to fix it
- Currently any python export requires manual shiboken compilation
    - We should improve here and make it easier
    - Idea: Some maintenance tool component which gets you latest shiboken and shiboken generator, etc…
        - Qt ships clang already, why not add the rest to the standard package?
    - Running out of time
- Deploying Python applications is a mess
- Python transpilers
    - Use-case: What about my python application which I need on a phone
    - Proposal: Wait for what others do and just use that
    - Beeware: Python VM in JS