General and Desktop

@Axel-Spoerl I assume this is OP's working code, solved.

@Rumeysa_135 Hi, You keep a buffer that you append to each time readyRead is fired and check for when you have a full frame of your data in there. Then take the data out of the buffer and process it.

Absolutely! To run repc.exe on all .rep files during builds, add a custom step in your project config. Utilize the relevant build system (e.g., CMake or qmake) to integrate repc.exe with the needed options for .rep file processing, ensuring automatic execution in each build.

@John-Hon No, but you can block signals while you reset the cursor.

@jsulm Hi， I uploaded a code that can reproduce this problem, Below is the download link for the code: https://drive.google.com/file/d/1cvgUQThXoCUkt8UHIrm71rAzn-i1ErYA/view?usp=sharingrf Could you please take a look at what's wrong with the code? Thank you.

@Asperamanca See bug report https://bugreports.qt.io/browse/QTBUG-120924

I would expect that do_task will return after it is done. QtConcurrent::run will return a QFuture. In order to get a signal out of that you can use a QFutureWatcher. Since your callback does not seem to provide any additional parameters I would personally prefer this approach. (If there are additional callback, e.g. for progress, a wrapper class makes more sense.)

Recursion can always lead to a place where the stack is too deeply nested. Modern compilers can convert tail recursion into a loop to avoid this problem. However, signals and slots will prevent this. This would only be a problem if you are using a DirectConnection for your signals and slots (which would most likely happen automatically). You should make sure that your connections (for the state machine) are QueuedConnections. Especially if the state machine is run inside the main thread a DirectConnection would block the event loop. A QueuedConnection would allow other things to be processed by the event loop as well.

@Axel-Spoerl I managed to get it working. I utilized the "Override deployment data from build system" option and modified the final step to "Upload files via SFTP" as shown in the image below. [image: e6553330-e4df-4768-ab73-e24b7bdf7673.png] Now, I have a couple of questions: What configurations are required to enable the build system to automatically detect the source and target directories? Is there any documentation available that provides a description of how the deploy files step is utilized? I haven't been able to locate it.

@asisisyah first of all thank you so much everyone. i made a "starter.sh" file... than echo nvidia | sudo -S ./myApp ... than start it with startUp Application . its worked. no problem just now thank you so much everyone

@Babitha Be aware that QtWebKit was removed from Qt later on Read https://stackoverflow.com/questions/2461799/statically-compiling-qt-4-6-2 and https://forum.qt.io/topic/90051/qtwebkit-cannot-build-qtwebkit-static-for-static-4-8-x-or-5-5-1. Gist is that although some people say they did manage to compile it statically it is apparently "not easy" and also A few people succeeded in making static builds on Windows, however getting linking right is not trivial

@buhtz Well it's only a changeEvent() on (subclassed) QMainWindow, not much. But agree it's not vital.

@Jsla The problem is that the "project directory" which exists while you develop simply does not "exist" at runtime when you deploy elsewhere/to other people. By which I mean there is no way to "locate" it. You then have 3 choices: Use Qt's QStandardPaths Class to generate a full path to one of the standard directories and use that. The problem is that it's not easy to deploy your file(s) there in the first place,. Use Qt's QCoreApplication::applicationDirPath() to locate where the executable lives. Use that to generate a full path to some images sub-directory from there where the images have been provided. As @SGaist says use Qt's resource system to embed the images into the actual executable and access them there. This is perhaps the easiest, requires you to specify you are using resources at development time.

@ChrisW67 @ChrisW67 said in How to find out the camera device ID in the metadata of images and videos?: Why can't you believe this? The evidence is right in front of you. The birth time of the file on the Windows file system is whenever you created the file. It has zero to do with the content of the file, or the creation time of the file on any previous system. Its because for all other 45k media files (except for those taken with that one particular gopro camera) QFileInfo f("myfile.jpg"); QDateTime dt = f. metadataChangeTime(); and QFileInfo f("myfile.jpg"); QDateTime dt = f. birthTime(); return identical values and they reflect exactly the time when this media was created. So QFileInfo must somehow have accessed this otherwize the date would be different. @ChrisW67 said in How to find out the camera device ID in the metadata of images and videos?: As for the metadataChangeTime() being before the birthTime(), different by how much? 1 year apart. exactly the time distance btw media recorded and media copied to hard drive. @ChrisW67 said in How to find out the camera device ID in the metadata of images and videos?: You should look at exiftool to see how it might help you. I did integrate the exiftool package into my codde. That is why for jpg only, this is not a problem. But for any other file format, be it video or image, problem is unsolved. But, you just inspired me to invest more time for a solution: maybe if I dedicate more time understanding what exif tool code does in particular and as it simply reads meta data for jpg, maybe I can modify it to read any media file's meta data (provided that I gain full understanding of where the meta data is accessible for each file). I created this bug (actually a suggestion how to improve) which might solve my birth date problem and as QMediaMetaData also can access most if not all meta data once [mediaStatusChanged()](link url) but with delay with which miltithreading cannot live with as described above: [https://bugreports.qt.io/browse/QTBUG-120959](link url)

@buhtz said in What is the system under test when doing Qt tests?: So it seems it is not easy to reach complete code coverage for Qt code using tests. If it's only your code which has full coverage I don't see why it should not be possible.

@NULL_NULL m_buttonis directly parented to MainWindow, which at this point doesn't have a central widget. That's added (amongst other things) in setupUi(). Hard to say where and why exactly things go wrong, but it's somewhere there. It'll be better to construct the button without a parent in the first place: , m_button(new QPushButton("KSKSKSKSK")) You can add it after calling setupUi(), e.g. with m_button->setParent(centralWidget()); or by adding it to a layout with ui->anyLayout->addWidget(m_button);

@Axel-Spoerl Ah yes that was it, thanks. Stay warm...

@Christian-Ehrlicher Thanks a lot! You are right! I forgot to activate (bind) the program in paintGL(): void paintGL() override { m_program.bind(); glClear(GL_COLOR_BUFFER_BIT); glDrawArrays(GL_TRIANGLES, 0, 4); } [image: 69d1a505-0c96-4e98-b236-54dc8cdf047f.png] pro QT += core gui openglwidgets widgets win32: LIBS += -lopengl32 CONFIG += c++17 SOURCES += \ main.cpp main.cpp #include <QtGui/QOpenGLFunctions> #include <QtGui/QSurfaceFormat> #include <QtOpenGLWidgets/QOpenGLWidget> #include <QtOpenGL/QOpenGLBuffer> #include <QtOpenGL/QOpenGLShaderProgram> #include <QtWidgets/QApplication> class OpenGLWidget : public QOpenGLWidget, private QOpenGLFunctions { public: OpenGLWidget() { resize(350, 350); setWindowTitle("OpenGL Triangle"); } private: void initializeGL() override { initializeOpenGLFunctions(); glClearColor(0.4f, 0.8f, 0.9f, 1.f); qDebug() << "OpenGL Version:" << (const char*) glGetString(GL_VERSION); qDebug() << "GLSL Version:" << (const char*) glGetString(GL_SHADING_LANGUAGE_VERSION); qDebug() << "OpenGL Vendor:" << (const char*) glGetString(GL_VENDOR); QString vertexShaderSource = "attribute vec2 aPosition;\n" "void main()\n" "{\n" " gl_Position = vec4(aPosition, 0.0, 1.0);\n" "}\n"; QString fragmentShaderSource = "#ifdef GL_ES\n" "precision mediump float;\n" "#endif\n" "//out vec4 fragColor;\n" "void main()\n" "{\n" " gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);\n" "}\n"; m_program.create(); m_program.addShaderFromSourceCode(QOpenGLShader::ShaderTypeBit::Vertex, vertexShaderSource); m_program.addShaderFromSourceCode(QOpenGLShader::ShaderTypeBit::Fragment, fragmentShaderSource); m_program.link(); m_program.bind(); float vertPositions[] = { -0.5f, -0.5f, 0.5f, -0.5f, 0.f, 0.5f }; m_vertPosBuffer.create(); m_vertPosBuffer.bind(); m_vertPosBuffer.allocate(vertPositions, sizeof(vertPositions)); m_program.setAttributeBuffer("aPosition", GL_FLOAT, 0, 2); m_program.enableAttributeArray("aPosition"); } void paintGL() override { m_program.bind(); glClear(GL_COLOR_BUFFER_BIT); glDrawArrays(GL_TRIANGLES, 0, 4); } private: QOpenGLShaderProgram m_program; QOpenGLBuffer m_vertPosBuffer; }; int main(int argc, char *argv[]) { QApplication app(argc, argv); OpenGLWidget w; w.show(); return app.exec(); }