General and Desktop

@inforathinam QGuiApplication has this signal because it is derived from QCoreApplication https://doc.qt.io/qt-5/qcoreapplication.html#aboutToQuit

@SGaist I use KDE Neon 5.17 with Qt 5.13.2. My behaviour is like this: Right button press on DungeonView shows CrossCursor Right button release on DungeonView shows ArrowCursor Left button press on DungeonView shows ClosedHandCursor Left button release on DungeonView shows OpenHandCursor Now I only can trigger the HandCursors. The CrossCursor never shows up again. I also testet it on Windows 10 which results in the same behaviour.

@RahibeMeryem said in how to generate profile data and and using it with qmake?: /data/profile Is this just an example or really the path you're using? Is this directory writeable by you? Did you make sure these parameters were really passed to the compiler? Also, according to https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html "You must use -fprofile-generate both when compiling and when linking your program"

@megido said in create a child object with initial data: I have delete that. it was a private void Why not making it public and use instead of deleting?

@ArunBm said in QLineEdit focus Event: Is it possible to subclass and use it in Ui ? Yes, it is. Subclass it, add normal QLineEdit and then promote your own subclass. https://doc.qt.io/archives/qt-4.8/designer-using-custom-widgets.html

@limy said in mixing QtOpenGL and QPaint programming: Try doing endNativePainting(); before you start doing QPainter stuff, and it'll restore the QPainter state. Actually, I think you probably want to do your OpenGL painting first and once that's done then create the QPainter and paint with it so you don't need to interleave the painter and OpenGL.

Thanks, I updated the code to: QWidget *w = ui->scrollArea->takeWidget(); delete w; ui.scrollArea->verticalScrollBar()->hide(); it works fine.

@SGaist , Thanks a lot for your time! I used QTableWidget::setWidget instead of QTableWidget::setItem to set a QComboBox in the cell, and it worked fine: QComboBox* _list = new QComboBox(); _list->addItem("A"); _list->addItem("B"); _list->addItem("C"); ui->tblPks->setCellWidget(_row, 4, (QWidget*)_list); [image: bf277cc8-47f7-4ce7-a4f8-276276bda652.png]

What "GUI stuff" is going to interfere? Either the app is designed to operate at 60 fps or it is not. What else is the gui going to have besides the output window? If stuff is event driven with heavy processing of data sent to threads then nothing will cause it hang in slow ops. Are you generating content in the background?

@sonichy said in Qt3D: how to do boolean operations ?: QBlendEquation Looks like a pixel oriented operations, not CSG (constructive solid geometry). https://en.wikipedia.org/wiki/Constructive_solid_geometry

@Alexandre-Camelo said in When trying to make some queries and deletes in the database, the program closes and does not inform the reason of the crash: In a little while I'll be back to "bother" you again. Its all about the "bother", no trouble...

@hobbyProgrammer Do you actually have event loop running when you emit the signal?

@Omar-Medhat Show your current void MainWindow::on_openImage_clicked() implementation. The previous one was wrong as @SGaist pointed out...

Here is the solution if anyone needs it : //----------------------------------------------------------------------------- class myActiveDisabledStyle : public QProxyStyle { public: int styleHint(StyleHint hint, const QStyleOption* option = 0, const QWidget* widget = 0, QStyleHintReturn* returnData = 0) const override { return hint == QStyle::SH_Menu_AllowActiveAndDisabled ? 1 : QProxyStyle::styleHint( hint, option, widget, returnData); } }; // Make sure disabled actions are still considered active menu.setStyle(new myActiveDisabledStyle);

thanks @LeLev it Worked

@Kerndog73 said in How to open an asynchronous application modal file dialog: The dialog doesn't appear Are you sure? open() does nothing but setting the modality of the window and then calls show() so it's strange that it doesn't work I was under the impression that synchronous dialogs were bad and that I should use asynchronous dialogs instead. Kinda... the mentioned "bug" is illustrated in this article. Strictly speaking it's better to use async even for modal dialogs but the downsides are performance and some very fringe case crash so I wouldn't be too worried about using exec() if it achieves what you want