Skip to content

General and Desktop

This is where all the desktop OS and general Qt questions belong.
83.4k Topics 456.4k Posts
  • vlc media Lecture : vlc headers vs vlc-qt SDK

    Unsolved vlc vlc-qt cross platform compilation plugins
    7
    0 Votes
    7 Posts
    905 Views
    T
    @JoeCFD Hello , thank you for this answer .. building this is not easy for me on windows. could'nt find a complete tutorial without using docker images or msys2 App. Meanwhile i tried to run the QtPlayer example in "doc\libvlc\QtPlayer" . It runs without error when i changed my .pro ... but video does'nt start affter selecting the file. What am i doing wrong ?
  • Help wanted: paintEvent is only called once in a series of datachanged event

    Solved
    7
    0 Votes
    7 Posts
    357 Views
    F
    @SGaist Thank you for your suggestion, problemed is solved althought without QTimer. : )
  • How to build real template class?

    Unsolved
    26
    0 Votes
    26 Posts
    3k Views
    FeRDNYCF
    @J-Hilk said in How to build real template class?: I'm never going to pronounce it cute, gun to my chest and all SRSLY. I resisted 30-odd years ago when they tried to convince us that SCSI was pronounced "sexy" (in fairness, so did everyone else), and I shall be no less resolute against this affront! "Cue tee" is the hill I'm willing to die on.
  • colorSchemeChanged under Gnome

    Unsolved
    19
    1 Votes
    19 Posts
    4k Views
    Axel SpoerlA
    But in all honesty, this code if very fragile. Under kde if no ColorScheme value is found in the local kdeglobals file (say the stringliteral is key is actually "General/ColorScheme" in this case) then an empty QVariant (invalid) is returned. All KDE settins read in QKdeThemePrivate::refresh() are (sadly hard wired in the code, and) updated when found in the expected place. In other words, they aren't updated if the respective readKdeSetting() returns a default constructed QVariant. I'd call that strict, which means it is fragile on purpose. There's something wrong, if a setting isn't in the expected place. There is room for improvement as regards logging and flexibility. The settings we need from KDE could be put in an enum, and mapped to their KDE settings key. That could be exported to / imported from a JSON file. Logging could be added for settings which couldn't be read. I'll look into this!
  • Video transmission through ethernet port.

    Unsolved qt c++ qtnetwork qtmultimedia
    5
    0 Votes
    5 Posts
    635 Views
    mrdebugM
    Hi, if you have to straming audio and video files you could use live555 on server side and, client side, only QMediaPlayer using rtsp.
  • Can not convert A QByteArray to QImage on windows7

    Unsolved
    6
    0 Votes
    6 Posts
    402 Views
    Christian EhrlicherC
    @Neether And you read it after requestFinished()? I would save it to a file and try to read it with another image reader. Also make sure the Qt jpeg image plugin is available on your system. (plugins/imageformats folder in your Qt installation).
  • lupdate adds build locations to .ts files

    Unsolved
    1
    0 Votes
    1 Posts
    107 Views
    No one has replied
  • unsync function , QSocketNotifier & Cannot move to target thread

    Solved
    13
    0 Votes
    13 Posts
    639 Views
    Christian EhrlicherC
    @__d4ve__ said in unsync function , QSocketNotifier & Cannot move to target thread: I use socket->waitForReadyRead(1000); Again: do not block the event loop, use signals and slots.
  • Qt Positioning and NMEA

    Solved positioning positionsource qtpositioning gps
    2
    0 Votes
    2 Posts
    510 Views
    D
    The NMEA plugin also requires the Qt Serial Port plugin. After installing it, the same snippet of code works as expected.
  • Thread affinity and signal emission

    Unsolved
    3
    0 Votes
    3 Posts
    292 Views
    Axel SpoerlA
    As @Christian-Ehrlicher said: The slot is executed in the thread, where the receiver lives. Since QThread inherits from QObject, you can simply assign a distinct object name to all your threads and qDebug() << __FUNCTION__ << QThread::currentThread() in your slot (or lambda). That behavior can be asserted. A ui object e.g. is likely to crash, if modified from a different thread than the ui thread.
  • How to use the QtLinguist, easy way?

    Unsolved qtlinguist cmake windows
    18
    1 Votes
    18 Posts
    4k Views
    ekkescornerE
    you don't need this. Qt 6.7 / QtC 13.0: there are automatically generated targets there, you can execute: update_translations release_translations [image: e68d24d5-128c-4a0f-9dce-7e1682099059.png]
  • QGraphicsSvgItem crash when rendering into pixmap

    Solved
    14
    0 Votes
    14 Posts
    1k Views
    jeremy_kJ
    @Joel-Bodenmann said in QGraphicsSvgItem crash when rendering into pixmap: I assume (!) that QGraphicsSvgItem requires QStyleOptionGraphicsItem to be non-null. That is correct. Beyond that, the documentation doesn't suggest that anything other than a valid object is expected.
  • 0 Votes
    4 Posts
    363 Views
    FeRDNYCF
    (Hint: For those playing along at home, itemAt(x, y) returns the item under those pixel coordinates in the widget. item(row, col) returns the item in the specified table cell.)
  • Open a dialog from other than mainwindow

    Solved
    14
    0 Votes
    14 Posts
    1k Views
    Pl45m4P
    @Bryan-Kelly said in Open a dialog from other than mainwindow: @Pl45m4 said in Open a dialog from other than mainwindow: Is main_x the simplification of your dialog classes dx (d1, d2, d3 or whatever you call them)? There may be something in the question that I don't understand, but I think: No, its just an integer declared at what I think of as the top level of my application. Yes, I wasn't asking what main_x is ( I know/can see that), I was rather asking about its meaning in your program / for you. The topic is named "Open a dialog from other than mainwindow", I made couple suggestions with full examples and code snippets, and now there's an Integer you want to pass somewhere, which I said, works the same as if you would pass any other pointer or data to your dialog. A term. I am using "main" to indicate the code that is first created when an application is created. If I take the defaults the file names used are mainwindow.h, main.cpp, mainwindow.cpp, and mainwindow.ui. So I have been using "main" to refer to the core of the app. The core that launches and anchors everything else As said above, it's not about why the variable is called like this. More like what are you trying to do with it and why. So I was wondering if you just simplified your code for your better understanding... and went from passing a QDialog pointer to passing an int... that's why I was asking. I will have multiple dialogs that each do some things, and some of the results of those dialogs need to get back to main. I would prefer that the dialogs be able to send such data to main rather than waiting for the user to ask for the data with a button click. Then other dialogs will need that information and should be able to fetch it rather than waiting for the user to click a button in main and send it to various dialogs. Understood. But the data doesn't "travel" from one dialog to another or to your MainWindow by itself. There needs to be some (user inter-)action going on. For example, you call the get functions from within the MainWindow. How it's done and how you pass data to your dialog class, I've already explained in my post here. And if you don't want the user to click any buttons, what's the point using a QDialog class, which returns a "state" whether the dialog was rejected or accepted by the user? Ok, so a strategy change. Create a class to serve as a repository for shared data. Call it "repo" for repository. Keep the data private. Provide public get and put functions that dialogs can access. This class will not do any processing, just serve as a repository for shared data. This sounds like a data "model". Therefore have a look at Qt's Model/View section and classes: https://doc.qt.io/qt-6/model-view-programming.html Ask yourself what do you really need/want... How your dialogs (or whatever you are using to display or modify your data) should look like and how you want to manage them. What kind of data you have? Consider using a proper data model + the right "view" class for displaying, when you are dealing with more complex data. So, please, if you don't have any questions regarding how to "Open a dialog from other than mainwindow" left, mark this topic as "solved" and create new topic(s) for your further questions. Because I feel like this topic isn't going somewhere. You reply to suggestions dealing with your initial problem with new/other issues.
  • This topic is deleted!

    Unsolved
    1
    0 Votes
    1 Posts
    10 Views
    No one has replied
  • FTP transfer error AuthenticationRequiredError although user and password are set

    Solved
    3
    0 Votes
    3 Posts
    226 Views
    T
    Hey, I found it! I used the long version of the upload path instead of the path from the FTP-User's access point
  • Qt 6.7 and QOpenGLWidget issue

    Solved
    6
    0 Votes
    6 Posts
    778 Views
    D
    I found the error in this lines: vertBuff->allocate(&vertices[0], (int)(vertices.size() * sizeof(QVector3D))); ~~~^~~~ indBuff->allocate(&indices[0], (int)(indices.size() * sizeof(GLushort))); ~~~^~~~ Now all works correctly: [image: 47af7f2e-fdc3-459e-b7a1-4d7ec94a9196.png]
  • 1 Votes
    29 Posts
    5k Views
    SGaistS
    @ChrisW67 Interesting take, I didn't think of that one !
  • 0 Votes
    3 Posts
    549 Views
    MasterBLBM
    Hello @SGaist That's correct. Sadly, in my use case usual way of closing the context menu by click outside of its bounds has side effects, as in close neighborhood of the menu there are many QWidgets whose react to mouse clicks. Hence the need of dedicated close/cancel button. However, I've finally found a hint in Assistant "If the QWidgetAction fires the triggered() signal, the menu will close.". So, the problem is solved for my case, the solution is just: connect(closeButton, &QPushButton::clicked, menuTitle, &QWidgetAction::triggered); but thank you mate nonetheless for trying to help.
  • Native QPrintDialog does not process events during it's execution

    Solved
    9
    0 Votes
    9 Posts
    449 Views
    S
    Alright, it took me a bit more than I wanted but here is how it went: Created a TTimer with Timeout slot to indicate a request for closing the window. Subclassed QPrintDialog into TPrintDialog. For QT5.7 I've connected the TTimer::Timeout signal to TPrintDialog::close. This is not necessary in QT>=6, this is because for some reason the close method is not invoked when destroying the window in QT5.7. Overridden the TPrintDialog::closeEvent - this is where the "hacking" begins - inside I find a HWND handle to a PrintDlg with GetWindow((HWND)this->winId(), GW_HWNDPREV) , which gets the window that is before the this->winId() in Z axis on the screen, and then send a WM_CLOSE message to the handle with PostMessage(handle, WM_CLOSE, 0, 0), and set the handle to nullptr; Feel free to lecture me if you see something concerning about that or something that could be done better :) Here is a source code for the tests, I tried to make it as compact as possible: app.hpp #pragma once #include <QMainWindow> #include <QTime> #include <QPrintDialog> class TAutoLogoff : public QObject { Q_OBJECT public: explicit TAutoLogoff(QObject* parent); ~TAutoLogoff(); virtual void timerEvent(QTimerEvent* e) override; void StopTimer(); public: signals: void Timeout(); private: ULONGLONG m_interval; ULONGLONG m_begin_tick; int m_timer_id; }; class TMainWindow : public QMainWindow { Q_OBJECT public: explicit TMainWindow(QWidget* parent = nullptr); ~TMainWindow(); void Process(); public slots: void OnTimerExit(); private: TAutoLogoff* m_auto_logoff; }; class TPrintDialog : public QPrintDialog { Q_OBJECT public: explicit TPrintDialog(QWidget* parent = nullptr); ~TPrintDialog(); virtual void closeEvent(QCloseEvent* e) override; }; app.cpp #include "app.hpp" #include <QApplication> #include <QTimer> #include <windows.h> static TAutoLogoff* g_auto_logoff = nullptr; TAutoLogoff::TAutoLogoff(QObject* parent) : QObject{ parent } , m_begin_tick{ GetTickCount64() } , m_interval{ 2500 } , m_timer_id{ -1 } { m_timer_id = QObject::startTimer(m_interval, Qt::CoarseTimer); } TAutoLogoff::~TAutoLogoff() { qDebug() << "TAutoLogoff::~TAutoLogoff"; } void TAutoLogoff::timerEvent(QTimerEvent* e) { if (m_begin_tick + m_interval < GetTickCount64()) { StopTimer(); emit Timeout(); } } void TAutoLogoff::StopTimer() { if (m_timer_id != -1) { QObject::killTimer(m_timer_id); m_timer_id = QObject::startTimer(m_interval, Qt::CoarseTimer); } } TMainWindow::TMainWindow(QWidget* parent) : QMainWindow{ parent } , m_auto_logoff{ new TAutoLogoff{ this } } { g_auto_logoff = m_auto_logoff; connect(m_auto_logoff, &TAutoLogoff::Timeout, this, &TMainWindow::OnTimerExit, Qt::QueuedConnection); QTimer::singleShot(0, this, &TMainWindow::Process); } TMainWindow::~TMainWindow() { qDebug() << "TMainWindow::~TMainWindow"; g_auto_logoff = nullptr; } void TMainWindow::Process() { TPrintDialog pd{ this }; if (pd.exec() != QPrintDialog::Accepted) return; } void TMainWindow::OnTimerExit() { qDebug() << "TMainWindow::OnTimerExit"; close(); } TPrintDialog::TPrintDialog(QWidget* parent) : QPrintDialog{ parent } { connect(g_auto_logoff, &TAutoLogoff::Timeout, this, &TPrintDialog::close); } TPrintDialog::~TPrintDialog() { qDebug() << "TPrintDialog::~TPrintDialog"; } void TPrintDialog::closeEvent(QCloseEvent* e) { qDebug() << "TPrintDialog::closeEvent"; auto* handle = GetWindow((HWND)this->winId(), GW_HWNDPREV); if (handle != nullptr) { PostMessage(handle, WM_CLOSE, 0, 0); handle = nullptr; } QPrintDialog::closeEvent(e); } main.cpp #include <QApplication> #include "app.hpp" int main(int argc, char *argv[]) { QApplication app{ argc, argv }; TMainWindow window{}; window.show(); return app.exec(); }