General and Desktop

@ChrisW67 it is the terminal outputs overlaping ,the file's text itself not wrong, my fault!!

My solution was to create a list of all the command line arguments not starting with '-' or directly following one starting with '-' in the derived Application class constructor. In the FileOpenEvent handler, the filename is checked against that list, and if found the event is ignored and the filename is removed from the list, otherwise the event is handled normally and tries to open a file.

@Grimface reimplement these methods and reject the proposed action when adequate.

Sorry I don't have deep knowledge of the Wayland internals. Based on that page content it seems that kwin and sway supports this protocol.

@JonB said in QVariant - empty or Null: This is still null QVariant, so QVariant::isNull() can still be used to test for it. Correct. But QVariant::isValid() returns true in this case but not for value = QVariant() (as written in the documentation). But binding an invalid QVariant to a QSqlQuery will work too.

@DQUY05 I had the same problem. Have you solved it now?Thanks

@jsulm I suppose it's possible, but I moved to XFS filesystems a month ago and never had a problem with that until 2-3 days ago. A few packages related to filesystems (btrfs packages) updated a few times in the last week, so it's possible they did something that confused Qt to create this huge file. However, I'm not that filesystem savvy, so RN I'm just shooting in the dark, so to speak. I moved to XFS bc I read it was meant for large files, for faster moving of those large files between different storages and XFS is a generally faster filesystem when it comes to copying large files. Which turned out to be true, esp. compared to ext4 whose performance feels a lot like NTFS. If that problem occurs again, I'll attempt to archive the file again (this time through a Live distro) and see if I can send it over to Qt support. Maybe there's something among these 480 MiB which explains what happened.

@JonB But you talk about "The purpose is to have different lines/coloring for each line". That implies to me you do want multiple, separate line series, each with their own points and color? Yes. In that case you do want new QLineSeries created each time round the loop, so you end up with 5 lines (and get rid of the wasted one outside the loop). Okay, thank you. I did this and with a little bit of refactoring I got it to work as expected. Appreciate the assistance!

@JonB DId not know about that, thank you!

@syrine So ld/collect2 is telling you that function is not found. Either you are not linking against the library, or function is not defined and exported from it. Or maybe some clue from the exact error message.

@kshegunov Important addition. If there is a struct|class MyType inside this namespace MyNamespace in which Q_DECLARE_NAMESPACE_TR(MyNamespace) macro used, all direct call of tr() function inside MyType methods will deduct context as MyNamespace::MyType. Not just MyNamespace. That's why translation may not work. Don't forget to call tr() inside this namespace like MyNamespace::tr() to avoid such context issue.

@jsulm @jsulm void MainWindow::on_openCamera_clicked() { try { static QTimer qTimer ; if ( bContinue ) { qTimer.stop(); QObject::disconnect(&qTimer, SIGNAL(timeout()),this, SLOT(showPicture())) ; ui->openCamera->setText("open"); ui->status_label->setText("Trạng thái máy ảnh: Tắt"); } else { QObject::connect(&qTimer, SIGNAL(timeout()),this, SLOT(showPicture())) ; qTimer.start(100); ui->openCamera->setText("close"); ui->status_label->setText("Trạng thái máy ảnh: Bật"); } bContinue = !bContinue ; } catch( exception const &e ){ ui->status_label->setText("ERROR"); } }

@Hyperspider-Software Resizing and moving the window will cause updates, renders and repaints. If everything is done and nothing changes, it doesn't have to get updated at such high rate as it would, when you grab the window and move it around and change dimensions of the content. Just a guess. Maybe it might be helpful if you show some code, how the window is rendered. Is it just one window or does everything behave like this?

@ChrisW67 Ahh, ok good info thanks, I'll take a look at that library; thank you.

@Roberrt Read characteristics are undefined if you don't guarantee exclusive access, or at least use data types that are guaranteed to be atomic. Generally the read of a native word sized int is atomic across architectures because the CPU microcode likes to deal with a whole word at a time, and preemption wont occur in the middle of a machine code instruction. But it is safer to lock for reads as well.

@Paul-Colby Thanks for the reply. Just for sake of discussion - what would be the benefit of adding EXTRA file to EACH suboproject ? Besides it does not meet the post " specification" to " add single place to control preprocessor" to main .pro. Cheers

@DatGK https://codebrowser.dev/qt5/qtbase/src/widgets/widgets/qprogressbar.cpp.html#424 QFontMetrics fm = fontMetrics(); QStyleOptionProgressBar opt; initStyleOption(&opt); int cw = style()->pixelMetric(QStyle::PM_ProgressBarChunkWidth, &opt, this); QSize size = QSize(qMax(9, cw) * 7 + fm.horizontalAdvance(QLatin1Char('0')) * 4, fm.height() + 8); if (opt.orientation == Qt::Vertical) size = size.transposed(); So qMax(9, cw) * 7 + fm.horizontalAdvance(QLatin1Char('0')) * 4. I think the gist is 63+-odd for the chunks (7 chunks) + 4 character 0s. Then in your case this is applied for the height instead of the width. May be quite close to 95-odd pixels.

@SGaist You are right.. I missed that completely. m_client = new QMqttClient(this); m_client->setHostname(ui->lineEditHost->text()); m_client->setPort(ui->spinBoxPort->value()); m_client->setProtocolVersion(QMqttClient::MQTT_5_0); Thank you very much for quick help