Console: Port to Qt

[nikhil-sethi]

Hey everyone! In light of my conversation with @khancyr at Discord about MAVproxy improvements for GSOC 2023, I've started with a very basic port to the QT framework for the console. A lot of It is based on the previous console to avoid significant changes.

Features

• Uses QT's signals and slots instead of callback functions
• module loading and unloading (module name: qt_console)
• mavlink information messages + Show map action working

Caveats

• There are a lot of modules that depend on wx for updating information using set_status whose signature might need to be updated as the row argument might not be required.
• Need to cleanup and separate classes into multiple files

I know that there shouldn't be more than one commit and merge commits in a PR. Please let me know if I should squash and rebase. I was also wondering if some re-organization of items on the console is needed which is a bit cluttered right now. We could use tabs to distribute info better. Any ideas are welcome.

[peterbarker]

Nice POC.

Could you outline some of the advantages you see here QT-vs-WX, please? This might just be a copy/paste summary from Discord.

Need a requirements.txt file inside your new directory - we don't want to make PySide6 a hard dependency yet, but having a requirements.txt in the subdirectory is a pattern we've used elsewhere.

Need this patch to ease testing:

--- a/setup.py
+++ b/setup.py
@@ -82,6 +82,7 @@ on how to use MAVProxy.''',
                 'MAVProxy.modules.mavproxy_paramedit',
                 'MAVProxy.modules.mavproxy_smartcamera',
                 'MAVProxy.modules.mavproxy_cesium',
+                'MAVProxy.modules.mavproxy_qt_console',
                 'MAVProxy.modules.mavproxy_joystick',
                 'MAVProxy.modules.mavproxy_magical',
                 'MAVProxy.modules.mavproxy_optitrack',

Whatever we do here - we should ensure the existing wx-based console continues to function. I don't think a magic "switch-over" to this new console is appropriate - MAVProxy's module system should allow both to co-exist for now.

[nikhil-sethi]

Hey @peterbarker Thanks for reviewing! With regards to qt vs wx, there are some differences that are nice but at the end of the day, it depends if they matter or not:

1. Signal and slot mechanism allows more flexibility in the widget and reduces code as compared to callbacks
2. I made the widget in this PR very fast on Qt-designer which can autogenerate UI code as a .py file (pyside-uic). One major advantage this has is that the UI code is well-separated and can be updated via the designer easily.
3. Qt definitely has much cleaner, clearer documentation and forums.

In the meantime, I'll also ask @khancyr and others on the discord about what they have in mind regarding Qt. I agree there shouldn't be a switch-over and I was thinking of minimally invasive ways to manage both. Can you recommend something that you might have used in the past? I'll add the commits for the requirements etc. and push. Cheers!

[peterbarker]

On Tue, 14 Mar 2023, Nikhil Sethi wrote:

I agree there shouldn't be a switch-over and I was thinking of minimally invasive ways to manage both. Can you recommend something that you might have used in the past?

Not off the top of my head. try/except blocks may be appropriate. Depends on what needs changing where. Perhaps put an example together?

Peter