General and Desktop

@SGaist I used this link where you had also posted info. https://forum.qt.io/topic/57852/solved-menu-bar-remains-stubbornly-invisible-on-mac-os-x-yosemite The key was to set the parent of the menuBar to null. That resolved the problem.

@SGaist It's works! Thank you!

@SGaist Thank You a milion. [Platform] CocoaArguments = fontengine=freetype is the correct incantation

@Henrik-Rasmussen Thanks, that helped!

Hi, Do you mean that your application should always stay on top and not let any other get focus ?

Hi, @calmstack said in QtNetwork: incomingConnection not triggered: @jsulm Isn't it what the official documentation recommends ? No, it's one usage example. You have the same example without threads.

Hi, From your code you seem to convert every pixel value, use the reverse formula to change your YCbCr back to RGB. You should have it in the same place as the one for RGB to YCbCr.

@KroMignon said in Executing QProcess in QThread: memory leak: This is the way I would implement multiple pings in parallel: This code doesn't work. Only one iteration.

@akhi95 I found out some additional info. I think the below two installer signals and three methods might be useful. I tried : installer.uninstallationStarted() [https://doc.qt.io/qtinstallerframework/scripting-installer.html#uninstallationStarted-signal] installer.uninstallationFinished() [https://doc.qt.io/qtinstallerframework/scripting-installer.html#uninstallationFinished-signal] installer.runUninstaller() [https://doc.qt.io/qtinstallerframework/scripting-installer.html#runUninstaller-method] installer.setCompleteUninstallation(bool complete) [https://doc.qt.io/qtinstallerframework/scripting-installer.html#setCompleteUninstallation-method] installer.setUninstaller() [https://doc.qt.io/qtinstallerframework/scripting-installer.html#setUninstaller-method] I tried runUninstaller() and setCompleteUninstallation() methods in constructor of one of my component scripts but for some reason the uninstaller (MaintenanceTool) is not being called. Also, I'm not sure what does setUninstaller() do and how to use it. But I think it might be useful for my case.

Already solved, use ui->tableViewSpdLimit->itemDelegateForColumn()

@PKan Do you have to use MSVC2019? If not use older compiler - it would be way easier than patching Qt...

@Christian-Ehrlicher @JonB Thank you very much! I've managed to sort it out now.

Do I need to wait for some signal to fire before tossing a frame at the monitor? I talked about how it works some time ago here. It was about QPainter, but it's similar with OpenGL or Vulkan. As for synchronization, depending on your OS, graphics card and driver this can be controlled or set up at many different points. There's bunch of knobs and switches in the OS, driver and in your app through Qt or directly in OpenGL that you can play with. In the simplest case you just draw to the back buffer and OS takes care of a synced flip of the back buffer at your monitor's rate. With QOpenGLWindow this behavior is the default. See the documentation for setSwapInterval() and the paragraph about swapping buffers in QOpenGLWindow Detailed Description. I just have to worry about queueing frames faster than the eye can detect and let the kernel module do the busy work. Well no, that's not entirely true. For smoothest experience you should try to produce frames at the rate of your monitor. Not slower but also not faster. It's not immediately obvious but producing more frames than the display can actually display is not just wastful but, more importantly, produces jaggy result. I touched on this a bit with example here. That post is a bit dated and there are some pretty cool new techniques to get the smoothest results, but I think it gives a bit of a baseline on what to do or not do.

Hi all - and thanks a lot to all who wanted to help. I write this as a final note, because I consider this as solved. My solution looks now like this: QTranslator* pTrans = new QTranslator(); if( pTrans->load(translationFile, path)) if( QCoreApplication::installTranslator(pTrans)) { qInfo() << "Successfully installed language file " << translationFile; return; } qCritical() << "failed to load translations " << translationFile; So the QTranslator, which is "installed" into the application does never run out of scope. One might consider this a leak - but as I do not intend to offer a switch of language I guess for me this is OK. So the take away for everyone who has similar problems: let your QTranslate survive, then it will work for you! Best regards Holger PS: This will translate MessageBox buttons as well as Wizard buttons. It does not work for File dialogs which are provided from the OS.

@Christian-Ehrlicher No, I do not need to edit self-defined design-time properties. If I do want to put it onto another widget/window at design-time, I am quite happy with Promote. (Other times I create one dynamically from code.) I do understand that if I did want to expose new design-time properties to edit I would need a proper custom widget, with its code. But I just don't need that. I am designing a table, or tables, that has quite some design-time layout and content. Think of how much you can tailor on a QTableWidget at design-time. It has some fixed rows, fixed columns, headers, some of the cells are filled in at design-time. I want to drag out particular column widths. I have bolding on some items. And so on & so forth. Oh, and by the way, yes I do go back and change the content/layout over time. Please don't suggest copying & pasting onto other forms! (Your " than propagate this in designer"??) Yes, I absolutely could just write code for my class MyTableWidget, deriving from QTableWidget so I can access all those methods, and add my own for this table. And do all that design-time stuff in code. Then nobody would give me a hard time. But I want to use Designer for QTableWidget on it. Please! As I said before, settling for a top-level QWidget which has my desired QTableWidget as a child just does not give me my desired interface to the outside world of a class MyTableWidget : QTableWidget. Now I don't see what is hard to understand about this situation :)

Does it work if you do not use any Qt code in your .dll ?