General and Desktop

@aha_1980 Thank you very much, first. I got a way by my team: for(file, src_files) { # replace slashes in source path for Windows win32:file ~= s,/,\\,g QMAKE_PRE_LINK += $$QMAKE_COPY_DIR $$shell_quote($$file) $$shell_quote($$dst_dir) $$escape_expand(\\n\\t) }

Bump as I re-edited the topic with new info from "scratch"

@SGaist said in QImage from raw array of RGBA32floats ?: Hi, ARGB32 is 4 bytes hence the 32. So in your case it would rather be ARGB128. Argh this explains my confustion! Yep thats it thanks! @wrosecrans said in QImage from raw array of RGBA32floats ?: @Dariusz said in QImage from raw array of RGBA32floats ?: Format_ARGB32 Yup, that's 32 total bits per pixel, not 32 bits per channel like the GL_RGBA32F notation in OpenGL. And even then, there are also 32 bits per channel integer pixel formats that still aren't floating point. So even if you do see a 32 bit per channel format, you can't assume it's floating point if it doesn't say it explicitly. (Admittedly those aren't especially common, but formats like OpenEXR support them, and you'll sometimes see them used for things like Object-ID channels in 3D renders) Basically, every image handling API covers more or less the same basic functionality, but just different enough to make you want to rip your hair out when you try to use them together. It's not even like nothing in Qt can deal with floating point. QOpenGLFrameBufferObject supports OpenGL format names: https://doc.qt.io/qt-5/qopenglframebufferobjectformat.html#internalTextureFormat and can be FP internally. Then if you try to get a QImage from an FBO using toImage https://doc.qt.io/qt-5/qopenglframebufferobject.html#toImage-1 it will know how to do the pixel format conversion to 8bpc. You just can't get the raw FP data in a QImage. shrug. This stuff is always more work than you expect, mostly for no good reason. Argh too sounds about right! Looks like I will either have to build my own image library for format/data handling or perhaps use freeImage as my base... are there any other libraries u could recommend perhaps? I think I'll mark this issue as solved now as its Qt Limitation and me misunderstanding Qt format. Thank you all for help. Regards Dariusz

@JonB Hi， This is a very good website! Thank you very much! https://www.advsofteng.com/ Best Regards!

@VRonin said in Need lock for model and view?: Are you using multiple threads? Maybe. Posting event to the UI thread seems a good solution.

@aha_1980 said in Clear QLineEdit on Click: Hi @Shoaib-Muhammad, one thing to note is, that QLineEdit already has a clearButton. But I'm not sure how much that will help you, as the default implementation clears everything. But probably you can detect that and print your prefix again. Regards Hi aha_1980, Thank you for this. This works as an alternative. I have read this function somewhere and completely forgot about it. Thank you everyone for your inputs. I'll mark this thread solved. Kind regards, Shoaib

Hi There is also https://github.com/mohabouje/WinToast

@JonB Only when they are used with setIndexWidget() ;) In this case its more due to the fact that a QScrollArea with "hundres of buttons" gets slow pretty fast on non Desktop class devices. So View + Delegate is the sure road to better performance and in many cases the preferred way which you likely already know. :)

just use #qmake -t vclib QGLViewer.pro -spec win32-msvc

@lse123 Hi But installing the newest version gives the same as Updating to the newest version. Anyway as @jsulm says [image: VQgTQ5.png]

@hobbyProgrammer Yes, I meant to write, multiple-inheritance can be a bit tricky if you're not used to it. You have to explicitly indicate which class's method you are trying to override/invoke if there is ambiguity. You can Google for helper class C++ for examples. For a start any methods in your current derivation which do not use this (for the QGraphicsView), or can be re-factored not to use it, are candidates for moving out. Related is also encapsulation, where you define a class which does not derive from QGraphicsView but instead has the QGraphicsView as a member, and operates on that as needed. It's a fine line to decide when best to use what in your design, but that's programming for you :)

This also breaks test output to file (xml/xunit/csv). It's just cleaner and better to create a separate project for each test with an individual main if you want to use the Qt Test framework

@VRonin Thank you for your help! This works!

It turns out that I was later calling QObject::disconnect() on IntParameterWidget, which also disconnected signals in the base classes, including the QComboBox valueChanged( int ) signal. So it isn't a Qt bug/issue. Just my stupidity. Oops.

Using the 2nd thread is a good suggestion, but the documentation does not say anything about this being valid or not and all the question I saw about this went unanswered the difference between push and pull is not explained very well I believe. I read the code for the pulseaudio case and I have understood that the only difference is who owns the timer. In pull mode, the AudioOutput owns the timer and will call you to get the data. In push mode your application will require a timer (if one is not already present) and will do exactly the same, ie write the data.