Qt for Python

problem solved. thank you AI. OK, digging into the vibe debugging, this seemed pretty good. I was going to summarize it, but the AI generated description seems pretty legit, so here is what it did: Getting pyuscope's GUI running on the labsmore scope host (jaguar) Host: videoteam@ps1.fpgas.online:4031 (hostname jaguar, Debian 13, Python 3.13) pyuscope: ~/pyuscope, run as ./app/argus.py inside venv ~/venv/labsmore Scope: lip-vm1 — a Hayear HY-800B v4l2 camera (on /dev/video4) + GRBL motion Date: 2026-06-15 Carl's GUI wouldn't start. There turned out to be three separate problems, one stacked behind the other. All three are now fixed and the GUI runs. Problem 1 — Qt "xcb" plugin crash (the one Carl reported) Symptom qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in ".../cv2/qt/plugins" even though it was found. Cause (plain English) pyuscope draws its window with Qt (PyQt5). The venv also had the deluxe opencv-python, which secretly ships its own private copy of Qt. The moment pyuscope does import cv2, opencv quietly repoints an environment variable (QT_QPA_PLATFORM_PLUGIN_PATH) at its own Qt plugins. Now two different copies of Qt fight inside one process: Qt finds an xcb plugin file (so it isn't "missing") but it's the wrong, mismatched one — "found" but "could not load". Proven: QT_QPA_PLATFORM_PLUGIN_PATH is empty before import cv2 and becomes .../cv2/qt/plugins immediately after. Fix — use the headless opencv build (same API, no bundled Qt). pyuscope uses no opencv GUI functions, so nothing is lost: ~/venv/labsmore/bin/pip uninstall -y opencv-python ~/venv/labsmore/bin/pip install opencv-python-headless==4.13.0.92 Problem 2 — GStreamer "could not link" crash (GST_IS_CAPS null) Symptom (after Problem 1 was fixed) gst_caps_intersect_full: assertion 'GST_IS_CAPS (caps1)' failed ... assert self.raw_element.link(element) AssertionError (gstwidget.py:530) Cause This host has a newer PyGObject (3.56) in which the old shortcut of passing a string straight into the Gst.Caps() constructor was removed — it now raises SystemError / silently ignores the string, producing an empty/invalid caps. pyuscope built its video pipeline's capsfilter with Gst.Caps("video/x-raw,..."), so every microscope config got a null caps and the pipeline wouldn't link. Fix — use the supported API, Gst.Caps.from_string(...), at the 3 call sites (uscope/gui/gstwidget.py ×2, uscope/imager/gst.py ×1). Applied in-place; see git diff in ~/pyuscope. (Worth upstreaming to Labsmore.) Problem 3 — the real root cause: the venv couldn't see GStreamer's Python support Symptom (after Problem 2 was fixed) gst_base_sink_init: assertion 'pad_template != NULL' failed ... assert queue.link(dst) AssertionError (gstwidget.py:634) Cause pyuscope's frame-grabber (CaptureSink in uscope/gst_util.py) is a GStreamer element written in Python. The machinery that turns its __gsttemplates__ / __gstmetadata__ declarations into a real element (with a "sink" pad) lives in the gst-python overrides — Debian's python3-gst-1.0 package, not in pip's PyGObject. The venv was created with python3 -m venv (so include-system-site-packages = false) and had a pip-installed PyGObject. That pip PyGObject has no gst-python overrides, so the sink never got a pad and the pipeline couldn't link. This same missing-overrides problem is also what broke Gst.Caps("string") in Problem 2 — one root cause, two symptoms. Proven: with the venv's own python but the system overrides on PYTHONPATH, the sink registers correctly; without them, it doesn't. Fix — let the venv use the apt-installed python3-gi + python3-gst-1.0 (matched to GStreamer 1.26.2): # 1) allow the venv to fall back to system packages # edit ~/venv/labsmore/pyvenv.cfg: include-system-site-packages = true # 2) remove the override-less pip PyGObject so the system one is used ~/venv/labsmore/bin/pip uninstall -y PyGObject (The venv's own pip packages — PyQt5, numpy, opencv-headless — still take precedence; only gi/Gst now come from the system, which is how GStreamer Python apps are meant to run on Debian.) Result — the GUI runs --microscope mock (test pattern): full GUI comes up with live video — see argus_mock_screenshot.png. --microscope lip-vm1 (the real scope): launches cleanly with zero console errors, connects to the HY-800B camera (/dev/video4) and the GRBL motion controller, and reaches pyuscope's normal "System is not homed" dialog. A direct GStreamer grab from /dev/video4 produces valid frames (dark only because the scope light was off / no sample) — scope_camera_frame.jpg. How Carl launches it ssh -p 4031 videoteam@ps1.fpgas.online tmux a # tmux already has DISPLAY=:0 cd ~/pyuscope . ~/venv/labsmore/bin/activate ./app/argus.py --microscope lip-vm1 Then click OK on the "System is not homed" dialog once the stage is clear (this homes the CNC — it physically moves the stage), or Cancel to use the GUI without homing. Durability of the fixes opencv: nothing depends on opencv-python; setup.py has install_requires=[] and setup_ubuntu_20.04.sh only installs apt python3-opencv (--user), so the headless swap won't be undone in the venv. venv config: a backup of the original was saved as ~/venv/labsmore/pyvenv.cfg.bak-claude. source patch: the Gst.Caps.from_string change lives in the ~/pyuscope git checkout (visible in git diff) — review and upstream when convenient.

If those flags are honored or not depends on the window manager: " Some of these flags depend on whether the underlying window manager supports them."

It's a question of object lifetime or rather garbage collection. I have got hit by this one some years ago.

Eventually found this. Since the start and end edge code are very similar, I develop the start-side code, and get all the pointers connected up properly first edge - port - node can get a little tricksy! And then I do the end-side, copying and pasting, and change all (<-- hint) the start variables to the matching end variables. Except I missed one. Now found. All good.

@rida_zouga Sorry, yes, I forgot you said Python. I just search/post links from C++ reference pages. https://doc.qt.io/qt-6/qtwebengine-changes-qt6.html#qwebenginepage QWebEnginePage Has been moved to Core, and API that worked on QWebEngineView or QPrinter has been moved, and can now be accessed only from QWebEngineView. See Changed API.

@JonB Thanks for the link! There's border-radius, which makes the plain "StyledPanel" style possible but the website only mentions a shadow for "PaletteRole". Does this mean that you can't achieve the "raised" or "sunken" styles purely using QSS?

Hi, From old memories, you need to create the initial context first and then share it with the others and don't forget the creat calls. This Reddit thread might be what you are looking for.

@JohnL53 hi and welcome to devnet, Which variant of Debian are you running ? Did you consider using the online installer to get Qt ?

sudo apt install pyqt6-dev-tools solved it for me on Ubuntu.

The bindings for QtOpcUa, QtMqtt and QtCoap are provided for commercial license owners as part of the commercial offering. So, the contribution can unfortunately not be accepted.

seems like an issue with Nuitka. I created a bug here - https://qt-project.atlassian.net/browse/PYSIDE-3312 in Qt for Python, but this actually would need a bug to be filed in Nuitka which i can do soon.

See PYSIDE-3286 for reference.

Hi and welcome to devnet, macOS has certain rules (as other OS do as well) to have a consistent user experience and Qt helps to put things into the right place automatically. For example, the settings are under Preferences in the application's name menu. User don't have to hunt down for these kind of things. On macOS the default QMainWindow menu bar is indeed at the top of the screen which is normal and expected. Taking a look at your code and the picture you posted, I would suggest to redesign things a bit. For example, having the dark/light theme switch under Help is rather unexpected.

Hi, Did you check the Eratosthenes example ? It used the QtAsyncio.run method to start the event loop and asyncio integration. When reading the example, check that you have the asyncio implementation shown as there are two different implementations shown. Hope it helps

This eventually turned out to be an unneeded call in the parent.paint, which got very confused when the item had been deleted. Keeping everything clean and as simple as possible helps.

Hi and welcome to devnet, You should open a feature request on the bug report system. That will be the right place to discuss this kind o things. This forum is more user oriented.

Now I'm working on drawing a vertices cloud for a model imported from polygon, and I was puzzled about this issue as well. I've tried changing point size in .vert file, but no effect actually. Anyway, shader files in Qt are seriously hard to compile successfully.

@pasmon90 said in Drawing LaTeX image in pyside6 using TextObject: I need python equal or greater than .12 for gemini api feature So i cannot use pyqt6 as it does not get install. I know nothing about your situation. But if you are saying that PyQt6 would work, or is at least worth trying to compare against PySide behaviour, have you tried running PyQt6 with whatever 3.12/3.13 version of Python, regardless of whether PyQt6 is supplied with an older version of Python?