General and Desktop

@Chris-Kawa said in Porting a simple shader from Qt5 to Qt6: @RobertB texture2D function is deprecated in GLSL v440 and only available in compatibility profile. Replace it with generic texture function. That worked, thanks. Trying to port the vertex shader now, but can't get it to work. I don't know what are inputs, or outputs, and how both frag/vert variables interact with eachother (if at all). Ill give up on this :-)

Error checking read/write connect(ui->pbUnpack, &QPushButton::clicked, [this]() { QString ziped = "../svtplay-dl-4.28.1.zip"; QString unziped = ".."; QuaZip zip(ziped); // Open the zip file for reading if(zip.open(QuaZip::mdUnzip)) { // qDebug() << "Zip file opened successfully."; QDir dir; for(bool more = zip.goToFirstFile(); more; more = zip.goToNextFile()) { QString filePath = zip.getCurrentFileName(); QFileInfo fi(filePath); QString dirpath = fi.path(); dir.mkpath(unziped + "/" + dirpath); QuaZipFile zFile(zip.getZipName(), filePath); // Open the source file in the zip file for reading if(zFile.open(QIODevice::ReadOnly)) { // qDebug() << "Opened file in zip for reading: " << filePath; QByteArray ba = zFile.readAll(); zFile.close(); QFile dstFile(unziped + "/" + filePath); // Open the destination for writing QFileInfo fi(dstFile); // If it is a directory, an error message will appear if(fi.isDir()) { continue; } if(dstFile.open(QIODevice::WriteOnly)) { if(dstFile.isOpen()) { dstFile.write(ba.data(), ba.size()); dstFile.close(); // qDebug() << "Write successful."; } else { qDebug() << "Destination file is not open for writing."; } } else { qDebug() << "Could not open destination file (dstFile) for writing: " << dstFile.errorString(); } } else { qDebug() << "Could not open file in zip for reading: " << filePath; } } zip.close(); qDebug() << "Done."; } else { qDebug() << "Could not open zip file: " << ziped; } });

OP's Ubuntu should support stat file for Birth. See e.g. How to Find Out When a File Was Created in Linux for a recent discussion of the issues.

@Asperamanca I'm just curious, because I've never heard of it and usually you would design the QuickItems in their QMLanguage on QtQuick side and then connect your C++ code to it

I assume QApplication::beep() is just sending \a to the console. This would also the reason why this cannot be expanded to other system sounds.

@jsulm No I didn't. However, the problem never appeared after I added "chartview->setViewportUpdateMode(QChartView::FullViewportUpdate)". I just assume it's solved...

@SGaist That's right. Thanks everyone

Hi and welcome to devnet, If you positioned everything by hand then you either have to redo that or position your widgets in your code for example in the resizeEvent method. Otherwise, the recommended way to work is to use layouts which automatically adapts to the size of your widget.

Beside the good point made @jsulm, since you know that your whole processing chain is slow, why are you reading the file faster than what your processing chain can do ? Rather than pushing images as fast as the reader can, you should pull them as fast as your processing chain allows. The way you build your chain just complicate things for no real benefit.

@jeremy_k said in How to draw a transparent area selection box: If there's no initial underlying window belonging to the application, the window manager is going to have to cooperate and not deliver the mouse button press to something else. That's the sort of thing I was thinking of. I didn't know plain applications had access to the visual desktop, only to the windows the manager allowed it to create. But I don't really know.

@JonB said in QHeaderView induvidual background colors: @Andy314 What I do not know is why/how a derived QHeaderView does not get this set as a base QHeaderView does. Perhaps a Qt/C++ expert would care to enlighten us? That is exact the problem I struggled. From the logic it can only be that the QTableView itself configures its QHeaderView correct. Indeed I found the code for it: void QTableViewPrivate::init() { Q_Q(QTableView); q->setEditTriggers(editTriggers|QAbstractItemView::AnyKeyPressed); QHeaderView *vertical = new QHeaderView(Qt::Vertical, q); vertical->setSectionsClickable(true); vertical->setHighlightSections(true); q->setVerticalHeader(vertical); QHeaderView *horizontal = new QHeaderView(Qt::Horizontal, q); horizontal->setSectionsClickable(true); // Here is the code **************************** horizontal->setHighlightSections(true); q->setHorizontalHeader(horizontal); tabKeyNavigation = true; #if QT_CONFIG(abstractbutton) cornerWidget = new QTableCornerButton(q); cornerWidget->setFocusPolicy(Qt::NoFocus); QObject::connect(cornerWidget, SIGNAL(clicked()), q, SLOT(selectAll())); #endif }

@Christian-Ehrlicher, @JonB I deployed the two programs again and had the same problem as before. Then I went through all the deployed .dll's and there were some missing. I copied them inside the folder manually and now it works. So the problem was windeployqt or some missing windeployqt-commands while deploying. Thank you again, I'll close this topic now.

@Chris-Kawa Hi Chris! Thanks for your response. Just to be clear, the message box display is the end of the route of an exception. There I have a stack trace which helps me a lot to debug and fix problems. Also, the wrapper I'm doing is just a workaround while I track down all the slots that are not capturing the exception inside them and letting the exceptions go out. That's not going to work. It's not connect that throws. The code that throws is invoked in the signal call when it's a direct connection or on the thread the slot is in when it's a queued connection. I understand that now. Thanks. Just don't let exceptions escape slots. There are tons of slots that already do that. But, unfortunately, the ones that are letting exceptions escape are in great amounts too. So, I have a lot of refactoring to do. :) If Messagebox is based on Qt UI (e.g. widgets) this shouldn't be called from non-UI thread, so you can't call it as a generic exception handler, since you don't know what thread might throw. Yes, it is. The problem I mentioned is only happening on UI threads. Anyway, thanks again for your time explaining that. It helped a lot to understand what's wrong, and how I can fix that and avoid falling on that pitfall again. Have a nice day!

@Tian-Sen This thread is 8 years old and the OP was also last time here 8 years ago. I suggest you start your own thread.

@Pl45m4 here it's the other way around, QtPDF is LGPL and uses pdfium which is Apache 2.0 so if @user931357 modifies Qt itself, he is required to publish the changes he did. However, if the changes are done to pdfium directly and only pdfium, then I think he is fine keeping them private.

@kalster great solution. Even after 11 years it is still usefull.

Not read the whole thread but maybe this is of interest: https://wiki.qt.io/TaskTree

Thats' a good idea, I'll give it a try. A slightly more complicated workaround was to specify: swig.output = ../../project/${QMAKE_FILE_BASE}_wrap.cxx GENERATED_SOURCES += ../../project/ui_wrap.cxx which keeps the wrapper file location but adds a relative path to it which is valid for both the source tree and shadow build tree. But that is not as neat as your idea.