General and Desktop

@jsulm Thank you. Now it works good. No GUI blocking.

Drawing direction and radian were the problem. With these: #define whats16 16 Slice::Slice(float start, float sweep, QColor color, QGraphicsItem* parent) : QGraphicsItem(parent), m_start(start), m_sweep(sweep), m_color(color){ m_realColor = color; m_rect = QRectF(0,0,200,200); m_path = QPainterPath(QPointF(m_rect.width() / 2, m_rect.height() / 2)); m_path.arcTo(m_rect, -m_start, -m_sweep); m_path.closeSubpath(); dx = 10 * cos((m_start + m_sweep / 2) * M_PI / 180); dy = 10 * sin((m_start + m_sweep / 2) * M_PI / 180); setAcceptHoverEvents(true); } QRectF Slice::boundingRect() const { return m_rect; } QPainterPath Slice::shape() const { return m_path;} void Slice::hoverEnterEvent(QGraphicsSceneHoverEvent*){ m_color = Qt::gray; moveBy(dx, dy); } void Slice::hoverLeaveEvent(QGraphicsSceneHoverEvent*){ m_color = m_realColor; moveBy(-dx, -dy); } void Slice::paint(QPainter *painter, const QStyleOptionGraphicsItem*, QWidget*){ painter->setRenderHint(QPainter::Antialiasing); painter->setPen(Qt::white); painter->setBrush(m_color); painter->drawPie(m_rect, whats16 * -m_start, whats16 * -m_sweep); } Now, slice moves perfectly: [image: cb199f19-a0d1-4d4c-acfc-8eb4bb342d51.gif] BUT the whole pie moves for a while (5 times as I start hovering over different slices). Why does it move?

@Pl45m4 It always crashes if the API Key Request process happens

@JoeCFD , @swansorter, I finally figured out what whas happening in my case. Since my touch screen is a capacitive one, I had to create my qdialog on mousereleaseevent, instead of on mousepressevent.

@eyllanesc Thanks a lot it worked perfectly

@SGaist said in how to convert between QPixmap/QImage and Xlib Pixmap?: qt_xcb_pixmapFromXPixmap Thank you very much.

@ShahShaj said in Qt with opencv and gstreamer not working: Instead of using QtMultimedia, qmlglsink will be a better option? Worth a try indeed.

You can read the class sources.

@eyllanesc it's Qt 5.11.2

Thanks a lot!! It is finally working! Wooohoo! Thank you for your patience, I know those may be basic stuff, but I am just a beginner.

@freemanl144 If you really have long running, non-UI processing to do go ahead and use threads and don't get it wrong. Doesn't alter the fact that threads cannot address the UI. Use signals from your threads to inform the UI thread of something for it to act on. Use a signal from your main thread to secondary threads if you want to tell them to exit. If the UI needs to allow the user to interrupt, put up a dialog and send a signal to the sub-threads (preferably) or terminate them (not so preferably).

@AnneRanch "studio" here refers to the "design studio" program. It's (I think) outside the scope of our talk here. I was referring to the situation where you create widgets via c++. They will not be visible in the Creator but you can connect their signals and slots. Consider this example (submenu with zoom levels): zoomMenu = viewMenu->addMenu(tr("&Zoom level")); zoomLevels = new QActionGroup(this); for (auto x=10;x<210;x=x+10) { QAction *act = new QAction(QString::number(x)+"%",this); act->setCheckable(true); zoomLevels->addAction(act); connect(act,&QAction::triggered,this,[=](){setZoom(act->text());}); } zoomMenu->addActions(zoomLevels->actions()); Each action is connected (here via lambda). With widget (same boilerplate application, QComboBox for zoom level): zLevel = new QComboBox(this); for (auto x=0;x<zoomLevels->actions().size();++x) { zLevel->addItem(zoomLevels->actions().at(x)->text()); } zLevel->addItem(tr("Fit to window")); connect(zLevel,&QComboBox::currentTextChanged,this,&MainWindow::setZoom); ui->toolBar->addWidget(zLevel); There is absolutely no need to use Creator for connecting signals and slot. I, personally, consider this a bad habit, as connections are not clearly visible in the code.

@LRDPRDX said in In what thread would a QObject be deleted if it was moved to another QThread?: the dtor must be called and executed in the secondary thread not the main one. Am I right? Correct, that's what connect(thread, &QThread::finished, worker, &QObject::deleteLater); does and as you noted> No more events will be processed in the thread, except for deferred deletion events. Do the deleteLater will still picked up after the finished is emitted and the destructor will run in the secondary thread

@amu1550 This just means your program successfully ran from beginning to end. If you expected it to do anything, show what code you have written that would result in something happening.

@qwe3 said in How to stop QThread?: I change a little your code ( I never before used QFuture etc. so maybe I do something wrong ): runnable->run(); after futureWatcherProgress.setFuture(runnable->getFuture()); Okay, my code was o a little bit too rough, so I will be more explicit: a create a class based on QRunnable to be able to use it with QThreadPool. in the method getFuture(), the class instance is transformed to future a will run in next thread available the thread pool. So the run() method will be called a soon as possible after that I record the QFuture instance returned into the QFutureWatcher instance to be aware about state changes. Your fun1() don't made sense; the QFutureWatcher is a local variable which will be delete at function end! Change it like this: void MainWindow::fun1() { // do NOT use a local variable!!! auto futureWatcherProgress = new QFutureWatcher<void>(); // ==> delete QFuteWatcher instance instance when process done connect(futureWatcherProgress, &QFutureWatcher<void>::finished, futureWatcherProgress, [futureWatcherProgress]() { futureWatcherProgress->deleteLater(); qDebug() << "Processing done."; }); // ==> stop future on application exit connect(qApp, &QCoreApplication::aboutToQuit, futureWatcherProgress, &QFutureWatcher<void>::cancel); // follow progression connect(futureWatcherProgress, &QFutureWatcher<void>::progressValueChanged, this, [](int progressValue){ qDebug() << "Progression is" << progressValue; }); connect(futureWatcherProgress, &QFutureWatcher<void>::progressRangeChanged, this, [](int minimum, int maximum){ qDebug()<< "Progression range from" << minimum << "to" << maximum; }); connect(&futureWatcherProgress, &QFutureWatcher<void>::progressTextChanged, qApp, [](const QString &progressText) { qDebug() << "Progression:" << progressText; }); // create worker ==> QRunnable are automatically destroyed when finished (cf QRunnable::autoDelete()) auto runnable = new Work(); // register future and start processing futureWatcherProgress->setFuture(runnable->getFuture()); }

@J-Hilk , yes, if you know where to look but it isn't very clear on the signals page, unless you scroll down.

@IknowQT said in How to put dynamic library project in one project: I want to exclude files from being created Then do so. What is the problem?