Porting PyQt6 to Mojo: A Call for Discussion

[pourjour]

Introducing the Future: Porting Qt to Mojo - A Call to Action

Hello Mojo Community,

We're on the brink of something revolutionary in the software development world, and it's called Mojo. Imagine a language that combines Python's simplicity with C's execution speed. That's what Mojo promises, and preliminary benchmarks suggest we're achieving that goal.

Why Qt?
Qt is a free and open-source widget toolkit for creating graphical user interfaces. The Qt library is widely used, known for its performance, and has bindings in several languages, including Python through PyQt. But what if we could make it even better by leveraging Mojo's efficiency?

The Vision: PyQt in Mojo
By porting Qt to Mojo, we could create ultra-fast, efficient, and responsive UIs. This will be particularly useful for resource-intensive applications where every millisecond counts. Imagine medical applications that need to process EEG data in real-time or high-frequency trading systems where the slightest delay can cost millions.

The Road Ahead
Benchmarking: Prove Mojo's speed advantages with real-world examples.
Prototype: Develop a prototype of Mojo-Qt to showcase its capabilities.
Community Involvement: Establish a developer community committed to bringing this vision to life.
Call to Action
We're looking for:

C/C++ experts familiar with the inner workings of Qt.
Software engineers experienced in compiler design.
Developers interested in creating the next big thing in UI/UX.
If you're excited about the idea and want to contribute, in making this vision a reality.

Let's build the future, today.

[david-ragazzi]

I think it's not necessary convert the whole Qt c++ code to Mojo in order to we have quickly available a MojoQt version. It's just create a kind of (mojo) bindings project using pythonic name convention and inside them call the c++ function which is in the linked QT library to make the magic.

In other words, it's "just" convert the PyQt code to mojo code, as PyQt already is a python binding to Qt c++ library.

[GuyResh]

I know very little about Mojo at this point but it has piqued my interest as I'm looking to attempt to speed up a trading application I wrote (Fu510nTrader) using vanilla Python 3.x/PyQt6 and have hit some performance bottlenecks. This has sent me down the Rust path which sadly doesn't have very good Qt support so I'm stuck trying port the GUI to GTK4 which has it's own set of challenges combined with Rust's learning curve :(.

That being said:

• I want FT to be OS-agnostic (vs. Windows-only, which most trading platforms are)
• I want FT to be LLVM-based for performance (and REALLY don't want to try to write something this complicated in C++)
• Ideally Qt-based vs. GTK4

Looking at the PyQt6 package, I see a lot of references to SIP and MetaSIP so that definitely sounds like the best approach here as well.

[rectalogic]

Instead of PyQt6 I would suggest PySide6 since it's the official way to support Qt6 in Python.

It almost works today with mojo - e.g. see https://github.com/rectalogic/mojo-qt/blob/main/qt.mojo

However on macos (at least) the window is not displayed when using mojo. Possibly due to issues transforming the console app to GUI?
( see qt_mac_transformProccessToForegroundApplication)

Even a simple empty window fails to display https://github.com/rectalogic/mojo-qt/blob/main/window.mojo

$ mojo window.mojo
size PySide6.QtCore.QSize(100, 100) active False

[pourjour]

@rectalogic thanks for taking the initiative. so you mean that Qml is working, but you found difficulties with QtWidgets?
Did you test all the qt modules?
Any remarks or issues you can share with us?

[rectalogic]

I tested QGui (with and without Qml). A QWindow fails to display - but everything looks correct, it's just invisible.

I just tested QtWidgets too and they also do not display the window.

mojo: https://github.com/rectalogic/mojo-qt/blob/main/widget.mojo
python: https://github.com/rectalogic/mojo-qt/blob/main/widget.py

When I run any of these mojo scripts, I can see in the macOS dock a console icon for mojo:

and a corresponding application menu:

So actually I think that means the mojo process is being transformed to a foreground application. Also when I filter Acivity Monitor to show Windowed processes, it includes mojo. So the cause for not displaying any windows must be something else.

Here's an Activity Monitor sample of mojo, it looks like it's just in the Qt event loop as expected:

Sample of mojo.txt

[rectalogic]

OK, I figured it out. mojo is aggressive in destroying objects, so it destroys the QWindow before the main event loop even gets a chance to display it. Assigning window to the discard pattern at the end keeps it alive and the window is displayed. See rectalogic/mojo-qt@7e47a7a

See discussion here: https://docs.modular.com/mojo/manual/lifecycle/death#explicit-lifetimes

[felixf4xu]

There seem to be 3 different understandings here:

1. pure mojo, qt's c++ ported to mojo. This seems to be the OP's original idea
2. mojo call's python and then pyside6. This seems to be @rectalogic 's demo, because I see code like var QtGui = Python.import_module("PySide6.QtGui")
3. PySide6 is ported to mojo, then only mojo + qt c++ code left, no python code any more.

let me summarize:

1. pure mojo, (no c++, no python)
2. mojo + python + cpp
3. mojo + cpp

Personally I would suggest to go with 3).

[IgorDeepakM]

I see the third alternative (Mojo bindings + C++) as the only realistic solution. Alternative 2 would maybe work but it is really going over the bridge to get water. Also without Python you only need Mojo binaries + Qt DLLs in order to distribute it.

In this case it is neither PySide nor PyQt as the Mojo bindings go to the Qt library directly. However, PySide or PyQt can be used in order to get ideas how to port the bindings and have it as a template so that people familiar with PySide or PyQt will feel at home also with the Mojo bindings.

[david-ragazzi]

I also think the 3rd alternative is good. You don't need reinvent the wheel and you can quickly follow any update in QT C++ base code just creating the pythonic calls/structures/etc to the new changes.

In the pure mojo alternative, in every update in c++ base code, you would have rewrite the c++ change in mojo.