We'll forget hello yeah so last talk super difficult
slot but also i guess that everyone wants to go and relax a
little bit after a full day of talks here but
i promise you this talk is not a technical talk like so much technical there
will be some code there it's mainly ideas and highlights of what what we are
doing with the most stable and feature complete set of bindings for the Qt framework
and i am not being biased to saying that because that's a reality so first First,
if you don't know me, my name is Christian.
I have been working in the Qt company for even more than six years now.
And to show some connection to the whole community, of course,
I wanted to put some, not going into full memory lane, but highlight what is
my connection, at least with KDE.
So the main motivation that I had to be here finally in person,
because in the last events I was only online, is that long time ago,
I was part of this community I hope that you don't know the logo because sadly
that community doesn't exist anymore,
but there was even an official blog post about it,
But Elio Castro, I think that is also is was active on the chat there.
He was visiting there the community and Back then we used to had a Chilean KDE community.
So this was 2010 I made a mistake of
of subtracting the years and knowing that is a long time ago
so yeah i mean back then i
was one of the only one pushing for for cute there around
and you might think oh well it's another community there in that country that
the the answer is no because in south america besides
brazil genome was the king everyone
was doing genome like everyone was doing gtk and there
were only a few weird people like this in these photos like we were using cute
i said oh but that thing is is a european stuff whatever i was like yeah it's
so nice so we were We were there doing some stuff and I started to check this
really old set of pictures and I noticed another picture that if you were here
for the initial talk this morning, the.
Speaker there, Joana, I think was her name, that was bragging about using RLinux.
I was also using RLinux there and I also started in our community and if you
are a RLinux user, you remember that around that time using it was a lot of fun.
But this is not the content of the talk.
So first disclaimer again, like this morning's talk about Rust,
the idea of this talk is not to say, hey, Python is better, use Python.
No, it's like, hey, Python is also there. We can use it, we can get ideas,
and we can improve the whole ecosystem.
So I don't want to convince you.
So, first of all, the language findings in the Qt ecosystem is something that
is nothing new. I mean, I will not bore you here, like, explaining you how to do it.
It's there. Nothing new. But I really believe that the bindings that we have
are there are also Qt experience.
And because of that reason, some people using other languages can think, oh, Qt is really bad.
I will not use it or I will not even start using KDE because of the experience
that they had on those bindings.
So I think that as a Qt project, we need to be responsible for it.
For it and that's why I believe that why we need to push
so much for having a good experience with Python
bindings in general so just to highlight a few that I was just checking maybe
you know that wiki page maybe not but only a few we have two bindings for Python
we have the CSXQ that we talked this morning about it there are other Rust bindings
around we have for Java that is to my to my surprise,
Java bindings are super up-to-date and still actively maintained.
Julia, ,, you name it. There is even like 26 others there.
And it's super relevant. But the problem that I have is that most of these bindings
usually try to boot a one-on-one kind of equivalent.
So you have these classes in
the Qt ecosystem exposing those things in the neural language and to it.
But at some point, when we are reaching feature completeness with the Qt framework,
we thought, what about we can improve the experience of the Python users in
the Qt ecosystem with our set of bindings?
So, and also the idea was to at least say, okay, it's not like you can use Qt
with Python, but you have other things that you can use around.
So in the case of Python, I sadly need to go back to all these surveys around,
like this morning we're referring, and also don't like them much.
But the only thing that I want to highlight here is that even though most of
us like we're born and raised C++ developers, we cannot neglect Python.
By the way, I think that there we don't even have Rust.
And I think this was shown, I think a different one was shown this morning was
Tag Overflow survey that even though you can see like Rust is growing and everyone
wants it, But the reality is that out there,
most of the developers are using technologies like Python, JavaScript, and all the others.
So it's super relevant still about the thing.
So, of course, most of you, your social hands, will never use Python in this room.
Everyone's used perfect. So we cannot neglect this kind of things.
I mean, this is only a little I don't want you to read that Just want to see
the magnitude For doing a kind of like super simple.
Hello world and silver plus and cute and I'm not even adding the CMakeList TXT
there and that will be the equivalent with Python.
So even that's Selling point for new users like oh, yeah You can do the same
with this other language and achieve whatever you want to achieve there for
your first application Which maybe will not be a super commercial ready already an application,
but something to get started into the Qt ecosystem is very appealing.
So even though there are some things that I don't like from the current state
of the project regarding syntax, I believe that is something that we need to
push more so we can attract more people to Qt.
And naturally, we will have more people into the KDE community.
So if you're not into much the history of Python, I'd say personally that Python
has three main points where it started to shine.
The first one being the whole web development things, when you had things like
Flask, Django, and lately FastAPI, which is a really, really popular Python module.
And then we had the second kind of like another peak of the development,
which you all know, I am almost certain, which is data science lately.
And last but not least, I also believe that this is also a really cool area
because there are projects like MicroPython and CircuitPython that started to
brought the whole microcontrollers to the people that didn't know a lot of experience of,
I don't know, memory allocations or limits on the RAM or whatever.
So I believe that these three pillars of the Python community is something that
is what is still making it shine.
Nowadays, we know it's a reality and you know.
Someone wants to start learning how to code, you most probably will say,
yeah, maybe you can do some Python first and then, you know,
go into the harder languages.
So first, another thing that is to highlight that I guess that we cannot defeat
the installing systems of Python.
So pip install, whatever, and then you have it. It's way simpler that at least
all the other compiled languages that we have there.
We even managed at some point to expose, since I work in the computer company,
that kind of functionality to having private wheels, which is something that
also is not very explored in companies because companies sometimes offer commercial Python packages.
And we did this thing, again, it's written in C++, and it was also a really good experience.
At least the feedback we got from some commercial customers is really good.
I was telling before about the whole data science popularity and specifically
on the machine learning popularity, you see those two are the more essential or main modules.
And you can see already in the language, those projects has how important C++ is.
So the whole message here is that I really believe that one of the pilars of
the Python ecosystem at the moment to be in like such a good language is because C++.
Because C++ is exposing all these, like, you know,
the hardcore performance critical processes into a user-facing API that is super
simple and people without any knowledge of programming can add a few lines,
train a model, and start doing things.
That's why I believe that with this combination of C++ and Python,
we got the perfect recipe.
So as I said before, we have a Python user-facing experience with a C++ core,
right? That should be right.
I will talk about that later. But let's go about Python and Qt.
So first of all, I want to clarify something that I get wrong all the time,
but many people they interact with.
We have the Qt ecosystem, two set of bindings.
And I want to explain why we have two set of bindings. So I know that now you're
expecting like all the drama behind it.
It's not, at least I was not there, but when this happens, but in a nutshell,
you know, PyQt has been around for a long time.
At some point it got invited into the Qt project with
the condition of course of changing the license and then
the people behind PyQt say like thank you very much but we have our own thing
where our business around it not convening for us to say okay then we need to
do another one and that's why PySite was born so is maybe it was more dramatic
I don't know I don't even want to go into the meta list at all but the main
difference are like this as I I mentioned before, licenses,
the company that is behind the development,
supports are roughly the same, and the and more part there is that I want to make emphasis why.
And as I said, I know I might be biased, but this has been the goal in the latest
years that we want to offer more than just the Qt API available in Python.
So, I don't want to go into the details, but this is more or less the story of PySight.
I joined around 2018, so you can see there, I missed all the fun parts there
before, but so far so good.
We are just keeping the same release schedule as Qt, and everything is going great.
As I told you before, for PySight, as I said, we would not like to just expose
the Qt API because then the question that you all might have is like,
so what's the difference? So I just changed the import and that's it.
And this was the state of the project at some point. And we were like really
thinking, oh my God, we really need to do a difference now.
So what I would try to do now is to highlight which are all the features that
we have at on top of just having Qt bindings for making the Python experience
for new Qt developers very well. So as I said, searching for features.
So the first one we thought it was a really interesting one.
It was a main use case from one of our customers.
It's some code there you're unable to read so far, but don't worry,
give it a couple of seconds.
Maybe you're familiarized with the solution from Autodesk. They started with
this requirement that was having access to a Qt C++ application from a Python interpreter.
In a nutshell, if you want to implement plugins or add-ons to the application.
We thought it was the main thing that people were planning to use it.
People still wanted more.
So at some point we thought, what is the most popular Python model out there
that we can make, we make it interact flawlessly with Qt.
And it was NumPy, a numerical Python module, historical module that also was
super important in the evolution and the adoption from the scientific community.
And then we thought, maybe we can have some mechanisms inside to accept the
data structures that they expose, the NumPy arrays, within that thing.
And even at some point, we got a project called PyQtGraph, and I know it said
PyQt, but it's It's compiled with PySide as well.
They asked, you know what? We really would like for QPainter to have a specific
API that accepts these two and AMP arrays, whatever, whatever.
And since everyone was thinking of, ah, yeah, the PySide bindings are,
yeah, there, we thought, yeah, you know what? Let's break API.
You have this need. It's an open source project that will benefit from it.
We gave those new APIs. So this is even something that we have been open for
all the other projects. Like, you need something that's not there?
Let's do it. We don't care. We just want to get more people happy.
And the third point was Qt Creator support, at least a minimal one.
So we thought that exposing a few templates there that you can start was enough.
We started to work a little bit more on these things. And after you finish and
selected your module you wanted to use, you can even have the option now to
create your own virtual environment, which is the natural thing for Python developers to do.
And then you get this nice, or maybe, I don't know, not so nice,
but a pop-up about like, hey, PySense is not installed.
Maybe you can install it like that. So trying to ease the interaction there.
But then people, I went to conference around it. They said, yeah, that's not enough.
I said, well, okay, let's look for more maybe Python features to this.
So the first one, and this is something that you might believe maybe,
oh, that's silly, but I will tell you later why it was not.
Typical, nonsensical, like simple code, just to highlight that this is what
we will be using in Python.
And then we implemented a feature that was changing the whole Qt API at runtime to SnakeCase.
And you will say, this was, alongside the next one that I will tell you,
the number one comment that every single, it was really like a joke,
like an eimer that follows you, everyone.
But you know what? You have camel case and that feels really C++.
It's not really Python. So we did that, but it was not enough because then people
thought, you also need to have true properties because in C++,
we're used to setters and getters, well, and Qt, right?
But in Python, that's not a thing. So we implemented another option called true property.
So then you don't need all these setters and getters and you can just directly
go there and modify the property value.
And as I told you, this was really what everyone was asking for.
Even this thing, as well, caused many good and positive comments out of the community.
Then we had QML element. So as you know, you're secure to C++ developers,
you can expose C++ code to use in the QML, made this little macro called QML
element that then at build time because of some CMAX magic, you get that exposed.
We don't have build time in Python. So we needed to do something like how could
we solve this problem for the Python users?
So we thought what is natural for people in Python to have, you maybe want to,
I don't know, do some external decoration on things.
So literally using a decorator. So then we implemented this approach of,
it was literally just having one decorator on a specific Python class that needed
to inherit from QObject,
giving some important name and versioning, and then people would easily go to the QML there,
and just instantiate the object and using it all over the place.
With that also, we made a lot of QML users happy about it. and it was something
that literally like changed the situation.
If you were using PySide, have
you ever used QML element to expose Python things to C++? Sorry, so QML?
Nobody? Okay, good. So now you know, but now you can do it.
So yeah, this was very important. And then after that, I didn't want to put
it here in the slide, but there are many other degraders that can help you,
like if you want a singleton or whatsoever. So, we have many methods there to
do the whole type registrar thing at runtime.
So, every time, maybe yourself and the people behind all the support that we
have in CMake gets creative with doing things in build time,
we need to somehow try to figure out why do we do that.
As far as I know, and please correct me if I am wrong later,
PyQ does not have any mechanism to do this.
Tooling then we thought okay maybe we need
to do something about that people don't know that we
include in the wheels all those tools there
the ones that you see on the top maybe you cannot read it well properly are
the one that we have wrappers around the c++ code so the the c++ tool so we
can use it in python modules and the last two there sometimes they are super
simple as calling the binary that we're including but we also have things that
doesn't exist in Qt for example, generate type hints for Python.
We have even a little functionality to do a complete dump of the meta object
and even new tools that also have not getting a lot of love because we have
been really bad at communicating those things,
which is like you can have tools like PySatSig Project that is kind of having
a kit creator on the terminal because you can start new projects based from
templates and just build and run the application there without worrying about anything.
And then you also have a tool to deploy, for example.
Deployment is a big issue even nowadays for C++ and Qt developers because,
in my opinion, it's not good to have the application to deploy to Linux,
one to Windows, and one to Mac.
So we thought, why reinventing the wheel, like having yet another tool base, whatever?
So we started to look into the Python community. And there is recently a really
good deployment tool in Python, which is called Nuitka.
And it's the only one that really compiles Python code.
All the other ones are freezers. The one that like transforms some stuff and
is a fake zip, but this is really good and we said, let's do a user interface
on top of that developer team.
There is super nice, super open. So we have been collaborating quite a lot.
So why not? And the last that you see there on the right is the Android deployed,
which I will talk about later, which is also a big milestone in our own project.
So, yeah, again, even with all these things, people were still asking about,
eh, what about, okay, let's do even more features.
Android support, as I just told you. This is a case that since I joined the
company, people is asking for Android support.
My opinion, I'm not a mobile developer. It's really strange for someone to want
to do a mobile application using Python since there are options out there that can be super simple.
But again, we thought, why reinventing everything from scratch,
trying to figure out everything?
And one of the competitors that PySight has out there in the Python ecosystem is Kibbe.
Kibbe is another framework to create user interfaces in Python.
And they developed a tool that is literally to put Python modules on Android devices.
And then we saw the license is compliant. We developed one tool around it that
was compliant with everything they had. We contacted them, they say,
hey, we have a recipe now, so you can have pies right there.
I said, yes, sure, let's do it.
And we are reusing that thing again. So even though there are like two different
offers, we are trying to find our ways to interact more with other projects doing things.
So if you want to know how it works, you will be unable to read here because
it was recording on a screen size with the resolution too high.
But in a nutshell, the first step that you maybe saw there is that just calling
the Android Deploy tool that we have.
And we do provide some ARC64 wheels, so we are using those.
You can do this, the cost compilation to create those wheels for Linux or Mac.
And then when we have all these wheels, we are preparing the packaging.
Then you can open it, for example, in Android Studio, where you can see all
the information there generated.
And I think the last step now would be that we are preparing to put the package on a mobile phone.
And soon as you will see the application popping up. There it is.
Oh, is that Bossert?
So then you have like the usual permissions and everything. And thanks to one
of my colleagues, Sham, that recorded this like two days ago.
So then you have that. The first comment that I got when we announced under
support of all the work, like, yeah, what about iOS?
And I was like, OK, yeah, so I will not not even continue and take the time for it.
Another interesting experiment here, which is cute as in Kayo.
This doesn't exist in C++, of course.
And why we did it is because we had a lot of people requesting inter-availability
between the module async.io in Python and Python applications.
So async.io is one of the main, if not like the maybe well-accepted modules
to do asynchronous computing in Python.
And there are many plugins out there. If you really, if you Google for like,
I don't know, like Qt or async.io or whatever, you will find those things.
They started to stop being developed and one after the other they were forking
each other and then at the end I think there is no active project so we thought
why not having something like that.
So this was never done before because it is literally a model that doesn't exist
in C++ that people can't import like they do with any other Qt module.
So in a nutshell you can see there like a little example that is just highlighting
how do you call, I think this is the simple example that we have.
How do you need to use this new wrapper around the queue application,
for example, in order to make it work.
So at some point, we even were discussing like, oh, maybe we can make now this
a C++ thing and maybe reinvent it, but no.
So far, no interaction on that. And sadly, also the Adrian, the person that
was in charge of the thing, at some point stopped contributing with the project.
So in case you're interested with this topic, we can talk about each other.
Another thing, so Design Studio. Have you ever used Design Studio by the way
here? Is anyone using Design Studio? Okay, you are.
Super requested thing by open source user and commercial users like,
hey, but I want to have a Python project out of it.
We didn't have support. So the solution that we have in place now that we will
announce in the following days,
it's a new option in Design Studio that you have enabling the Python generator
that will create this new Python directory inside your project,
where you will have a setting things that is the file that will be constantly
changing in case you have more assets there in your project and the main POI
file, which in theory will not change at all.
So you don't have the risk of touching again and again the files and everything.
As I said, with the next Qt Design Studio release, this will be out as well.
And we were preparing a blog post about it. So you can have a look.
So it's really convenient. And at the same time, maybe you have noticed that
Design Studio also has their own Qt Quick components that they're not in Qt.
So what we also did is that now we will have a PySite design studio wheel that
includes those components as well, so in case you want to just use those.
Another thing that it was really interesting to achieve is that before the jump
from five to six, we noticed that performance-wise, PySite was really slow compared to PyQt.
And we did some investigation, and we noticed that back then we were using really
inefficient containers,
in the implementation, and we improved that, and we managed to get parity of the speedup,
but something that we are still fighting well
hopefully for not so long is that the loading of the modules
is something that is a it was a little bit more
sorry slow so this new
approach that uh when another colleague christian is working uh it's based on
a enhanced proposal in the python ecosystem that was rejected but the idea was
good to improve the improve the startup time and i don't know if some of you
were in the contributor summit but we talk about there that there.
And for the end user, it's just faster to run a Python application.
Qt script. You remember maybe Qt script, the one that enabled you to make some
nice interaction with JavaScript that was in Qt 5 that was not maintained anymore.
At some point, we had an internal hackathon, and I had the idea like,
hey, maybe we can do it with Python. And everyone was like, ha,
ha, ha, but it's not for real.
And then we did something, and it was very interesting. The reception,
at least in the company's hackathon, was, yeah, maybe we can push it later.
And another colleague from the team, Friedemann, decided to say like,
hey, maybe we can do this thing.
Recently, maybe you saw that Qt Creator supports Lua now for creating extensions,
and the end goal of this is to convince and work together with the Qt Creator
developers to enable Python to be as a language to write plugins for Qt Creator.
I don't know if you have wrote any Qt Creator currently, but it's a little bit complicated.
So, as I told you before, the idea of this would be to embed this Python interpreter
so you can use it within C++.
And it was similar to the first example that I showed you there.
This application, this widescreen that was enlarging the fonts.
And it would enable us to use these dynamical bindings for this program without
relying on having this binding generator needing to be building the modules and stuff.
So it will be really cool in my opinion and hopefully it's something we can
push soon to to have this thing around.
Something that might be interesting, at least the people that are around this
topic know already, so I'm happy about it, is that for a long time,
I remember having many conversations with people from the KDE that said, hey,
please, make it possible to build this via Flatpak.
So recently, Shyam, one of the colleagues, decided to enable this thing,
so maybe you remember this Python with Kirigami website that is in the documentation.
Presentation before it was PyQt with Kirigami and
now we gladly with this support we managed to
do the Python in general so users can have
the choice they can do Kirigami based applications with either with PyQt or
PySide so this something was recently announced there and since we are talking
about KDE something that also makes us really happy and and thanks for color
here is that there's also a work being in the whole Summer Code done by Manuel.
And Carl is helping. And apparently, as I heard, everything is going well so far.
So it is something that is still interesting to have.
And I believe that this is kind of the idea that we need to move into the future,
like stop thinking of C++ framework and more like many languages framework.
So then the question was, is that enough with all the pies and features that we have?
Well, I believe that it will never be enough. so we even started to think about new features.
And here I want to make a parenthesis, and I want to talk about Rust.
Recently, and this is my own personal opinion, some people noticed that rewriting
Python code in a compiled language was faster.
And then everyone was like, oh my god, right? And I was like, seriously?
But anyway, this is improving the Python ecosystem, so people are happy about
using it, But I really don't like when people always do this comparison about
like Python being slow with compared to Rust or C++.
Yeah, we know. I mean, it's a reality. This is what happens.
Because we don't use Python for being fast. We use Python for being convenient.
But anyway. So I like the whole argument of memory safety. Yes.
But if you see a person only highlighting faster, it's like...
And you may believe like, okay, well, that's a silly thing. So Rust started
to be super strong in the Python community.
And now there is even like companies doing tooling around it.
So people decided, for example, to start rewriting different applications.
The first two are rewrites of existing Python tooling.
And the last one is kind of like a cargo for Python kind of thing.
And they have been super successful lately.
So I believe that this is really good for the Python ecosystem.
System and I really hope that with the CX execute we can manage to get into
a point of having also this another language and being not rewriting things
like in the talk this morning was,
mentioning but having new things written in Rust that can improve the KDEK system.
There is a different approach though that something someone there
is also a different company called Exaloop decided to you
know what Python is cool but let's keep only the user or interface and
rewrite everything one of the authors this thing it's
a commercial only thing so far it's one of the the
people behind llvm so they decided
to say just using as python as a front end and then well the
language that you see and then everything else is super improved
to run in different system whatever and it's i don't know it's a nice approach
that i wanted to highlight as well so i think i still have like sometimes right
so like five okay cool so yeah that was the parentheses and with regarding Rust
because maybe you have read some news or in your timeline some respective social
media like Python and Rust are being really cool.
And I had a talk in Lithuania where a lot of people wanted to say,
oh yeah, Rust is so fast, Rust is so fast.
And I wrote one extension in Rust and one in C++, and C++ was faster.
So why people is not writing things in C++?
You tell me. I don't know. So the future of the project, the future of PySide. it.
First of all, simplifying user experience. This is Qt. I will give you a couple
of seconds to digest the code.
This is a prototype that I was playing around with because sometimes I get the
complaints from people that to write a simple application, they need to know
a lot of things about Qt. You need to know what a Qt application is.
You need to know what a Qt push button is, how to interact that
you need a QV box layout in order to put things
and some people don't like that I respect that
but maybe as a Qt project we could start envisioning
trying to have solutions on top of what we have already so this is only widget
based and I don't think that I will ever publish it but if you see it's completely
different and it's super similar to other frameworks like Flutter does there
is currently something called Flet that is Flutter for Python that is literally
this kind of like interfaces.
So I know, I don't know, maybe it was a playground thingy. It's something that
is convenient for us to expose people to our dear technology,
but in a way that is not so specific to our framework and in my work.
The other one is packaging and tooling. Even though we still have lots of tools,
I still believe that we need to make a better work communicating it,
and functionality-wise, maybe start shipping everything,
but maybe have one or two that does most of those stuff, because people get
super confused, and I all the time have bug reports like, if I put designer by a standalone,
it doesn't work with the PySite plugins, and it's like, now you need to do PySite
as a designer instead of, okay.
So yeah, maybe we might work on that as well. And new modules integrations.
I always like to see Qt for Python as an interface, trying to get the best of both worlds.
So we are still looking into other Python modules that we can have more API for.
So we can use maybe, I don't know, have a Qtable widget or a view populated
by a Pandas data frame, for example, if you're familiar with Pandas in the Python ecosystem.
Things like that might be worth exploring and might be also a good thing to have in the future.
And the other thing that I was mentioning before is about this async.io module
is that maybe we'll have other modules written in Python only that can improve
the life of Qt developers in Python.
I only have a few slides, so I will be finishing soon.
And as I told you before, but don't tell this anyone outside this room,
if you have requested a specialized API that can break the Qt API but is solving
your problem, let's talk.
And maybe we can even add it to the model without any problem. them and if
you have ideas as well contact me if you
I will be around tomorrow and the day after tomorrow even if
you have pain points I'm happy to hear so what's
next I think that we need to
embrace the idea of many language framework for the Qt ecosystem
and I like I don't know maybe because
I'm getting old but I really would like for us to be boring and
in a sense of like do not try to reinvent a new
super parser that does something if there is something out
there let's use it or they did something that worked let's do
that with every single language because sometimes you don't need
to invent new things all the time you can adopt and nurture
whatever you have with those things so that's the thing that i really envisioned
that having a cute ecosystem imagining like everything acting together and imagine
all the possibilities that we have like putting more languages more ideas more
mechanism that maybe solves problems that you as a cute user as a kda user have.
And then with all this thing, you know what we can, oh, sorry,
we can have a better Qt ecosystem overall.
And with that, I just wanted to see, like, again, if we have a better and polyglot
Qt framework, that means a better KDE for sure.
So yeah, thank you very much. And if you have maybe any questions, you can let me know.