QT forum

For an educational project, I want to compile Qt 6 C# (presumably, via the new Qt Bridge) to GitLab Pages-compatible WASM (presumably, via Emscripten). Is this feasible, and/or possible? If not, I am happy to file an enhancement request for Qt Jira's QTBRIDGES product. Though, I fear that it may be as difficult as what github.com/pyodide/pyodide-recipes/issues/183 describes.

Sorry; I would have edited the post but the site does not allow me. The error message I posted was from when I had my custom debugging helpers on. Them being on or not (or even present) has no impact on this failure, but they do change the error message slightly and I didn't want to confuse the issue with that oversight. Here is a version of the error with no involvement from those: &"python theDumper.fetchVariables({\"allowinferiorcalls\":1,\"autoderef\":1,\"context\":\"\",\"displaystringlimit\":300,\"dyntype\":1,\"expanded\":{\"inspect\":100,\"local\":100,\"local.boxHigh\":100,\"return\":100,\"watch\":100},\"fancy\":0,\"formats\":{},\"nativemixed\":0,\"partialvar\":\"local.boxHigh\",\"passexceptions\":0,\"qobjectnames\":1,\"qtnamespace\":\"\",\"qtversion\":331539,\"resultvarname\":\"\",\"stringcutoff\":10000,\"timestamps\":0,\"token\":718,\"typeformats\":{},\"watchers\":[{\"exp\":\"6d446972656374696f6e\",\"iname\":\"watch.0\"}]})\n" >~"bridgemessage={msg=\"b' COULD NOT ACCESS FIELD: union {...}'\"},\n" >~"bridgemessage={msg=\"b' COULD NOT ACCESS FIELD: union {...}'\"},\n" >~"bridgemessage={msg=\"b' COULD NOT ACCESS FIELD: union {...}'\"},\n" >~"result={token=\"718\",data=[{iname=\"local.boxHigh\",name=\"boxHigh\",address=\"0x555555f48b78\",size=\"12\",numchild=\"1\",sortable=\"1\",children=[],type=\"glm::vec3&\",value=\"\",},{iname=\"watch.0\",wname=\"6D446972656374696F6E\",numchild=\"0\",type=\" \",value=\" \",},],typeinfo=[],partial=\"1\",runtime=\"0.012951968994457275\",

@rida_zouga OK :) Now that you are using the color just for the background and filling first you can drop the alpha/opacity, e.g. QColor(255, 255, 0) should be pure yellow. Mine was just for illustration.

Thx for explanation what the problem was. That is what I need. Marked topic as solved

If you want the release candidate it is in the development releases area of the mirrors, e.g. https://download.qt.io/development_releases/6.12/6.12.0-rc/qt/single/

Hi, I haven't since a long time but one thing to check: which version of Xcode do you have ?

The language server doesn't show hover tooltips for types or type properties. When triggering the LspHover command, the Vim client plugin returns the warning No documentation found for current keyword . Jumping to definitions of built-in QML types also doesn't work. When triggering the LspGotoDefinition command, the LSP client plugin returns the warning symbol definition is not found . Other language server features I've checked do work. Namely: autocompletion for both built-in and custom types, autocompletion of type properties, and jumping to definitions of custom types created both in QML and in C++. Hover tooltips as a feature also work in general, but for files with code in other programming languages (e.g. C++) with other language servers (e.g. clangd ). What could be causing this behavior? How can I make the language server show hover tooltips and jump to definitions of built-in types? .qmlls.ini [General] no-cmake-calls=false buildDir="/home/user/.workspace/playground/qt/learn_qt/sample-0005/build-debug" docDir=/usr/share/doc/qt6 importPaths="/usr/lib/qt6/qml" Arch Linux Qt 6.11.2 Vim 9.2 lsp — Language Server Protocol plugin for Vim9 yegappan/lsp qmlls 6.11.2

@sierdzio There also seems to be some interaction with wrap mode of the text, also depends if one uses JS script: my text string, or not. Anyways, i ended up using ColumnLayout with a ListView that fills it and that ListView has delegate Item that has column embedded in it, which is anchors.horizontalCenter: parent.horizontalCenter . I tried to have just column as delegate, but that also wouldnt work, so i wrapped it in an item. Anyways it is not that important atm, i might return here once I have time to experiment more.

@IgKh said in QTabBar-like list of "x-clickable" buttons?: adding a tag is to type it and hit return Fair enough. I think different from what I took from the OP's description. At least I understand. (I get it now. Your "Tags Input" is those adding a bunch of tags to a topic by typing in words on little "cards", and "x" to delete one.)

@Jackie said in Agentic Chat Improvement in ACP plugin: Oh I see, sorry for posting in the wrong place. No worries ! You're not the first nor the last in that case. You came to the right place to get directions :-)

Platform: Raspberry Pi 3B, Debian Trixie, Qt 5.15, GStreamer 1.24, Wayland compositor, v4l2h264dec Why we built a custom GStreamer item instead of using Qt Multimedia's Video element Before describing the transition problem itself, I want to explain why we're not using Qt Multimedia's Video QML element, since that's the obvious first question. Qt Multimedia's GStreamer backend does use v4l2h264dec — we confirmed this with GST_DEBUG=3. That's not the issue. The issue is what happens at EOS on this specific platform. On Pi3 / kernel 6.6, when GST_EVENT_EOS reaches the V4L2 sink, it triggers a known memory leak in the Pi's V4L2 driver at end-of-playback. For a digital signage player looping content 24/7, this CMA (Contiguous Memory Allocator) leak accumulates until V4L2 buffer allocation fails: v4l2h264dec: Failed to allocate output buffers — Cannot allocate memory The workaround is to intercept and drop GST_EVENT_EOS via a pad probe on the sink pad, before it reaches the driver. End-of-video is detected via GST_MESSAGE_EOS on the bus (which is still emitted normally). Qt Multimedia's Video element doesn't expose any hook to install a pad probe at this level. This is why we built GstVideoItemV2 , a custom QQuickItem that drives the pipeline directly with the raw GStreamer C API. Our pipeline: filesrc → qtdemux → h264parse → v4l2h264dec → queue → waylandsink ↑ pad probe: drop GST_EVENT_EOS Note on Qt6: migrating to Qt6 is not on our roadmap today, but if Qt6 Multimedia's GStreame

On the one hand you are saying that you have restricted the recursion depth to 14 levels, but on the other hand you are saying you have a stack overflow. This does not make sense unless you have really huge stack frames (any arrays on the stack?). Or your actual recursion depths is much deeper than 14 levels. It is quite likely that the stack overflow is the real problem and malloc doesn't have to do anything with it. For now, I would stop looking elsewhere. Setting a larger stack size certainly seems to help. Somebody mentioned that Linux stack size is 8MB, so you could even just go with 8MB (instead of 16MB) if your software works on Linux. However, this is not a permanent fix! Over time people will run larger and larger problems. You'll eventually run out of stack space on all operating systems, not just macOS. The best solution might be to rewrite your recursive algorithm with a loop. (This is technically also not a permanent solution, but the only restriction is not enough RAM and there is nothing you can do about it in software.)