[Development] QtCS2019 Notes: Qt for Python and beyond

[Maurice Kalinowski]

Hi,

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