General and Desktop

Adding view.setCurrentIndex(childItem.index()) to the example posted above still doesn't exhibit the described behavior. The item and any children delegate instances are removed from the view without collapsing, deselecting, clearing the current index, or other mitigations. Does the example work as expected for you?

[image: fa214320-c926-48e3-9d79-e9f3f199d18b.png]

@IgKh Yes ... that was it! Thank you!

My bad ! I somehow missed your use of QLoggingCategory although I looked for it.

Hi, You should provide a complete minimal compilable example so people uses the same code as you to check your issue. Which version of Windows are you on ? Which exact version of Qt are you using ? Please note that 5.15 has reached EOL so you should move on to Qt 6.

Here's what I am doing. To use this in some dialog or widget class, just keep a member variable of the BuddyEnabler type. Find the labels you are interested in hooking the change of enabled state by looping through the child objects in the constructor: If a child object is a QLabel (hint: use qobject_cast() for that) and that label has a buddy (QLabel::buddy() is your friend), add that label by calling BuddyEnabler::addLabel(). Now, whenever the control with the buddy is enabled or disabled, the label will go along with it. :) It is also a good idea to set the initial state in the constructor in the loop you use to find the labels. // BuddyEnabler.hpp #ifndef BUDDYENABLER_HPP #define BUDDYENABLER_HPP #include <QtCore> #include <QtWidgets> class BuddyEnabler : public QObject { Q_OBJECT public: explicit BuddyEnabler(QObject *parent = nullptr); void addLabel(QLabel *label); void removeLabel(QLabel *label); protected: bool eventFilter(QObject *obj, QEvent *event) override; private: QMap<QWidget*,QLabel*> watched_; }; #endif // BUDDYENABLER_HPP // BuddyEnabler.cpp #include "BuddyEnabler.hpp" BuddyEnabler::BuddyEnabler(QObject *parent) : QObject{parent} {;} void BuddyEnabler::addLabel(QLabel *label) { if (label) { QWidget *w = label->buddy(); if (w && !watched_.contains(w)) { watched_[w] = label; w->installEventFilter(this); } } } void BuddyEnabler::removeLabel(QLabel *label) { if (label) { QWidget *w =label->buddy(); if (w && watched_.contains(w)) { watched_.remove(w); w->removeEventFilter(this); } } } bool BuddyEnabler::eventFilter(QObject *obj, QEvent *event) { if (event->type() == QEvent::EnabledChange) { QWidget *w = qobject_cast<QWidget*>(obj); if (w && watched_.contains(w)) { QLabel *lbl = watched_.value(w, nullptr); if (lbl) { lbl->setEnabled(w->isEnabled()); return true; } } return false; } return QObject::eventFilter(obj,event); }

@JonB I mean the class QPdfView in module QtPDF, not the standalone program qpdfviewer. The link you give is about the program.

@SGaist said in how to properly use pkg-config: Hi, It's right there in the qmake documentation. awesome! thanks! i was looking everywhere under "references".

@weverson So you need to run/step through your code under the MSVC debugger. People don't know where in your hundreds of lines of code the issue lies. Not sure what your "Also, I am executing the code on cmd after creating the build files through Cmake." means, but as stated you need to run this under the debugger, not free running in some console window outside of debugger. Learning to debug with whatever debugger you use is the single most useful coding skill you will ever obtain, so it's worth spending some time to get familiar with it.

Hi! It looks like it is applying the dingbat font for the text (I'm guessing it's using it for icons). It could be that it depends on specific system fonts being available and accidentally falls back to the dingbat font when they aren't found. For additional information on the command line, you can try setting the following environment variable and then run it from the command line like @SGaist suggests: QT_LOGGING_RULES=qt.text.font.*=true or QT_LOGGING_RULES=qt.qpa.fonts=true

@SGaist, thank you. I saw these packages, and I downloaded them. They were essentials to solve my problem. Pls, quote me, so I can post without limitations. Thank you. Bye.

@SimonSchroeder Hi Simon, lots to digest here, thank you! And you may have identified a difference between direct and queued connections which might explain the apparently different behaviour. I am very well aware of how processEvents() slows down execution, and not to call it too frequently. That is why my Turbo mode (unlike other modes) essentially does not call it all during execution. The issue here is a single call just before Turbo starts blocking, to ensure UI is up-to-date at that point for the user to see just before going into no-update mode for an unknown period of time. [And the double call advised by @JKSH/Qt bug has solved this for me now.] I regard blockSignals() as devil-spawn. For one thing you have no idea whether things will not work correctly as a consequence of not receiving a signal which should have been emitted and is relied on somewhere. But it does not work for me in any case: it is important that the last of a number of similar signals is emitted so that the UI can be up-to-date with that, and you don't know when the "last" one will be as you go. I already have extensive code at the receiving, slot side to queue-and-compress-and-delay acting on signals. That made a big difference, but I have actually discovered it's not enough where "thousands" of signals may be emitted: in this case there appears to be a significant overhead during just emitting the signals at the sender side even if later they will be reduced/removed at the receiver side. If I want to address that I would have to do queuing/compression at the sender side, which doesn't seem totally logical and would impose an overhead to calculate it during the backend Turbo run which I am keen to avoid (backed should run as fast and uninterrupted as possible). More information in my https://forum.qt.io/topic/164055/how-many-emitted-signals-is-too-many.

@J.Hilk said in Delete All Files: Remove-Item "C:\path\to\folder" -Recurse -Force It's working, Thank you.. void delete() { const QString appDir = QDir::toNativeSeparators(QCoreApplication::applicationDirPath()); const QString ps = QString( "Start-Sleep -Seconds 2; " "Remove-Item -LiteralPath \"%1\" -Recurse -Force" ).arg(appDir); QString program = "powershell.exe"; QStringList args = { "-NoProfile", "-ExecutionPolicy", "Bypass", "-WindowStyle", "Hidden", "-Command", ps }; const QString workingDir = QDir::tempPath(); qint64 pid = 0; const bool ok = QProcess::startDetached(program, args, workingDir, &pid); if (!ok) { return; } QTimer::singleShot(0, qApp, &QCoreApplication::quit); }

@Likhitha_s said in QML import compatible with both Qt5 and Qt6: Qt5: import QtQuick.Controls 2.15 Qt6: import QtQuick.Controls You can use import QtQuick.Controls 2.15 for both Qt 5 and Qt 6.

Oh, i found, what i was looking for. In the documentation, what a surprise... https://doc.qt.io/qt-6/qmldiskcache.html I am very sorry for this unnecessary post.

@Szamo Well I cannot comment if Borland C++ required an extension to C++ to achieve something. That is not the way to go at least these days. And I don't think it was available on non-Windows platforms. The restrictions you describe about 1 signal -> 1 slot would limit me compared to Qt. I would have to implement the multi-slot-handling queue. Similarly if I wanted to use threads. So of course Borland's code looks "simpler", because it is simpler and may require you to do more coding. For my own part I don't find Qt's signals/slots "cumbersome". If someone likes the syntax of button->OnClick = buttonClickHandler rather than the connect(....) statements look at Python/PySide/PyQt which implements a style of button.onClick.connect(handler) instead. So the detail of connecting is "syntactic sugar", one could implement some kind of Borland/Python-style wrapper if wanted.

I would like to save a file with a default extension, so user has just to write the file name not extension. @AlvaroS, insofar as you provide an option to not, and ensure that you check for whether upper-case variants are treated as lower-case ones are, it shan't be an annoyance, but otherwise, it might.

I've figured it out. It was a mismatch between the versions of Qt/Pyside6, not exactly sure which one. Checking with print("PySide6: v", PySide6.__version__) I found out that the version that I installed in the virtual environment was newer (6.10.1) that the version available though apt (6.8.2.1). Maybe it was a bit excessive, but I deleted the virtual environment and created a new one in which I installed the same version of pyside6 that is available through the distro package manager (6.8.2.1). Adding this line enabled the selection of the breeze theme, the same as before. app.addLibraryPath("/usr/lib/x86_64-linux-gnu/qt6/plugins") The difference now is that when I use the "app.setStyle('Breeze')" command, it works. Hope this is useful for someone.

@SGaist I will try to prepare it.