Re: [Interest] Qt archives corrupted?
Il 30/03/20 22:02, Matthew Woehlke ha scritto: What happened to the Qt archives? I can download 1.41, but 5.2 - 5.8 and 5.10 and 5.11 are missing? They have been moved here https://download.qt.io/new_archive/qt/ HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers
On 27/03/2020 15:03, Tomas Konir wrote: Sorry for possible misunderstanding, but i think, that original question was little different. Question was: There is company, where are two developer groups: Group1: Use QtCreator and works with QT libraries (and works with other code which not use QT libraries). All users have Commercial License. Group2: Would like to use QtCreator and not use QT libraries (they working only with QT unrelated code). The want use QtCreator only as IDE Can both groups use QtCreator? I thought, that using QtCreator as IDE is not conditioned with having QT Commercial license. The only difference that comes to mind is that the first group can use Qt Creator under its commercial license, which may come with some extra features (not exactly sure of which ones, at this particular point in time). The second group can instead just use Qt Creator under its open source license. The open source license of Qt Creator itself does NOT extend in any way to the software you develop (cf. the GPL FAQ). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt5 connect signal to signal
Il 10/03/20 14:21, Jérôme Godbout ha scritto: This should work, the default is connect type auto, which mean that it will be direct if both object (source and this in your example) have the same thread affinity. If both have a different thread affinity, the connection will be queued Watch out: the sender object thread affinity DOES NOT matter. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Callgrind under Linux
Il 06/03/20 18:13, Christian Kandeler ha scritto: By the way: Is there a list of such environment variables that let you configure Qt behavior at runtime? I wish it was (or similarly there was one of the compile macros to define). I've tried to write one myself, but it falls out of sync quite quickly. Something for the doc team? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Callgrind under Linux
Il 06/03/20 15:56, Konstantin Tokarev ha scritto: We did find a closed issue about it:https://bugreports.qt.io/browse/QTBUG-62118 But no solution or hint about the cause of this. You can configure Qt with explicitly disable RDRAND, or use same hack as used in tst_qrandomgenerator.cpp, passing SkipHWRNG flag to qt_randomdevice_control. Or just export QT_NO_CPU_FEATURE=rdrnd , no need to rebuild Qt (RDRAND is detected at runtime). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: Re: Signal/Slot connection fails, even though QMetaObject::activate is called
Il 08/02/20 03:37, Jonathan Purol ha scritto: After manually removing every line of code to see when a MVCE would work, I found a loose `blockSignals(true)` flying around that was there from a debugging session. By the way: there's QSignalBlocker for not forgetting... HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QWebSocket text methods should be utf8?
Il 15/02/20 15:46, Roland Hughes ha scritto: The QString class, by virtue of the little yippy-yappy dogs it is running on isn't big-endian hence your continually calling toUtf8(). Endianess has nothing to do with this: 1) QString is UTF-16 encoded (in host byte order). The whole ordeal is that it's *not* UTF-8, therefore it needs to transcode from it (even on big-endian systems). 2) UTF-8 has the same byte order everywhere. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] What does LTS mean?
Il 06/02/20 17:11, Jason H ha scritto: With Qt 5.12 not being in strict phase (there is no 5.15 LTS yet, and I cannot find an announcement) or even very strict phase, I assume 5.12 is standard LTS phase. I believe fixes for crashes are something that should be in LTSs. Change my mind? Even if you can change my mind, I am not sure why we even have LTSs in the first place? Can we get a more formal definition of what a LTS is other than "support". Just nitpicking (and truly non answering), the paperwork says that 5.12 has already been in strict mode for almost an year (?). https://quips-qt-io.herokuapp.com/quip-0005.html strict This period starts when the one after next stable branch is created (for the 5.9 LTS, the one after next is 5.11). Meaning 5.12 went strict when the 5.14 branch was created (not when 5.14 was released). Of course the definition of strict/very strict is very relative. If you have fixes for bugs you really want to be cherrypicked, make an argument for each one on the respecive bug reports? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Account email verification needed
On 29/01/2020 15:01, The Qt Company wrote: Thank you for creating a Qt Account. Please verify your email address 'interest@qt-project.org' within 72 hours to complete the registration process. ^ This was me. Ignore it. There's something very fishy here: are the lists open for posting also to unregistered users, or is @qt.io whitelisted? Both sound like bad ideas. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_DECLARE_SMART_POINTER_METATYPE type restriction
Il 28/01/20 21:59, j...@embedded.pro ha scritto:
I was investigating the idea of storing an std::shared_ptr in a
QVariant. This would allow me to put a shared pointer to my custom data
int a QComboBox's data field.
I'm aware of the existence of QSharedPointer. The data I am working with
is only available wrapped into an std::shared_ptr (data provided by a
3rd party component). This leaves me with the choice of either storing
raw pointers or registering my own type for the use with QVariant.
For this, I've been looking at Q_DECLARE_SMART_POINTER_METATYPE. The
documentation has the following to say about this macro:
This macro makes the smart pointer SmartPointer known to QMetaType as
a smart pointer. This makes it possible to put an instance of
SmartPointer into a QVariant, if T is a type which inherits QObject.
I'd be interested to know why T would be restricted to a type which
inherits QObject.
Can anybody enlighten me?
If you have a concrete type, like std::shared_pt, then just
Q_DECLARE_METATYPE(std::shared_ptr) is sufficient and necessary for
storing it into a QVariant. Then you can set it as your combobox' user
data or whatever.
If you want to register a _class template_ so that any instantiation of
your template with a type T that inherits QObject is automatically
registered, then you have Q_DECLARE_SMART_POINTER_METATYPE. The reason
for this has mostly to do with QVariant's ability of unwrapping the
smart pointer and apply qobject_cast to it, e.g.
template class MySmartPtr { ~~~ };
Q_DECLARE_SMART_POINTER_METATYPE(MySmartPtr);
MySmartPtr ptr = new QPushButton;
QVariant v(ptr); // works
v.canConvert(); // true
QObject *rawPtr = v.value(); // works
QAbstractButton *downCast = v.value(); // works too
To say it all:
1) this ability of QVariant of doing magic casts is somewhat frowned upon;
2) Q_DECLARE_SMART_POINTER_METATYPE for all std:: smart pointers should
really something that Qt itself takes care of (it's not at the moment, I
can only guess we don't want a central header like qmetatype.h to pull
in ).
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QOpenGLWidget and quad-buffer stereo
Hi, On 20/12/2019 14:57, Tilmann Krueger wrote: Are we doing something wrong? How is one supposed to set this up correctly? Or are we really stuck with QGLWidget? All tried with a Windows 10 1903, with Quadro FX 4600 and a nvidia 3d vision compatible display from Acer. Not trying to give an "ultimate" answer, but I strongly doubt what you're doing is feasable with QOpenGLWidget. A fundamental difference between QOpenGLWidget and QGLWidget is that with QOpenGLWidget you don't draw to the screen, you draw into a FBO. The contents of this FBO are then "composed" with the rest of the contents (raster, other QOpenGLWidgets, other QQuickWidgets, etc.) of a given top level window. ... This involves Qt setting up a GL top level window, creating a GL context for it to do the composition, creating another context for your QOpenGLWidget sharing with the first context, and a lot of extra magic; the only way for you to control the creation of these GL contexts is via "global" settings (setDefaultFormat()) ... For this reason I don't think stereo/quad rendering is supported at all via QOpenGLWidget. The FBO created by Qt for your QOpenGLWidget will only have a single color attachment, and the composition step will just use that one to create the final contents of the window (instead of using multiple draw buffers). OTOH, QGLWidget has its own surface, its own OpenGL context, and hence its own OpenGL settings) and draws directly to the screen. This allows you to have _almost_ full control over its OpenGL rendering, and to easily have multiple draw buffers for stereo/quad rendering. For cases like this one, the direct upgrade path from QGLWidget is NOT QOpenGLWidget, but QWindow+QOpenGLContext (or the QOpenGLWindow convenience, etc.) + QWidget::createWindowContainer. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
Il 09/12/19 14:27, Roland Hughes ha scritto: Gosh no. I'm more stunned that only one person got it. That was an incredibly well written post. Everyone should read it. Too many QML users I guess. auto will be removed though. A bad idea that cannot be fixed. So were trigraphs and digraphs. There is a dramatic falsehood behind the philosophy of always using the latest and "coolest" language "features" because they get removed. How many are compiling code forcing c++11 with deprecation warnings turned off because they have a big codebase using std:auto_ptr. The same will happen to auto. A bad idea that can't be fixed. For being an apologetic email about the deliberate spread of bullshit, this message contains an abysmal number of sentences containing "I'm sorry" or "I apologize". -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Hi, Il 06/12/19 10:48, Dmitriy Purgin ha scritto: Hi Giuseppe, > This trick is used in several places in Qt itself (look for "includemoc" > in commits). Not only it helps build times but also it produces slightly > better code overall. Could you please elaborate what exactly do you mean under 'better code'? How does including the xxx_moc.cpp affect the code generation by moc? If moc decides to generate a better code when included explicitly in a cpp file, why can't it generate the same better code otherwise? Is there a technical reason for it? Sorry, not the code generated by moc -- the code generated by the compiler/linker. See e.g. here: https://codereview.qt-project.org/c/qt/qtbase/+/152423 HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Tricks to improve moc performance?
Il 06/12/19 09:42, Uwe Rathmann ha scritto: Something you can try is to include the moc file at the end of your cpp file. This can be done like this: #include "moc_XYZ.cpp" This type of construction is at least supported by qmake. This does not reduce the number of moc runs, but it reduces the number of compiler runs. As a rule of thumb for not too large classes I would expect, that ~50% of the compile time is spent inside the Qt headers and by including the moc file the overall compile time goes down by 33% as the headers need to be processed only once. This trick is used in several places in Qt itself (look for "includemoc" in commits). Not only it helps build times but also it produces slightly better code overall. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
Il 05/12/19 00:54, Thiago Macieira ha scritto:
Same issue (dangling pointer), no "auto" required.
Or
QStringView f() {
QString s("hello");
return s;
}
Or even
QVector v;
v << QString("world");
etc.
Really, one can build countless examples where Modern C++ will gladly
make you shoot in your own foot...
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Klocwork errors in Qt
Hi, Il 04/12/19 13:56, Christian Gagneraud ha scritto: On Wed, 4 Dec 2019 at 19:28, Giuseppe D'Angelo via Interest wrote: Il 04/12/19 02:36, Christian Gagneraud ha scritto: BTW, Clazy has a check for that very specific case, which just show how dangerous is this QStringBuilder. https://github.com/KDE/clazy/blob/master/docs/checks/README-auto-unexpected-qstringbuilder.md As a professional developer, one should strive for keeping a codebase under clazy, clang-tidy, and friends; and always be under -Werror. Really? (sarcasm) There's what you wish, and there's what you're asked (or allowed) to do. Another set of orthogonal concepts... We don't seem to live in the same world. Let me elaborate: the original claim was that QStringBuilder is dangerous. It's not (*). The danger can only happen as a misuse of it and it's not inherent to QStringBuilder itself, just like other countless things in C++ (e.g. returning a reference to a local variable). Yes, this particular danger is easy to trigger (store the result of a concatenation under QSB in a variable declared `auto`, more than reasonably expecting a QString result). On the other hand, we have tooling that can statically detect the mistake (just like compilers today will flag the returning a reference to a local variable). Now, I do get the argument that not everyone has the chance of using such tooling, for valid reasons (e.g. big codebase not portable under Clang, etc.). And there are surely costs associated at doing the work of making the code compile under different compilers, setting up a CI, integrating it with a code review tool, and so on. My counter-argument is: there are also costs associated at *not* doing the above. *Not* using static analysis tools costs something, just like not using sanitizers costs something (valgrind isn't exactly fast), just like not using C++17 (or 14, or 11!) costs something. In the specific case, the costs are, for instance: * the cognitive load of remembering not to use `auto` together with QStringBuilder (not to mention, the cognitive load of understanding what's the problem in the first place); * the fact that one has specifically to look for it in a code review; * the time spent debugging and fixing random crashes happening in some codepath due to triggering this bad QStringBuilder behavior; * the spread of "fake news" about Qt / QString / C++ / auto / whatnot, e.g. blaming them for hard-to-diagnose and easy-to-introduce bugs; ** ... and of course the time spent debunking some of these "fake news"; * the fact that the code runs slower than necessary because it's not being compiled using QStringBuilder unconditionally. All of this can be avoided, today, by using a tool that immediately picks on the usage of `auto` and tells you "please use explicitly QString here". Now, I can't put a figure on the costs above, of course. I'd say that, in the long run, the costs of *not* using as much tooling available as possible, the latest standards, etc. will be more than doing the necessary work to enable their usage and use them (and keep them enabled). In other words, there is a trade-off somewhere, with a tipping point. Typically, C++ applications are not made to last 6-12 months and then be thrown out and rewritten. C++ projects are, typically, long-running. Hence, I am not so sure of how many projects are actually still on the "don't use tooling" side of the tipping point. C++ is not an easy language. It comes with an *immense* cognitive burden. We cannot know everything, and be 100% focused, for every single line of code we write or review. We need _great_ tooling to detect as much as possible before the code ends up committed, if not in production. Only the tooling can save us from the complexity of C++. (*) I would also add: QStringBuilder should actually be enabled by all projects, by default, just like it's enabled inside Qt itself (libraries, Qt Creator, etc.). There's no reason for paying for N memory allocations instead of 1, when possible, and any codebase I've ever seen will try and concatenate more than 2 strings together somewhere. I wish there was a super-define in Qt that would enable all the "goodies" currently under individual defines: QT_USE_STRINGBUILDER, QT_NO_CAST_FROM_ASCII, QT_STRICT_ITERATORS, and the like. There are no excuses for not fixing mistakes that tooling can detect. Stop being patronising please. You're not helping. I was not patronizing. Please see the reasoning above. The authors of C++ tooling (compilers, static analyzers, linters, sanitizers, fuzzers, ...) do a tremendous effort to help us build (harder,) better, faster, stronger applications by detecting as many potential mistakes as possible; possibly, at compile time. Every time a compiler flags a warning in our code, please remember that someone somewhere had to add that warning to some tool, write the c
Re: [Interest] Klocwork errors in Qt
Il 04/12/19 02:36, Christian Gagneraud ha scritto: BTW, Clazy has a check for that very specific case, which just show how dangerous is this QStringBuilder. https://github.com/KDE/clazy/blob/master/docs/checks/README-auto-unexpected-qstringbuilder.md As a professional developer, one should strive for keeping a codebase under clazy, clang-tidy, and friends; and always be under -Werror. There are no excuses for not fixing mistakes that tooling can detect. Hence, this problem isn't actually a big deal at all (or: it isn't any more, since we have clazy). It falls into the general category of "ways C++ lets you shoot in your own foot", which is a much broad discussion. Kudos to Sérgio, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSpinbox repeat delay
Il 03/12/19 21:07, Murphy, Sean ha scritto: When using a QSpinBox, if the user clicks and holds on one of the up/down buttons (or uses one of the keyboard keys that do the same thing), there is a bit of a delay before the autorepeat functionality starts. Is there a spot to query what that delay is and/or change it? From trial and error it appears it is ~500 ms on Windows, but there doesn't seem to be a way to control it. As with any similar widget platform-specific behavior, specifically by the SH_SpinBox_ClickAutoRepeatThreshold style hint. Use spinbox->style()->styleHint to fetch the value; use a custom style or a proxy style to change it. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QListView moveRow() from model not called
Il 01/12/19 23:07, Martin Marmsoler ha scritto: Why moveRows() is not called? Because moveRows was added in Qt 5.x, and drag and drop in Qt 4, and still uses insert+remove for backwards compatibility. Not the answer you were probably looking for... My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Most simple emit from singleton?
On 13/11/2019 18:11, Jason H wrote: Maybe. Couldn't I just call: MySingleton::Instance()->MySignal(); and skip emit altogether? I've read that Q_EMIT and emit are just syntactic sugar, and there is confusion in this stackexchange: https://stackoverflow.com/questions/10160476/using-emit-vs-calling-a-signal-as-if-its-a-regular-function-in-qt it seems that the simplest way is just: MySingleton::Instance()->MySignal(); but to make it clear it is emitting, the sugar comes into play. Not sure if it has any affect on queued vs direct-call connections though. (I'm guessing no) "emit" / "Q_EMIT" are macros that expand to nothing. Therefore, after the preprocessor runs, the compiler does not see anything; whether emit was there or not makes no difference and thus results in no behavioral changes. Still: 1) use emit every time you emit a signal; emit is not there for the compiler, it's there for the developer 2) use emit ONLY in front a signal emission and nowhere else 3) While signals are technically public members, I'd consider that an implementation detail; one should NEVER be emitting signals on behalf of another arbitrary class. You should protect your signal emissions, e.g. use the same undocumented trick that Qt uses (make them have an argument of type QPrivateSignal), and give friendship to the only codepaths that are supposed to emit it (and, even better, have a trampoline function that emits the signal that these codepaths can call). Clazy already checks for 1+2 and in theory can also check for 3. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QImage::copy threadsafe?
Il 09/11/19 20:01, maitai ha scritto: I'll try to make a copy, I am reluctant because I must be very careful with memory and time to copy. As I said, the copies will be shallow copies, very cheap to make (they're just increases of a reference counter). The fact that the payload is actually shared amongst the copies _is_ an implementation detail: QImage is guaranteed to be reentrant, and you're acting on different objects, so you're honouring the contract. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QImage::copy threadsafe?
Hi, On 08/11/2019 18:33, maitai wrote: All is in the tile, is QImage::copy threadsafe? The method is const but is it enough? Documentation does not state it is thread safe so I am wondering. My case is I have a QImage loaded in the main thread, and many many threads that keep extracting small rectangles from it using QImage::copy. No other operations occur on the QImage once loaded. The short story is that const methods on Qt value classes are generally thread safe. The exceptions are very very few (e.g. QString::utf16). I don't believe this is guaranteed anywhere in the documentation, though. If you can live with the "implementation guarantee" then, by all means, just use copy() from multiple threads. On the other hand, you could just create copies of the image and give them out to each worker thread. Copying a QImage is very cheap (it's implicitly shared so it won't deep copy the data anyhow). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Help, I'm in QML signal hell
Il 01/11/19 17:42, Jason H ha scritto: I am using signals/slots in QML and the signal emissions are getting inverted. Here's my example: bool Socket::emitSignalForOp(const QByteArray &) "STF10" 10 bool Socket::emitSignalForOp(const QByteArray &) "PSF09" 11 STF10 necessarily comes after PSF09. In wall-clock time it does. But Qt is not getting the order right. The number above is the signal emission number, so it's not a display issue. You need to share more about your code. Just a word of caution: if we're talking about multithreaded code, "wall clock time" does simply not exist. Threads are relativistic... My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QGraphicsObject::boundingRect() called with different instance
Il 31/10/19 01:55, Bob Hood ha scritto: I'm on Windows using Qt Creator 4.6.2. Apart from MSVC working on porting ASAN, there's a memory error detector available as part of Intel Studio. To me, valgrind/ASAN is still a _huge_ reason to prefer Linux development. If you can, get a testcase and run it in a Linux VM under valgrind/ASAN. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QGraphicsObject::boundingRect() called with different instance
On 30/10/2019 01:47, Bob Hood wrote: When I enter the constructor, I have a specific ‘this’ pointer that has the provided ‘size’ argument placed into its ‘entity_size’ member. However, when Qt subsequently invokes the boundingRect() override function, it’s an entirely different ‘this’ instance whose ‘entity_size’ has clearly not been initialized. I’ve looked at several select examples/widgets/graphicsview/ sources, and those show that this should be working as expected. I’ve tested this with 5.11.1 and 5.12.3 with the same result, so I’m guessing this is some kind of pilot error on my part. Did you already run this code into valgrind / ASAN? HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QUdpSocket, QNetworkDatagram and QNetworkInterface
Il 30/10/19 10:42, Nuno Santos ha scritto: My local network has the main modem, which is connected to the internet. Then, there is an older wifi router from linksys only serving as a cable lan switch. Do you have a clue why is this happening? This is completely ruining the previsibility I was expecting to have. Smells like the router is doing NAT. Is the other machine behind the same linksys router, or still in your local network, or on the internet? HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Change in open-source licensing of Qt Wayland Compositor, Qt Application Manager and Qt PDF
Hi Lars, Il 16/10/19 15:13, Lars Knoll ha scritto: As it turned out, there was some miscommunication that happened regarding the re-licensing of Qt PDF, and not all contributors were on board regarding the license change. That means we’re not changing the modules license and won’t be adding it to become a supported part of Qt until this has been sorted out. Could it be possible to amend the blog post linked by Tuukka in the original email https://www.qt.io/blog/change-in-open-source-licensing-of-qt-wayland-compositor-qt-application-manager-and-qt-pdf to reflect this new condition? Blogposts are way more easily found by search engines rather than entries in this mailing list... Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Strange issue with Qt, OpenGL and remote desktop
Il 25/10/19 08:56, Rainer Wiesenfarth ha scritto: This is (still) QGL..., we have not yet switched to the QOpenGL... classes. Ok, so, to test if my random guess is remotely correct: get your QGLContext and connect to ctx->contextHandle()'s signal called aboutToBeDestroyed (i.e. check if that is getting called before problems appear). It's really a lick-finger-in-the-air kind of guess... HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Strange issue with Qt, OpenGL and remote desktop
Il 24/10/19 17:57, Rainer Wiesenfarth ha scritto: We ran into a reproducible crash that is restricted to a certain scenario. The crash occurs in QGlContextPrivate::syncGlState() when trying to call glDisableVertexAttribArray(). It seems the function pointer is not available. However, there are some other factors involved: Very wild guess, maybe remote desktop is somehow issuing a GL context reset, and the code in question is not prepared to handle it? (Are we talking about QGL* classes here or QOpenGL* classes?) HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] copying the object in the delegate
Hi,
Il 19/10/19 23:48, Dirk Hohndel ha scritto:
That is of course ridiculously inefficient. Even ignoring the issue on my
side that forces me to run the constructor every time the data() function
is called, it seems silly to not just be able to have a local copy of that
object for the delegate QML object which then accesses the members of that
object without calling back to the underlying model.
Is there a way to do that and I just didn't find it when looking?
Note that, in general, a model's data() function is expected to be
seriously hammered by a view. In Qt's model/view architecture, views and
delegates don't cache anything. (This is brought quite to the extreme:
it's not uncommon to see hundreds if not thousands of calls to data()
from a widgets view simply by moving the mouse cursor over it.)
If there's need of caching because accessing the data is "slow", for any
measure of slow, then this caching belongs to the model (or to the
user's own delegates/views).
Thus, the way I see it, you have two options:
1) Add some caching to your model's data(), e.g. a very simple LRU cache
of a reasonably small size, as proposed in the earlier reply.
2) Given that in QML you write the delegates yourself, maybe instead of
using something like:
delegate: MyDelegate {
propA: model.role.fieldA
propB: model.role.fieldB
// etc
}
which will likely cause multiple calls to data() for the rolename "role"
for the same delegate instance, did you try something like this?
delegate: MyDelegate {
readonly property QtObject myObject: model.role // or, "var"
propA: myObject.fieldA
propB: myObject.fieldB
// etc.
}
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] TLS/SSL XML encryption security
Il 19/10/19 14:35, Roland Hughes ha scritto: Actually it is of immense interest and value to the hundreds, perhaps thousands of Qt developers currently working on autonomous vehicles and attempting to integrate that with current infotainment systems. What's of little to no value are discussions of QML, JavaScript and iDiot Phone apps. How about you just ignore such discussions, and maybe also stop insulting people working in those markets? What we really need here are two interest lists. qt-interest-qml-javascript-and-idiot-phones qt-interest-things-which-actually-matter What we need is fewer completely delusional and off-topic threads. On the latter is where Qt can be discussed along with the architecture required for embedded systems which are either making human lives better or will have human lives entrusted to them. Surgical robots and other medical devices Which are being built with QML: https://www.qt.io/medec-built-with-qt Train/rail control systems Which are being built with QML: https://www.qt.io/ulstein-built-with-qt autonomous vehicles and infotainment systems Which are being built with QML: https://resources.qt.io/customer-stories-automotive/qt-testimonial-mbition-michael-chayka scientific test equipment, water purification control systems and all other manner of embedded control systems. Which are being built with QML: https://www.qt.io/bosch-built-with-qt The only time QML and/or JavaScript ever appears in that universe is when management is incompetent beyond description. STOP INSULTING PEOPLE. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Attribute Qt::AA_UseOpenGLES must be set before QCoreApplication is created.
Il 18/10/19 11:28, Thomas Sevaldrud ha scritto: I doesn't actually appear to have any negative consequences. Everything works as before, but our users are complaining about the warning :) The reason that these attributes are set after creating the QApplication is that I have a fallback system where I can try for software rendering if the ANGLE setup fails for some reason (crappy drivers, etc). So if my GLContext with AA_UseOpenGLES fails, I try again with AA_UseSoftwareOpenGL. This also appears to work nicely. The principle is that once Qt "thinks" you are using Desktop GL, setting that attribute may or may not make it switch over to ANGLE, and vice versa. In other words there comes a point in time after which setting the attribute becomes meaningless (in the specific case: typically after the first GL context has been created, but this is undocumented and should not be relied upon). What Qt is warning about is that you're touching a setting that may or may not have any effect (depending on the OS, what you did so far in the application, which modules of Qt you're using, the day of the week, the moon phase), so don't it. What you could maybe do is to create a Q(Gui)Application, do your tests to detect which GL way to use, and if you need to switch to ANGLE or software then 1) destroy the QGuiApplication object 2) set all the attributes you need 3) create QGuiApplication again and proceed (Or, similarly: save some settings and restart the application with the new settings) I don't actually use the QApplication for anything, I'm only using Qt as a GL wrapper with no QML, Gui, Network or anything. So I tried to simply remove the QGuiApplication, but then it crashes during QOpenGLContext::create(), so I guess it needs to exist after all. Touching any and I mean any GUI class requires a QGuiApplication object, anything else is not supported (and will likely crash). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing questions for iOS and Android
Il 08/10/19 10:24, Yves Maurischat ha scritto: I dont think that you'll get a definitive answer from this list as The other side of the coin: this list is NOT for sales or detailed licensing questions. It's about technical questions related to the usage of Qt (and, specifically, the parts of it released by the Qt Project, not the Qt commercial-only addons). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
Il 07/10/19 07:55, Uwe Rathmann ha scritto: Ah yes, sorry. My response was initially more explicit about FUD, before I decided, that it is not worth the effort. Huh? It was not my intention to spread FUD. I'm not telling anyone "buy a license, you never know..." or "stick to LGPL, don't worry about paid licenses, you don't need them". I'm actually trying to tell the opposite -- remove the all uncertainty from your specific use case, by getting an informed opinion by someone protecting your interests. (No, I don't get a % from law firms. :-P) HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
Il 06/10/19 11:56, Uwe Rathmann ha scritto: Maybe this presentation helps: https://www.youtube.com/watch?v=bwTlCBbB3RY Hey, I linked it two emails ago :-) -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Licensing
Hi, Il 05/10/19 19:19, Jérôme Godbout ha scritto: This is the true problem: when you need a lawyer, a sale rep and Qt support just to determine what you should do or buy, you know this is one hell of a brain f*** problem. I think Qt might just be missing sales because of this. Make it clear, make it obvious what people should buy or make a package with a displayed price point. I'm sure many just use Qt and try as hard as they can to be legit but at some point just gave up and say "screw this, let's use the free and hope nobody see it". We want transparency on this matter one day. I have some project moving away of Qt just because we are unsure if this a valid use case and the client doesn't have the time nor the resource for lawyer wasted money. I get your frustration, but please don't mix the topics: 1) YOU need a lawyer to protect YOUR OWN interests. Licensing is a legal topic, which makes it a minefield (depends on the country/legal system, your particular domain, how all the licenses you're using interact with each other, what certifications mandate, etc.). Licenses like GPL/LGPL are also particularly tricky because they carry many obligations. Therefore, any pre-made answer is not usable; and that's why everyone insists on answering "please have an expert look at your case and give you their opinion". While you may get a rough idea of what's going on from online forums and videos, are you willing to bet your business strategy and/or expose yourself to lawsuits, instead of paying a firm to give you advice? (I don't know anyone offering comprehensive legal advice for free. Note also that in some countries a hired lawyer that gives you blatantly wrong advice can be sued for gross incompetence.) To state the obvious: of course it's in Qt sales interests to sell you Qt licenses, NOT to give you such advice. In Italy we say something like "don't ask the innkeeper if the wine they serve is good". Qt sales protect Qt interests, not yours. To state the less obvious (?): you're building a product for whose success Qt is a necessary component. Assuming you'll need to continue sell and support this product for the foreseeable future, buying licenses can therefore be considered a strategic investment for you -- you want/need to keep Qt alive. 2) The actual licensing prices and schemes are not public. Even the actual wording of the commercial licenses are not public, AFAIK. It's a business decision. It can be questioned, like all such decisions. But note that you need someone anyhow to have a look at the commercial license text and tell you what it implies for you. Possibly, someone that protects your interests (= your lawyer), and we're back to square one. 3) I'm not sure what the Qt (technical) support has to do with this, to be honest. Anyhow: please direct these comments to your Qt sales representative; this is NOT a sales mailing list (in other words, chances are high that no one from sales ever reads these messages). This is a mailing list of the Qt Project. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TLS/SSL XML encryption security
Il 05/10/19 02:17, Roland Hughes ha scritto: Sorry, I need to invert the quoted message so answers make sense. On 10/3/19 5:00 AM, Matthew Woehlke wrote: On 01/10/2019 20.47, Roland Hughes wrote: If they targeted something which uses XML documents to communicate, they don't need to brute force attempt everything, just the first 120 or so bytes of each packet until they find the one which returns That seems like a flaw in the encryption algorithm. It seems like there ought to be a way to make it so that you can't decrypt only part of a message. Even an initial, reversible step such as XOR-permuting the message with some well-known image of itself (e.g. "reversed") might suffice? Of course! Everyone in charge of security at Google, Amazon, Apple, Facebook, Microsoft is a complete moron and didn't think of this already, as they're happily sending plain XML and JSON from their servers! Or maybe it has to do with the fact that modern encryption algorithms are designed to be resilient against these attacks, so there is no point at obfuscating the data you're sending? I'm really not sure. I'll go with "everyone else is a complete moron". Not a flaw in the algorithm, just seems to be a flaw in the communications. This isn't partially decrypting a packet. It is encrypting every possible combination of key+algo supported by TLS/SSL into a fingerprint database. You then use a sliding window of the fingerprint size performing keyed hits against the fingerprint database. You "dust for prints." Sure; there are (at most) ~10^80 =~ 2^266 atoms in the observable universe. So you need roughly ALL THE MATTER IN THE UNIVERSE to store every possible combination of 256 bit keys+algorithms into a fingerprint database. To really secure transmitted data, you cannot use an open standard which has readily identifiable fields. Companies needing great security are moving to proprietary record layouts containing binary data. Not a "classic" record layout with contiguous fields, but a scattered layout placing single field bytes all over the place. For the "free text" portions like name and address not only in reverse byte order, but performing a translate under mask first. Object Oriented languages have a bit of trouble operating in this world but older 3GLs where one can have multiple record types/structures mapped to a single buffer (think a union of packed structures in C) can process this data rather quickly. How is this not just "security through obscurity"? That's almost universally regarded as equivalent to "no security at all". If you're going to claim that this is suddenly not the case, you'd best have some *really* impressive evidence to back it up. Put differently, how is this different from just throwing another layer of encry^Wenciphering on your data and calling it a day? It's not. It's security by obscurity. I'll grant it may be a legitimate use of obfuscation, which of course doesn't work ALONE -- it works when the rest of your stack is also secure. And in the case of TLS/SSL, the rest of the stack is secure WITHOUT using security by obscurity. Well, first we have to shred some marketing fraud which has been in existence for a very long time. https://en.wikipedia.org/wiki/Security_through_obscurity "Security through obscurity (or security by obscurity) is the reliance in security engineering on design or implementation secrecy as the main method of providing security to a system or component." I wonder if Gartner was paid to market this fraud. They've certainly marketed some whoppers in their day. Back in the 90s declaring Microsoft Windows an "open" platform when it was one of the most proprietary systems on the market. Can't believe nobody went to prison over that. At any rate the peddlers of encryption have been spewing this line. In fact this line is much truer than the peddlers of encryption wish to admit. When you press them on it they are forced to perform a "Look at the Grouse" routine. https://www.youtube.com/watch?v=493jZunIooI _ALL_ electronic encryption is security by obscurity. Take a moment and let that sink in because it is fact. "Let that sink in" is the official "I've just told you a very very appealing lie/logical fallacy/... and I don't want to get caught". Your "secrecy" is the key+algorithm combination. When that secret is learned you are no longer secure. People lull themselves into a false sense of security regurgitating another Urban Legend. *JUST THE KEY*. Every other part of the system (SSL version, key derivation algorithms, encryption algorithms, etc.) can be known, and the system still be secure. The secret key is an input of the system, and NOT part of its design (which is standardized) or the implementation (which can be open source and thus examinable), which therefore doesn't make it (according to your own quote) security by obscurity. "It would take a super computer N years running flat out to break this
Re: [Interest] Licensing
Hi, Il 05/10/19 13:17, Colin Worth ha scritto: My company has developed embedded and cross-platform GUI software using free open-source QT, the latest version. We are using the libraries that are included with the standard open-source installation. Soon we will freeze the version number, because we need to go through the FDA certification process. The software will be included with a medical device and we may also develop a sub-project that can be sold directly to consumers (its a medical device for amputees) Can someone briefly summarize our options as far as licensing (I have already read and googled many links, read through license terms, etc., even including a suggestion that we need to hire a lawyer, but this seems like a pretty straightforward question.) 1) Are we free to sell and distribute the software with our product, or as a download, as long as we dynamically link to the Qt libraries (as happens automatically when deploying with mac/windeployqt). Do we need to post any part of our source code online? Unfortunately it IS a question for your own lawyers. The point is that you need an authoritative answer from an IP specialist operating in your country, with knowledge about your specific domain. Note that you said "open source" Qt, which is meaningless -- different parts of Qt are covered by different open source licensing schemes (LGPL3, GPL2/3, LGPL2, ...), that carry very very very different obligations. You need to audit your source and figure out which ones you're actually using. The same thing applies for any other 3rd party library you are using. And while a license like LGPL3 doesn't mandate publishing the source code of the application linked against a LGPL3 library, it *still* puts further constraints on such an application, that may or may not be fine with you. There is a number of online videos that might help at getting a rough idea about whether you'd be fine at using an open source license, but I cannot stress this enough: they're *not* authoritative answers for your *specific* case, and you shouldn't risk your entire business strategy based on what a complete stranger said on the Internet! https://www.youtube.com/watch?v=bwTlCBbB3RY https://www.youtube.com/watch?v=lSYDWnsfWUk 2) If not, how much does commercial licensing cost, not for ongoing development, but just to include Qt with a product, or would that be determined on a case-by-case basis with the QT company. The quotes are not public; this is a question for your own Qt Sales representative. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CPU load in busy indicator widget based on Q(Variant)Animation
Il 04/10/19 16:51, René J.V. Bertin ha scritto: I've isolated the class and its demonstrator, and added a few switches to assess performance (in terms of user experience and CPU load). The only way I found to limit the CPU load is by adding a delay after each frame render. 75ms of "thread sleep" already causes an almost 4x reduction in CPU load with a barely visible effect; with 250ms the animation is choppyish but still perfectly acceptable IMHO - and CPU load < 1%. github.com/RJVB/kbusygadget Am I being principled here or are there indeed cheaper ways to obtain a comparable UI effect? By default non-QQ2 related animations run every 16ms. Do you have a minimal testcase showcasing a suspicious activity of an animation? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QPainter drawLine zValue?
Il 25/09/19 19:13, Israel Brewster ha scritto: Is there a way to set the Z value of the line drawn by the QPainter::DrawLine() function? I have a library that uses the drawLine function to create a grid, and I would like to keep the grid on the top as I draw other things, if possible. Thanks. Can you draw the grid _last_? There's no Z value (or Z buffer altogether) for QPainter. A new drawX command draws directly to the target, honouring the composition mode for blending source and destination together. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Remove limitation of writing large qjson - QJson: Document too large to store in data structure
Il 22/09/19 19:31, Tharindu Mathew ha scritto: I'm attempting to write a large json file >1GB. My hardware is comfortably capable of handling this. It seems qt doesn't like to write large json files. Is there an option I can set to remove this limitation? I'm using Qt 5.11 on Windows 10 x64. This is a known limitation of QJson* classes, see https://bugreports.qt.io/browse/QTBUG-47629 HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Assertions from QQuickTableView::forceLayout()
Il 21/09/19 05:40, Patrick Stinson ha scritto: In many cases this assertion happens when TableView.rows is out of sync with model.rowCount(), or TableView.columns is out of sync with model.columnCount(). The fact that these are out of sync at all seems to me to be a bug? Do you have a minimal testcase? (E.g. a minimal custom model that is shown in a TableView, and that causes the assert). That would be enough to open a bugreport. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QByteArray vs QString, arg, why is there no arg()?
Il 18/09/19 13:16, Jason H ha scritto:
What's the best way to zero-pad a QByteArray?
What I want is QByteArray("%1").arg(6, 10, 10, '0')
Mostly it has to do with the fact that QByteArray is sitting between two
worlds; on one side it's just a container of bytes, on the other side it
has _some_ manipulation functions for ASCII-like strings. "Some"
because, as you've noticed, stuff like the arg() convenience is missing.
If you really need a QByteArray you can work around this by e.g. using a
printf-like function, what you're looking for is the "%010d" formatting.
Pseudocode:
int n = 123;
const char *format = "The number is %010d";
auto size = qsnprintf(nullptr, 0, format, n);
QByteArray result(size, Qt::uninitialized);
qsnprintf(result.data(), result.size(), format, n);
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
On 16/09/2019 18:51, Roland Hughes wrote: On 9/16/19 10:41 AM, Giuseppe D'Angelo wrote: On 16/09/2019 14:44, Roland Hughes wrote: On 9/16/19 5:00 AM,interest-requ...@qt-project.org wrote: Il 14/09/19 14:53, Roland Hughes ha scritto: Please keep in mind there is no version of SSL which is secure. Do you have any reference/source for this (quite extraordinary) claim? You know, for you it wouldn't matter. It would be a link and you are incapable of actually clicking then reading anything which doesn't support your opinion. So, personal insults right off the bat? Not insults, factual history. You've even flamed about links in messages in this very thread. There are numerous packages on the market which cut through SSL like a hot knife through butter. Any link to ANY of those? This is the leg work __you__ should be doing before writing your first line of code and before making any claim that SSL is secure. It doesn't work like this. YOU made the claim that SSL is not secure. Specifically, that it's as secure as hanging a CLOSED sign on the unlocked door to a jewelry store having $20 million in inventory sitting in the cases without an alarm system. So YOU now have to provide the references to support that claim. https://techxplore.com/news/2019-03-cybersecurity-dark-web-exposes-vulnerability.html Actual report the article is based on https://www.venafi.com/sites/default/files/2019-02/Dark-Web-WP.pdf This is exclusively about PKIs. It doesn't show any breach whatsoever of SSL. Here's some historical ones from Cisco. A bit dated but shows just how thriving successful attacks have been through SSL. https://blogs.cisco.com/security/breach-crime-and-blackhat This actually puts SSL in a positive light, showing only THREE attacks against it. At least RFC 7457 shows more. More https://www.semrush.com/blog/https-a-modern-false-sense-of-security And this again just mentions that earlier SSL versions had security vulnerabilities. It does not sustain the claim that there is NO version which is secure. (As Thiago has already reminded, we're way past the point where we do get to prove mathematically the correctness and the security of our code; instead we rely on expert research, responsible disclosure and quick fix of any issue that may have been found.) "60 Minutes" did a piece on the best known and most financially successful one but some sources say there are around a dozen packages playing at the same level. Here's the link which was provided before and I'm sure you didn't bother to follow prior to responding. https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/ The link does not talk about breaking SSL. The link is about spyware for smartphones. SSL is actually never mentioned, not to mention of course breaking it. One of the primary ways it does it is by breaching SSL which is the easiest entry point. The second entry point is via that little bot/virus/malware/whatever-called-this-week they attach to the phishing email. Where exactly in the video is "breaching SSL" stated? This is pure speculation, and very likely to be false too (you don't need to breach SSL to plant malware. You don't even need SSL in the first place!). Please also keep in mind the big systems are moving towards a TCP/IP software appliance within the OS. No application will be able to create or open a port. No application will be able to choose/define the transport layer security. They will open a logical-resource-handle provided by the OS and the systems manager will configure if that resource is I, O, or I/O as well as what the transport level protocols are. Eventually (within 5 years of adoption) this will be forced out into the IoT and lesser devices world as well. So long for the "backward compatibility is paramount" promise then. That would only be for the hokey code which came from the *nix world. And Windows. which took it from the *nix world if memory serves. For the code which didn't come from a world that did it wrong it is 100% backwardly compatible because that is exactly how we did network communications. In other words all of the software developed_on_ those platforms and_for_ those platforms will be fine. What will be going away are the *nix TCP/IP library functions of C/C++ because they are a massive security nightmare. There was a time when marketing bowed to the pressure from companies which only wanted "free" software on their million plus dollar platform, but that has lead to security catastrophe after security catastrophe. Now they are in the process of locking them back down and just letting people whine an snivel about *nix package not being available on the platform. So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e. roughly about 0% of the current market share of Qt. What are Qt users (the people who read this very mailing list)
Re: [Interest] mac app crashes if you plug in another monitor
Hi, On 13/09/2019 16:49, David M. Cotter wrote: this seems unexpected Not a mac user myself, but if you have a minimal testcase, please consider submitting a bug report. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 96, Issue 17
On 16/09/2019 14:44, Roland Hughes wrote: On 9/16/19 5:00 AM, interest-requ...@qt-project.org wrote: Il 14/09/19 14:53, Roland Hughes ha scritto: Please keep in mind there is no version of SSL which is secure. Do you have any reference/source for this (quite extraordinary) claim? You know, for you it wouldn't matter. It would be a link and you are incapable of actually clicking then reading anything which doesn't support your opinion. So, personal insults right off the bat? There are numerous packages on the market which cut through SSL like a hot knife through butter. Any link to ANY of those? "60 Minutes" did a piece on the best known and most financially successful one but some sources say there are around a dozen packages playing at the same level. Here's the link which was provided before and I'm sure you didn't bother to follow prior to responding. https://www.cbsnews.com/news/interview-with-ceo-of-nso-group-spyware-maker-fighting-terror-khashoggi-murder-and-saudi-arabia-60-minutes-2019-08-18/ The link does not talk about breaking SSL. The link is about spyware for smartphones. SSL is actually never mentioned, not to mention of course breaking it. I'll reinstate: where is the evidence supporting the claim that "there is no version of SSL which is secure"? This is a super-strong claim on a mailing list read by Qt users, who are using SSL in their products, who are relying on Qt to do the right thing when it comes to security technologies (and Qt offers SSL-related facilities). Please also keep in mind the big systems are moving towards a TCP/IP software appliance within the OS. No application will be able to create or open a port. No application will be able to choose/define the transport layer security. They will open a logical-resource-handle provided by the OS and the systems manager will configure if that resource is I, O, or I/O as well as what the transport level protocols are. Eventually (within 5 years of adoption) this will be forced out into the IoT and lesser devices world as well. So long for the "backward compatibility is paramount" promise then. That would only be for the hokey code which came from the *nix world. And Windows. For the code which didn't come from a world that did it wrong it is 100% backwardly compatible because that is exactly how we did network communications. In other words all of the software developed _on_ those platforms and _for_ those platforms will be fine. What will be going away are the *nix TCP/IP library functions of C/C++ because they are a massive security nightmare. There was a time when marketing bowed to the pressure from companies which only wanted "free" software on their million plus dollar platform, but that has lead to security catastrophe after security catastrophe. Now they are in the process of locking them back down and just letting people whine an snivel about *nix package not being available on the platform. So we're talking about non-Unix, non-Windows, non-Apple platforms. I.e. roughly about 0% of the current market share of Qt. What are Qt users (the people who read this very mailing list) going to do with this useless information? -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
Il 14/09/19 14:53, Roland Hughes ha scritto: Please keep in mind there is no version of SSL which is secure. Do you have any reference/source for this (quite extraordinary) claim? Please also keep in mind the big systems are moving towards a TCP/IP software appliance within the OS. No application will be able to create or open a port. No application will be able to choose/define the transport layer security. They will open a logical-resource-handle provided by the OS and the systems manager will configure if that resource is I, O, or I/O as well as what the transport level protocols are. Eventually (within 5 years of adoption) this will be forced out into the IoT and lesser devices world as well. So long for the "backward compatibility is paramount" promise then. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML and sensitive data
Il 10/09/19 15:44, Uwe Rathmann ha scritto: PS: could someone in charge of this mailinglist please have a look at the spam filter ? See https://bugreports.qt.io/browse/QTQAINFRA-3072 Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML and sensitive data
Il 05/09/19 14:28, Roland Hughes ha scritto: The best solution would be to use Widgets. A QLineEdit is just as secure as an equivalent QML control (which means, it's not secure). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Click and hold on close button
Il 27/08/19 20:09, Murphy, Sean ha scritto: I've attached a sample application below that can be used to test. When you build and launch it, a QLabel blinks between green and "normal", switching palettes every second. On Windows, if you click and hold on any of those 3 buttons, and while holding the mouse, move off the original button so that the release event doesn't happen on the same button, the blinking will cease the entire time you have the button pressed. Do the same thing on Linux and the QLabel keeps blinking happily the entire time. Please put aside the "conspiracy theories". The very simple reason that the event loop blocks is that Qt doesn't know what to do with that event, and it ends up calling DefWindowProc [1], "the default window procedure to provide default processing for any window messages that an application does not process" [2]. That is a blocking call (!); execution stays in there until the OS knows what to do, which seems to be not until you release the mouse button. If you enable QPA logging in the qt.qpa.events category (e.g. via QT_LOGGING_RULES), and add "verbose" > 2 to your QPA plugin loading (e.g. -platform windows:verbose=2) you'll see the mouse press correctly received by Qt. If also you run your app in a debugger and make it print a stack trace while keeping the mouse pressed on a window decoration button, you'll see the stack trace in there. E.g. C:\> timeout 5 & cdb -p 12345 [timeout trips into the debugger] 0:010> ~* k 0 Id: d90.3334 Suspend: 1 Teb: 0095`0578d000 Unfrozen Child-SP RetAddr Call Site 0095`058fbad8 7ffb`72b44f7a win32u!NtUserMessageCall+0x14 0095`058fbae0 7ffb`72b4470f USER32!RealDefWindowProcWorker+0x1fa 0095`058fbbe0 7ffb`6ecb984e USER32!RealDefWindowProcW+0x4f 0095`058fbc20 7ffb`6ecd24f7 UxTheme!DoMsgDefault+0x2e 0095`058fbc60 7ffb`6ecbc49f UxTheme!OnDwpNcLButtonDown+0xa7 0095`058fbca0 7ffb`6ecbbf81 UxTheme!_ThemeDefWindowProc+0x50f 0095`058fbe80 7ffb`72b44c4f UxTheme!ThemeDefWindowProcW+0x11 0095`058fbec0 7ffb`38488d92 USER32!DefWindowProcW+0x1bf 0095`058fbf30 7ffb`72b4681d qwindowsd!qWindowsWndProc+0x422 0095`058fc170 7ffb`72b46212 USER32!UserCallWinProcCheckWow+0x2bd 0095`058fc300 7ffb`3a30d443 USER32!DispatchMessageWorker+0x1e2 0095`058fc380 7ffb`385524f4 Qt5Cored!QEventDispatcherWin32::processEvents+0x5c3 This also answers why other applications don't freeze -- they must be handling the event internally, keeping their event loops unstuck. For instance, Chromium / Firefox may just be using client-side decorations, and handling clicks on the decoration buttons themselves. (This has nothing to do with the fact that their rendering is out of process, etc.; actually it's highly likely that you need an event loop running in the "main" application, in order to gather the rendering from the other processes.) So why does Qt call into a blocking Win32 API from the main thread? I have absolutely no idea; I'm not a Windows user and I know close to 0 Win32 API programming. Event loop code looks hairy enough, but if anyone knows if there's a "better" way to handle these events, please submit bug reports. [1] https://code.woboq.org/qt5/qtbase/src/plugins/platforms/windows/qwindowscontext.cpp.html#1600 [2] https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-defwindowprocw My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_NAMESPACE is not portable?
On 26/08/2019 18:04, Jason H wrote: "This is useful f.i. if the object needs to be exported from a dynamic library." what's "f.i."? "For instance"? Isn't that "e.g." (but definitely not i.e.) "For instance" / "for example" are precisly the English translations of exempli grati-a... Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_NAMESPACE is not portable?
On 26/08/2019 17:29, Matthew Woehlke wrote: Okay... that's both good and bad news... good that it's fixed, bad that it isn't available in a released version. BTW, what happened to the doc? Macros aren't class members... I'm thinking it's still https://bugreports.qt.io/browse/QTBUG-76822 (Relatedly, any word on lifting the implied dependency on several of these?) I agree in principle at moving these macros elsewhere, didn't *you* push a patch that got stuck just because of documentation issues? :-) Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_NAMESPACE is not portable?
On 24/08/2019 00:10, Matthew Woehlke wrote: Am I doing something wrong, or is it impossible to use Q_NAMESPACE correctly without platform-specific PP conditionals? I've fixed this in 5.14, see https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_NAMESPACE_EXPORT Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Add row to model *with data*?
Il 15/08/19 23:42, Matthew Woehlke ha scritto: Is there any way, with the existing QAbstractItemModel API, to specify the data that the row should contain in the same call that adds the row? Even better, is there any way to ask the model to add a row, with data, but*not* specify where the row is to be added? (The model would then return the new row index, or -1 if it could not complete the operation as requested.) There isn't such an API. Maybe you can fake it via a drop? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt free software policy
Il 15/08/19 11:14, Benjamin TERRIER ha scritto: Also I never asked for anything free here. I am asking if "GPLv3 only" is and will be the standard licensing scheme for new modules made by The Qt Company. I feel that it needs to be made clear, at least so that if an LGPL user need something he knows that he should not expect to have it in a future version of Qt, but should rather contribute it himself ensuring that it will be available under LGPL. I'd say that the decision is always going to be on a module-by-module basis. If you want to read something between the lines wrt TQC's commercial interests, feel free to do so, but that's not the Qt Project's policy. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt free software policy
Il 14/08/19 22:05, Thiago Macieira ha scritto: I don't know if there's anything that is GPL-3.0 (without 2.0). There may be. Quick, incomplete list, from the back of my head: * QtVirtualKeyboard * The WebGL QPA plugin * The WebAssembly QPA plugin * QtCharts are all GPL3 (not 2). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Overriding list properties in QML at initialisation
Il 14/08/19 11:23, Ulf Hermann ha scritto: In the following example, I would expect the list to contain 2 elements instead of 5. What are your thoughts? Should I fill a bug report and try to provide a fix? Yes, that would be nice. Keep in mind that the default property should still behave the old way, but only if you actually use it as default property. The details can be discussed in the report, though. This behaviour cannot be changed in a source-compatible way, so it's a no-go, unless we also add additional C++/QML syntax for opting in to the new behaviour. E.g. the QML APIs for Qt3D massively depend on this. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Is it safe to call qRegisterMetaType() before main()?
Il 31/07/19 23:22, Nikos Chantziaras ha scritto:
static void constructor() __attribute__((constructor));
static void constructor(){
qmlRegisterType("ClassName", 1, 0, "ClassName");
}
Maybe it helps.
Thanks! I didn't know about that one.
You can do that in pure C++, by the way; just define a global object.
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] error: reference to 'byte' is ambiguous with C++17
Il 24/07/19 09:25, Vadim Peretokin ha scritto: I'm compiling my Qt application with C++17 on Windows with the Qt-provided MinGW 7.3.0 and the Qt definition of a byte is conflicting with the new one defined in the standard (http://wg21.link/p0298r3). Here's a snippet of the issue: https://paste.ubuntu.com/p/Y73FRVqq2n/ Full build log: https://ci.appveyor.com/project/Mudlet/mudlet/builds/26199708 What's the correct solution here? As your log shows, that (re)definition of "byte" is coming from a MinGW header, and not Qt. Given the definition in the Standard Library is in the namespace std, the only possibility for a clash is that there's a "using namespace std;" directive somewhere in your code (or in some other header you include; Qt does not have anything like that). The solution is, as usual, to drop such a directive. This is the other side of the coin for "using namespace" directives: when names are added to those namespaces they may clash against existing code, destroying the isolation that namespaces offer in the first place. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Allow external library to generate OpenGL buffers in context of QOpenGLWidget
Il 15/07/19 22:51, Pieter Barendrecht ha scritto: Hi Giuseppe, Thanks, but unfortunately that's not it. It turns out to be possible to specify an OpenGL context as an optional argument when invoking certain calls to OpenSubdiv, though I'm not quite sure what to pass on from within a QOpenGLWidget — something like context()->handle() compiles but doesn't do the trick. To be continued... What kind of argument is supposed to be passed? The context alone seems a bit pointless (at a minimum one needs an ad-hoc struct containing context, a surface, and pointers to functions to make it current / uncurrent...). Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Allow external library to generate OpenGL buffers in context of QOpenGLWidget
Il 04/07/19 11:17, Pieter Barendrecht ha scritto: I have a Qt application with a QOpenGLWidget for displaying 3D meshes. Now I'd like to use an external library (OpenSubdiv in this case, see e.g. http://graphics.pixar.com/opensubdiv/docs/api_overview.html) to generate additional OpenGL buffers, which I can then bind and use in the context of my QOpenGLWidget. Currently the application segfaults when OpenSubdiv tries to generate these buffers — it does not seem to have a valid OpenGL context. Does OpenSubdiv simply require a current context when asked to generate buffers? You can achieve that by simply calling widget->makeCurrent(). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Removal of convenience functions?
On 03/07/2019 10:39, Michael Sué wrote: QDir ::operator=(const QString ) was removed in 5.13.0, a simple convenience function. What was the problem? Will everyone have to reinvent the wheel to get back such a convenience function in the future of Qt? It was not removed; you can still use it today. But note that it has been deprecated since Qt 4 (and 5.13 added proper deprecation markers). The direct replacement is setPath(). HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Clarification on network security
On 16/06/2019 13:41, Konrad Rosenbaum wrote: Bob, you already have really good answers from Elvis and Thiago - please ignore this thread! In short: use QSslSocket/QSslServer, set the protocol version to 1.2 or newer, deliver the server cert (not key) with your client software, authentication depends on your use case. Ask specific non-Qt questions onhttps://security.stackexchange.com/ . Some other advice: * Ignore Roland's email; * Network security isn't an after-thought, to bolt on somehow at the end of the development. It has implications in your architecture and processes (and ultimately code, to handle it properly). * Network security on non-localhost connections is a mandatory feature and not a "nice to have" (we're still in 2019). Qt makes it easy for application developers via QSslSocket/QSslServer (for TCP), QDtls (for UDP), QNetworkAccessManager (for HTTPS). Depending on which side(s) you're developing, you need knowledge about the challenges involved. * For some of the Qt-specific insights Richard Moore's talk from QtDD : https://www.youtube.com/watch?v=btLCVoEuEr8=PLizsthdRd0YzYe5T3Txgg7TUGVi-ijq4d=43 (It's a bit old, but the main points are still valid. The most important one being do not *ever* call ignoreSslErrors() unless you know what you're doing) * For the non-Qt specific insights, refer to online forums or a few good books (which however go old very quickly and need to be complemented by up-to-date information). I don't know about any single book around PKI operations, though, which are probably one of the most critical parts (rather than delving into OpenSSL programming, which Qt will hide from you). Maybe a question for the forums. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] OpenGL — using glDispatchComputeGroupSizeARB
Hi,
On 06/06/2019 17:05, Pieter Barendrecht wrote:
I'm trying to figure out exactly what to include to be able to use the
OpenGL command glDispatchComputeGroupSizeARB (which I'm positive is
supported on my machine/system). Unfortunately, the typical extension
workflow (i.e. #include in the relevant header file
and QT += openglextensions in the .pro file) does not seem to work — it
still results in an 'use of undeclared identifier' error upon compiling
the code. Any thoughts? I'm on Linux (64bit), using Qt 5.12.
I believe the QtOpenGLExtensions hasn't been regenerated for quite a
while, and thus does not cover this extension (Khronos changed the
extension database format or somesuch).
An easy workaround is to resolve the entry point manually. Include
qopengl.h and do something like this:
if (ctx->hasExtension("GL_ARB_compute_variable_group_size")) {
entry =
reinterpret_cast(ctx->getProcAddress("glDispatchComputeGroupSizeARB");
// use it
}
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How does one use Q_ASSUME?
Il 26/05/19 12:36, René J. V. Bertin ha scritto:
Giuseppe D'Angelo via Interest wrote:
Hi,
On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
After reading the MS doc I sort of understand how you can use the construct to
implement a Q_UNREACHABLE (but in the example given I don't see the codegen
advantage of `default: Q_UNREACHABLE` vs. not adding a `default:` at all).
There isn't usually a codegen advantage between the two (or maybe there
is only in some corner cases; to my book that's a bug report for "missed
optimization"). For instance: on compilers lacking a dedicated builtin,
Q_ASSUME(x) is indeed implemented as
if (x) {} else { __builtin_unreachable(); }
which clearly shows the semantics of Q_ASSUME, and that it can be
implemented in terms of Q_UNREACHABLE.
Look here at a possible example at how it can improve codegen:
https://gcc.godbolt.org/z/KlWBRY
Not really, I'm afraid.
The only thing that's evident to me from there is that there is much fewer
generated machine code when you add the assume statement. I don't see at all why
that would be, what difference it would make for the loop that it is always
iterated over a multiple of 16. I thought the difference might be in evaluating
the `i < count` expression, but even after trying to factor that out the
difference remains:
https://gcc.godbolt.org/z/2Zclp5
In my example, if we tell the compiler that count is a multiple of 16,
then the compiler can do a better job at generating code. In the
specifics, the compiler can use a vectorized loop using AVX to to the
sum 8 integers at a time. If the compiler knows that count is a multiple
of 16, then that loop is enough, and indeed only that loop gets emitted.
If the compiler does NOT know, then it does the vectorized loop as much
as it can, but then it has to deal with the remaining 0-7 integers,
which get dealt in the following generated code, which is an unrolled
for loop.
In your example, the compiler can easily deduce that i and count are
_both_ multiple of 16 (because they have the same value), so it applies
the same optimization. Maybe the codegen is slightly different due to
the decreasing loop induction variable that could throw the optimizer off.
Take home message for me is that this is a construct that's probably useful only
if you have very intimate knowledge about code generation, and thus not very
cross-platform/compiler (and even less cross-architecture). Except for the
Q_UNREACHABLE thing.
The optimization is probably the most compelling aspect of it, because
Q_ASSUMEs are left in release builds. The other aspect is of course an
indication for who reads the code -- that you're making an assumption on
certain conditions, so the following code is valid IFF those conditions
hold.
What I was hoping it might do is what the Qt documentation suggests, a more
graceful version of a Q_ASSERT. That is, a version that does the usual abort in
debug builds, but becomes a regular if in production code. I've seen too many
examples of coding where a Q_ASSERT is used to guard against situations that are
*assumed* never to occur, and then forgotten (or the devs assume everyone else
uses debug/development builds). In many if not most of those cases it's trivial
to add a graceful handling of the situation.
In production code Q_ASSUME is left (as a hint to the compiler);
Q_ASSERT disappears. That's why they're different macros (although, as
you point out, conceptually they indicate the same thing -- that a
condition is always true, else UB).
In debug builds, Q_ASSUME becomes a Q_ASSERT, so you can debug the case
in which the assumption is false.
Hope this helps,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How does one use Q_ASSUME?
Hi,
Il 25/05/19 10:12, René J.V. Bertin ha scritto:
I can't seem to wrap my head around what one can do with Q_ASSUME, i.e. which
will be the code for which the compiler won't emit code (and how the compiler
could know not to emit code as a function of a runtime condition?!)
Squinting at the macros it seems evident that you cannot do something like
this, which to me the documentation suggests (and I think) you SHOULD be able
to do:
Q_ASSUME(conditionsMet, {
// do something that should be done only when conditions are met
});
That's wrong; what you just wrote is a plain if. You can tune codegen by
using Q_LIKELY / Q_UNLIKELY in the predicate, if you know statically
that a condition is (way) more likely to be true than false (or viceversa).
if (Q_LIKELY(condition)) { ~~~ }
On the other hand, Q_ASSUME(cond) tells the compiler that cond is true,
always. If cond is actually false at runtime, you have undefined
behavior. And since undefined behavior cannot happen, the compiler is
free to optimize the following code assuming that cond is true.
Look here at a possible example at how it can improve codegen:
https://gcc.godbolt.org/z/KlWBRY
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Connect to signal QProcess::finished on MSVC 2017
Il 15/05/19 03:55, Konstantin Shegunov ha scritto: If you can't use qOverload or QOverload<...>::of(), then you have only two other options. Static casting the signal to the exact method type, or specifying the template parameter explicitly. Either: QObject::connect(process, static_castQProcess::ExitStatus)>(::finished), receiver, slot); or QObject::connect(process, ::finished, receiver, slot); I would actually recommend against this second form; I don't think there's an official stance by Qt (yet), but if one day we decide to change the template parameters of connect(), it may break. I'd follow to the rule to let the compiler deduce them, at least for connect(). I'd say to stick with QOverload::of() if you can't use a more modern compiler yet. Note that MSVC 2017 (15.8) / 2019 now have finally support for SD-6 feature-test macros, which should make qOverload also work there. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Connect to signal QProcess::finished on MSVC 2017
Hi, Il 15/05/19 03:35, jlk ha scritto: However, on MSVC 2017, I've now read about a bug (in the C++ standard requirements, I guess) that prevents qOverload from working. Could someone suggest a workaround for my case? I need to start an (asynchronous QProcess) and run a function when it finishes. Could you please elaborate? What bug are you talking about? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Don't get expected result from drawing StaticText with HTML
Hi, On 14/05/2019 20:07, Martin Marmsoler wrote: I store this String in a QStaticText (staticText)and draw this text with painter->drawStaticText(QPoint(-w/2,-h/2),staticText); But the result is that the hole text is red and not only the part "arke" Which Qt version are you using, under which OS, etc.? Do you have a minimal testcase somewhere? Did you already try painting a QTextDocument directly, without going through QStaticText? (At least it would point out if there's a bug in QStaticText) Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QFile/QDir: force move mode only?
Hi, On 14/05/2019 15:47, Jason H wrote: I'd rather static bool QFile::isAtomicRename(const QString , cont QString ); So that the software can plan accordingly. Blindly executing won't allow the software to accomodate non-atomic renames (i.e. Display an alternate UI). It would also be nice if there was an atomic-esque non-atomic rename, that would be a copy to the target FS and then atomic rename. Such a function would be inherently racy (the moment you have that information, the information is already outdated, as the filesystem may have changed). Suppose the function returns true, you then call QFile::rename() and may end up copying anyway. (I can't also think of an API at the OS level that could answer your question -- rename(2), link(2) etc. are all "destructive" syscalls. But maybe there is some trick.) However: KIO::rename fails if the rename cannot be performed, and you can then use move: https://api.kde.org/frameworks/kio/html/namespaceKIO.html#a399cbd217c9a897db18ea247fb289c84 Not entirely sure how to fix QFile::rename for this purpose (maybe adding a flag, making it fail if the rename requires a copy), or if it's even worth it given KIO exists. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QFile/QDir: force move mode only?
On 13/05/2019 11:31, Alexander Dyagilev wrote: And yes, this is a really unwanted behavior and it was a short-sighted decision to make it behave so. QFile::rename should rename always or fail! It should never do completely different operation - copy! It doesn't solve the problem at hand directly, but: have you considered using KIO? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
Hi,
Il 07/05/19 16:08, Ola Røer Thorsen ha scritto:
QByteArray bytes; // chosen because some api needs it later
std::vector other_bytes; // maybe returned from some 3rd party library
...
if (static_cast(bytes.size()) >= other_bytes.size()) {
...
}
I guess i could write stuff like
const std::size_t byteSize = bytes.size();
if (byteSize >= other_bytes.size())
but then I rather prefer static_cast. Note that I'm not saying we should
change everything in Qt to unsigned int, I think that might break a lot
of existing application code out there. Just saying that sometimes a
static_cast is needed.
I see, and it's indeed mostly annoying. Again, out of curiosity, is the
API forcing you to use a QByteArray coming from Qt itself?
Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
Il 07/05/19 17:02, Jason H ha scritto: Given how often I miss indexing negatives (to index from the end) It seems that we could do this in Qt6? /me ducks Note that you can (today!) use a range::view::reverse and pass positive indexes, counting backwards from the end. Adding this specific feature to QVector::operator[] won't be exactly welcomed (it'll add a branch inside inside of it). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
On 07/05/2019 16:11, Bernhard Lindner wrote: 1) the the change to qsizetype as an index type has not happened yet, anyhow. It's still a huge question if it's doable in the first place. It is still discussed? I thought it is pretty high at the priority list anyway. No such patch has landed, and the discussion on the mailing list stopped. I'm just guessing it's going to be one of the major points of debate during the container changes expected for Qt 6. It needs some serious experiment on some big code base. Disclaimer: I'm against this change, presented like that, on source compatibility reasons. If we can somehow get 100% SC, then I am totally in favour of it. I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't do it in a minor release, can you? x64 is standard in many applications and memory sizes are growing. I have seen to many platforms/frameworks die an early death because developers where afraid to enforce fundamental architectural fixes/improvements (including evolving language)... until it was too late. The hard answer would be: never. If you need a 64-bit ready byte array/vector/map/hash/list/deque/stack/..., the Standard Library has been providing them for a very long time now. Qt should make the transition towards them easier. The reason why I'm still in favour of the change above is getting a 64-bit QString, whose equivalent simply does not exist in the Standard Library yet. (Honorable mention: QStringView is 64-bit ready.) My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
On 07/05/2019 14:13, Ola Røer Thorsen wrote: We build our code using gcc with the options "-Wall -Wextra -Werror" and this leads us to have to use static_cast for example when comparing int and unsigned int (or std::size_t). A mix of using std::array, std::string and QVector/QByteArray often gives a few extra static casts, not that it bothers me too much. Could you make an example where the casts are needed? Maybe the code can be rearranged in a way that the casts are NOT needed in the first place. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Operator QMap[] is casting to int?
On 07/05/2019 14:42, Jason H wrote: Those will likely change to qsizetype in Qt 6. Which is still signed. This is disappointing. I'll only get half of the indexable space... can I get something in return? Having a negative index mechanism, like in Python, would be a way to alleviate some of the pain. Otherwise can you explain the rationale for not using signed? I guess you meant "not using unsigned" here? Half of the memory space is the theoretical maximum you get anyhow, no matter the signedness of the index, right? (You need to be able to take the pointer difference between any two positions in an array (including the one-past-the-end). Given that ptrdiff_t is the same size of a pointer, and has to be signed, that means that the biggest contiguous block of memory you can index is half of the address space. What am I not seeing?) About the rationale of using signed indices, see the link earlier in the thread to the previous discussion. Side notes: 1) the the change to qsizetype as an index type has not happened yet, anyhow. It's still a huge question if it's doable in the first place. 2) if you need containers bigger than 2^31 elements (assuming QVector gets fixed) then you can use the STL containers _today_. 3) there's only a handful of Qt APIs that take/return Qt containers. A goal for the Qt 5/6 transition would be make them container-agnostic (e.g. using output iterators), so not to tie anyone to use Qt containers. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 92, Issue 5
Il 05/05/19 15:07, Roland Hughes ha scritto:
On 5/5/19 5:00 AM, interest-requ...@qt-project.org wrote:
It makes for a lot of
documentation in the embedded system world where every static_cast<>()
has to be documented in the code and justified in a formal code review
which produces even more documentation. It also makes for some fancy
dancing on 32-bit embedded targets where a uint would be big enough to
hold the size of something but an int falls short.
No, the size of something definitely fits in int on 32-bit systems. And why do
you need to do any static_cast in the first place?
Question: "why do you need any static_cast?".
Virtually every English speaking embedded system shop uses the Barr
standard.
https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard
While each shop tweaks it for C++, C-style casts are explicitly
forbidden (at least in every shop I've been at). None can make it
through formal review. In their C++ presentation slides the Barr group
is a bit softer on their wording. Less so in actuality, but the slides
are recorded forever.
https://barrgroup.com/Embedded-Systems/How-To/Getting-Started-With-Cplusplus
Answer 1): A standard tells me not to use C-style casts.
Does it answer the question? No.
Next is type casting, when we use C style cast, there are times when we
are just kind of smashing “Square peg into a round a hole” this is
potentially dangerous. Because C++ is a lot more finicky about type
checking, the compiler will try to catch bad cast for us. There is no
way of getting around the need to do type casting. As you move forward,
consider always using the C++ cast operators, while these will look a
little foreign and you may need to occasionally look up, which one to
use in which situation, they are likely to ensure safe cast in your program.
As a general rule try to use static cast, this works for most data type
casting. Occasionally you will need to use reinterpret cast. It’s a
closest thing to a real C style cast. Since we don’t recommend using
RTTI, dynamic cast really won’t be of concern to you and we won’t really
talk about it here. And then the last one is const cast, which used with
extreme caution, this is similar to casting away the constance of an
object, so unless you really know that the object you are casting away
the constness from can be done safely we recommend being very careful in
this area.
Answer 2: what the different kinds of built-in casts are in C++, and
what they do.
Does it answer the question? No.
(Note that this is quoting Barr, without saying it out loud explicitly).
As to size definitely fitting in an int, we will have to disagree. Sure,
if a container is extremely short sighted and using an int internally to
keep track of (and therefore limit) each allocated byte, effectively a
neutered container, that statement would be correct. It never __SHOULD__
be correct.
Answer 3: an opinion/argument about whether a container should use an
int to keep track of its capacity.
Does it answer the question? No.
https://code.woboq.org/gcc/include/limits.h.html
/* These assume 8-bit `char's, 16-bit `short int's,
and 32-bit `int's and `long int's. */
/* Number of bits in a `char'. */
# define CHAR_BIT 8
...
/* Minimum and maximum values a `signed int' can hold. */
# define INT_MIN (-INT_MAX - 1)
# define INT_MAX 2147483647
/* Maximum value an `unsigned int' can hold. (Minimum is 0.) */
# define UINT_MAX 4294967295U
Answer 4: random paste from a file proving that on a particular system a
char is 8 bits and int is 32.
Does it answer the question? No.
The biggest physical container one can have is half of maximum physical
RAM. A small application can easily need more than that. We can use the
old chestnut of image processing which needs to load an entire hi-res
image into memory to do some kind of transformation, writing the
transformed bytes to a file output stream.
Answer 5: an argument about the biggest size of a "physical container"
(whatever that is).
Does it answer the question? No.
Is it even technically sound? That depends on the definition of a
"physical container", which I cannot find anywhere ("physical container"
yields 70k results on Google, 'C++ "physical container"' 2k, nothing
that answers it).
If it just means "container", then the argument is broken -- the maximum
size (in allocation units) is half of the *address space*, and the
physical amount of RAM has nothing to do with anything.
More recently we can go back to the QSerialPort discussions happening on
this list not all that long ago. The student level code examples trying
to do all of the I/O in the main event loop with the buffer growing and
growing in size.
Answer 6: an opinion wrt. the quality of some examples around QSerialPort.
Does it answer the question? No.
=
What is, when I ignore the ready read? Has the internal buffer a max
Re: [Interest] Qt World Summit 2019 - CfP
Hi, On 23/04/2019 11:49, Kai Köhne wrote: For Berlin, we (again) have an open Call for Presentations. The deadline for submissions is already *3rd of May* - that is, Friday next week! https://blog.qt.io/blog/2019/03/27/qt-world-summit-2019-call-presentations-open/ Check out above link for the details. Looks like the deadline has been moved to June, 2nd (quietly, haven't seen any announcement, and the blog post above has been silently patched). Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML preprocessing
Hi,
On 24/04/2019 21:23, Alexander Ivash wrote:
Yeah, it could work in theory, but in practice there already a lot of
places which would require such a modification. This solution just
doesn't scale.
Any preprocessing solution will require modifications at all call sites
anyhow, wouldn't it?
Moreover, resulting binary will contain
string 'console.debug('password: ',
someFunctionWhichReturnsPasswordFromProtectedStorage());' (well, maybe
not if qml compiler was enabled).
Why would this be a problem anyhow?
Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 91, Issue 26
On 18/04/2019 16:36, Roland Hughes wrote: The "filter" for SQL is the WHERE clause on the SELECT statement. A "filter" in the C++ world works on the result of the query. Worst case it doubles the memory and transfer resources required. When the goal is reduction of required resources, a filter after the fact cannot help. The original statement said "Its not possible to make the filter part of the SQL query" (sic). I asked why. This is not an answer, just a show-off that you know how SQL filtering works. -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Issue with QSqlModel and QSortFilterModel
Hi, On 18/04/2019 18:48, Scott Bloom wrote: Primarily because the user has the option of using wildcard or regexp, case insensitive or not, for multiple columns. So even if I upgrade Qt to the version that supports QregularExpression or REGEX, and also includes the wildcard to regex converter. Then I also need to figure out how to get the case insensitive option into the core Since /XXX/I doesn’t seem to work, an dyou have to use the case insensitive option.. I'm still *very* confused, what has this to do with a filter applied as part of the query? Why is that road NOT possible? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Issue with QSqlModel and QSortFilterModel
Il 17/04/19 23:40, Scott Bloom ha scritto: I have a source model, which is QSqlModel based, and a filter proxy model. Its not possible to make the filter part of the SQL query.. been down that road… Mind elaborating? Why not? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to hide the QSGGeometryNode?
Hi,
Il 15/04/19 13:11, Denis Shienkov ha scritto:
Yes, now I use this in a form of:
boolCurveNode::isSubtreeBlocked()const
{
returnQSGGeometryNode::isSubtreeBlocked()||!m_visible;
}
voidCurveNode::setVisible(boolvisible)
{
if(m_visible==visible)
return;
m_visible=visible;
if(!m_visible)
m_dirtyState|=DirtySubtreeBlocked;
else
m_dirtyState|=DirtyOpacity;
}
Please make a minimal testcase. The code above seems incomplete (e.g. no
calls to markDirty to update those dirty bits).
HTH,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Random question Friday: Why no area() for Rects and Sizes?, path.join()?
Il 12/04/19 17:09, Jason H ha scritto:
I often miss Node and Python that has a path appender. This could have been tedious
in the past but in C++11, QDir::join({parts, of, a, path, and, filename})
(declared as static QDir::join(const QStringList& parts);)
I'm aware that Qt makes file path delimiters OS-agnostic, but I find myself missing the construct as a logical concept.
It's non trivial in the presence of parts which design absolute paths,
and, Qt should stop adding filesystem convenience APIs before having a
serious discussion on its evolution (e.g. dropping QString in favour of
a filesystem path class).
For instance, see the complicated (confusing?) behaviour of operator/
for std::filesystem::path:
https://en.cppreference.com/w/cpp/filesystem/path/append
Also consider:
source ="file://" + appPath+ "/" + filename
*DO NOT CREATE URLS BY CONCATENATING PIECES*!
Use QUrl properly (QUrl::fromLocalFile, in this case).
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to hide the QSGGeometryNode?
Hello, Il 12/04/19 09:19, Denis Shienkov ha scritto: I have an own class, derived from the QQuIckItem. This class contains a multiple child QSGGeometryNode-s. Each node has own fragment && vertex shader. Each node draws a curves, which are specified by a points set to a vertex array. So, I need possibility to hide any selected QSGGeometryNode (i.e. do not draw it). How to do it in a right way? Did you try already to use isSubTreeBlocked? HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Signals, slots before the event loop starts?
Il 11/04/19 00:18, Jason H ha scritto: In a QObject who is exported to QML, and is instantiated just below the top-level Window: // in the object's open() method: if (!_serialPort.open(QIODevice::ReadWrite)) qApp->quit(); // won't actually quit - no use if I can't use the serial port. (because another instance is using it) Then I have a ready() signal that is emitted when the serial device is ready, however the QML, when I hook onReady, it never gets called. I have to use a Component.onCompleted at the top level. However, there is async serial I/O happening, so there is at least one event loop? What can I do to make sure these things work? Regarding quit(): calling it before exec() has been called yields no effects. This is documented: https://doc.qt.io/qt-5/qcoreapplication.html#quit If a signal connected (non-queued) to this slot is emitted before control enters the main event loop (such as before "int main" calls exec()), the slot has no effect and the application never exits So, instead of calling quit() directly, do a queued invocation. Regarding ready(): can't say more without looking at the code. You need to make a minimal testcase. Anyhow, all events queued before running exec() will get dispatched when you enter the event loop. The problem with e.g. quit() is that it does not involve sending events at all, it involves setting a flag into the event loop. Flag that is never read because the event loop is not running... HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Using a QAbstractScrollArea
Il 22/03/19 19:24, Bob Hood ha scritto: I'm having a bit of a brain fart here. I have a third-party class I'd like to use that inherits from QAbstractScrollArea. Qt Designer only knows about a QScrollArea, though, which inherits QAbstractScrollArea. How do I use this as a concrete Qt class type? Do I inherit from QScrollArea and then somehow change my parent to it? Or do I have to inherit from the third-party class, and then recreate the entire QScrollArea interface so it "quacks" like a QScrollArea instance? Is the question about how to use your custom class from Designer, or about how does QASA work and how's different from QSA? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
Il 20/03/19 19:41, Thiago Macieira ha scritto: Actually, it doesn't: 5.9 support ends in May 2020, OpenSSL 1.0 in Dec 2019. You're off by one year. 5.9.0 was released May 29, 2017. 5.9's support ends in May 2019 (probably a bit later because we are able to make the 5.9.9 release). Isn't the LTS supported for 3 years? We've now reached EOL for 5.6, released in March 2016. Is 5.9 supported only for 2 years? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
Il 20/03/19 19:29, Thiago Macieira ha scritto: Qt 5.9's lifetime ends before OpenSSL 1.0's. Actually, it doesn't: 5.9 support ends in May 2020, OpenSSL 1.0 in Dec 2019. The reality is that if your software depends on multiple libraries, your deadline is the whichever EOL for those libraries comes first. So, again, UPGRADE NOW. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
Hi, Il 20/03/19 18:23, David M. Cotter ha scritto: I understand LibreSSL has some advantages, is that worth checking out? Qt does not work with LibreSSL. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 5.9 and OpenSSL 1.1?
Il 20/03/19 11:15, René J.V. Bertin ha scritto: I just learned that Qt 5.9 apparently doesn't build against OpenSSL 1.1 . Does anyone already have a fix for this? Which distribution already stopped shipping OpenSSL 1.0? Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt on direct compose
Hi, On 18/03/2019 14:32, Pierre Lamot wrote: Before starting to perform a draw call, DComposition will inform you where it expect you to perform your drawing within the texture it gives you, like an OpenGL viewport. In most cases this will be (0,0) and will works out of the box. Though, especially when dealing with small resolution, DComposition will recycle its texture and ask you to draw with a different viewport. I didn't find a way to specify the viewport on Qt side, it seems to reset it before drawing the scene (probably [4]) . So my question is, is there any way I can tell Qt what viewport to use? Maybe there's a small bit of API missing here on QQuickWindow, to specify the viewport that Qt Quick should use when rendering on a FBO? (I'd suggest to open a feature request for this, should be relatively simple to implement...). Given the codepath that you pasted, there seems to be no way for a custom glViewport in there. And I wouldn't recommend using QSGEngine, the effort is definitely not worth it here. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] popcnt for QFlags
Il 15/03/19 13:58, Konstantin Shegunov ha scritto: PS. should I just use qPopulationCount? Yes, this is public API. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [#ID:INC-1251018#] Installation issue.
Il 12/03/19 02:11, Allan Sandfeld Jensen ha scritto: The problem is not the GCC version. It's the set of libraries provided by the old distribution. And I guess he could still build his own packages. The libraries would just use bundled qt copies if too old. Only the prebuilt packages have higher requirements, right? No; e.g. xkbcommon is no longer shipped with Qt and the one in RHEL6.6 is too old (the solution is building your own, I guess). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Taking back a widget from a QBoxLayout?
Il 22/02/19 20:42, Jason H ha scritto: ''' When you use a layout, you do not need to pass a parent when constructing the child widgets. The layout will automatically reparent the widgets (using QWidget::setParent()) so that they are children of the widget on which the layout is installed. Note: Widgets in a layout are children of the widget on which the layout is installed, not of the layout itself. Widgets can only have other widgets as parent, not layouts. ''' This is the bulk of the story, and ultimately, what's interesting for you. However: ''' void QLayout::addItem(QLayoutItem *item) Implemented in subclasses to add an item. How it is added is specific to each subclass. This function is not usually called in application code. To add a widget to a layout, use the addWidget() function; to add a child layout, use the addLayout() function provided by the relevant QLayout subclass. Note: The ownership of item is transferred to the layout, and it's the layout's responsibility to delete it. void QLayout::addWidget(QWidget *w) Adds widget w to this layout in a manner specific to the layout. This function uses addItem(). ''' So the docs are clear as mud. The docs are indeed unclear, but look at what you're quoting -- a function to add QLayoutItems to a layout. A QWidget is NOT a QLayoutItem (but it is possibly managed by one). QLayout::addItem will add a QLayoutItem to a layout, passing ownership of the _item_ to the layout (but not of the widget the layout item is managing). In other words, if you have a toplevel widget with two children (A and B), managed by a layout, what you're going to build looks like this from an ownership point of view: * QWidget (top) | +—— QWidget A | +—— QWidget B | \—— QBoxLayout ¦ +-- QWidgetItem (managing A) ¦ \-- QWidgetItem (managing B) Solid lines represent ownership via QObject parent/child. Dashed lines represent ownership via other means. QLayout mentions "ownership" but the tips mention "parent". FWIW, I knew QWidgets parented QWidgets, but I don't know what it means by "ownership". They refer to the same thing. A parent QObject owns (... has ownership of) its children QObjects, meaning that deleting the parent will deleting the children as well. Some object Foo acquiring ownership of Bar means that deleting Foo will also delete Bar. This can happen through QObject parent/child, or some other mechanism. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Taking back a widget from a QBoxLayout?
Il 22/02/19 19:04, René J.V. Bertin ha scritto: I am not 100% sure, it's been a while, but I would assume that the layout is not the true parent, combined is. The docs aren't exactly clear on this subject, at least not with the sort of reading glasses I usually have on when I don't exactly want to be reading them ;) Widgets can only have other widgets as parents. When you add a widget to a layout, the layout will reparent that widget to the widget the layout is installed onto. https://doc.qt.io/qt-5/layout.html#tips-for-using-layouts HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
Il 22/02/19 12:01, Uwe Rathmann ha scritto: Actually there are several versions of Qt5 that do not even compile when setting qreal=float. After reporting such a bug the fix did not even go into the relevant LTS version ( Qt 5.9 at that time ). Obviously building with qreal=float seems not to be covered by the Qt tests and also does not seem to be seen as import by the development. As long as such a configure option exists, a FTBFS bug is a P0/P1 in my book. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
Il 22/02/19 19:27, Matthew Woehlke ha scritto: We*almost* had that with QVectorNd and QMatrixNxN... until Qt5 went and made them float. Sigh. *Deliberately*, to target GPU programming, where the only things that matter (de facto) are floats. What I would*really* love is to see Eigen or the like standardized as part of C++23 :-D. But that's getting OT... Almost, we're getting more and more technical debt in Qt, and repeating the mistakes of the past (NIH and so on). Should Qt 6 try and change this trend? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
Il 21/02/19 22:47, Matthew Woehlke ha scritto: So... after a full day of debugging, trying to port my Qt4 app to Qt5 and chase down a nasty case of stack clobbering, I discovered that the problem is that QMatrix4x4 changed from qreal to float. (Uh...why? I am not particularly amused by the loss of precision, nor the extremely subtle incompatibility.) IIRC the idea in Qt 5 was that: * QMatrix, QTransform, QPointF, QRectF and so on were "raster engine" (aka CPU-rasterizer) datatypes, therefore using qreal (so either double or float depending on how you build Qt); * QMatrix4x4, QVectorND and so on were types for OpenGL integration, therefore only using float. The fact that you can use QMatrix4x4 on a QPointF is IMNSHO an API mistake. The two shouldn't mix together "transparently", if the intention is the one above. Alas, there does not seem to be any feasible replacement in Qt. I can't use QGenericMatrix because it can't be used to transform QPointF's, nor can it be inverted, both of which are features I require. I*really* don't want to throw out the precision of double, especially as I have tons of other code that still uses double and would have to wade through mountains of conversion warnings to do so. Am I missing something, or do I need to drag in Eigen? You're not missing anything. But maybe you can use something simpler, like GLM's dmat4? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSortFilterProxyModel
Il 19/02/19 16:48, Christopher Probst ha scritto: Thank you Nils. My question may have have been incomplete. I am looking to filter the model through a regular expression on data contained in the header. I am not sure the method you suggested is the appropriate one. But it will certainly help. Something that would ideally look like void setFilterKeyColumn(int column), where I have a column number that represents the vertical header. I'm not 100% sure I understood what you need, but here's an idea. Make your model return the header data you want to filter upon as some "hidden" role of come column. Then put a QSFPM on top, filtering on that column and that hidden role. If you can't modify the source model, place a QIdentityProxyModel in the middle with a custom data() override. HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
