[Interest] How to obtain padding and border styling for QFrame derived control
Hi Everybody, I have a QFrame derived widget that is styled using an application style sheet with optional padding and borders. In the minimumSizeHint, I need to get the currently active values from the style sheet. I would like to use sizeFromContents, but there is no ContentsType CT_Frame to adjust my contents rect. In the paint event, I call QFrame::paintEvent to do the background and borders, then I paint my contents. I expect contentsRect to be smaller due to the border and padding, but it isn't. How can I get (or allow for) the style sheet values? Regards, Tony ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] heads up - ksplashqml crash
Just in case this is deeper than the ksplashqml. https://bugs.kde.org/show_bug.cgi?id=408904 Don't know if it is specific to KDE or deeper within Qt. Appears to happen with nvidia-340 driver but doesn't happen with nvidia-driver-390 installed. I don't know if there was an assumption made deep in qml about what the Nvidia drivers can provide or if someone made said assumption in ksplashqml. Those who are trapped at 340 due to newer drivers will see this problem. https://nvidia.custhelp.com/app/answers/detail/a_id/3142/~/support-timeframes-for-unix-legacy-gpu-releases -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 97, Issue 4
On 10/5/19 5:00 AM, interest-requ...@qt-project.org wrote: 3) Phone App and Web developers should never use XML, JSON or any "free text" standard nor should they write systems which expect to get it off the IP stack in that format. If they do, then they are the security breach. If the exact same key+algorithm is used for an entire session, a hacker only needs to identify a single fingerprint to decrypt ever packet. Here's a really good 2016 article about birthday attacks and other security breaching methods. https://sweet32.info/ It is fine if your eyes glaze over reading it. Man I _never_ wanted to step back into this world! Before passing out reading it one should jump to the "Responsible disclosure" part near the end. "Mozilla is implementing data limits for all ciphersuites. This has been integrated into NSS 3.27, which should be used in Firefox 51." Okay, I'm at 69.0.1 on my machine, but the version isn't the interesting part of that quote. "data limits for all cyphersuites" is the interesting part. If you managed to wade through the entire article you will see they were able to force some "birthday" attacks within 64MiB of packet exchanges. This "data limits for all ciphersuites" is what pushes the creation of "fingerprint" databases. Lord knows there are more than enough compromised machines out there to create thousands of such databases. With a fingerprint database you need ONE magic packet. For JSON, that is any packet in the stream because you are looking for " : " ":" " :" ": " as an encrypted fingerprint with many instances in the packet. If the encryption algorithm used consistently encrypts the same character string the exact same way within a packet a human just glancing at the sniff could see the repetition. For xml you just need to find or the first 8 bytes of it (for the 64-bit block ciphers) and you are golden. But to find that you have to sniff the first packet of the document. Another interesting quote from that same section has to do with OpenVPN "It will also implement a default renegotiation limit of 64MB when used in TLS mode in a future version." They are slowly migrating towards what all communication has to use, a book code. Use of a book code removes the renegotiation. If you allow more than one packet to use one key+algorithm pair, at some point one side or the other sends the "next code" command then both sides move to the next code. The correct way to do it is change with every packet though. I call it "reading the book." The only negotiation is about which book and what page at the beginning. The books all have numbers and are routinely rotated out. No client has more than 3 and no server has more than 5. Fall too far behind and you need a new executable from the head librarian. *nix did it wrong. None of this transport layer stuff should ever happen at the application developer level. The "system manager" should configure the available connections along with their dynamic security and they should simply appear as files or streams of known names. In the case of Google/Apple/etc. idiot phones the "system manager" is Google/Apple/etc. When they push an update they push a new configuration with new books. One still shouldn't use XML or JSON because of the fingerprint repetitions. Note: With XML I focused on the opening string because it is a thumbprint. One could choose to search for the fingerprints of both < and > repeating many times within any given packet having stuff between them. -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ 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
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 hope one day Qt step up once and for all on this, the fact that this question rise over and over again is a huge indicator of the problem. I really do like the Qt framework, but the licensing is a mine field. From: Interest on behalf of Giuseppe D'Angelo via Interest Sent: Saturday, October 5, 2019 12:16 PM To: interest@qt-project.org Subject: 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 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
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] Expected event execution order in this multi-thread application
>> Because I attached a debugger and stopped T1 during
>> QCoreApplication::processEvents(). I can see E3 (the one that the thread is
>> currently processing) in postEventList at index 0 and E2 at index 1. That's
>> it. From there I see the following call chain
>> QEventDispatcherGlib::processEvents() followed by emit awake() because
>> canWait is false. I haven't traced it further. The signal emission doesn't
>> have any consequence in the event loop though.
>
> Can you check what happens when it calls into
> QCoreApplicationPrivate::sendPostedEvents()? That function should loop from
> data->postEventList.startOffset to data->postEventList.size() (size at the
> time you call into the function, so no new events wil be handed).
> Like you said, it should be handled on the first iteration after it's been
> queued.
The problem is that my explicit calls to QCoreApplication::processEvents()
do not reach QCoreApplicationPrivate::sendPostedEvents(). I found the root
cause:
1. Posted events will increase a counter (serial number) in the glib event
dispatcher
2. Before a call into QCoreApplication::sendPostedEvents, the dispatcher
stores the current counter value (lastSerialNumber). If multiple events are
sitting in the event queue, the counter value will reflect the last posted
event.
3. Explicit periodic calls to QCoreApplication::processEvents() go into
QEventDispatcherGlib::processEvents() which invokes an iteration in the glib
event loop. So far so good.
4. The glib event loop now calls postEventSourcePrepare() which compares the
stored lastSerialNumber to the current serial number. This function acts as
a filter to decide whether the glib event loop should invoke
QCoreApplicationPrivate::sendPostedEvents(). Since it finds lastSerialNumber
to be equal to the current serial number, it doesn't do anything.
Here is a minimal example of what is happening. It doesn't even need
multiple threads:
#include
#include
#include
namespace {
QAtomicInt done = 0;
}
void E1();
void E2();
void E3();
void E1() {
qDebug() << "E1";
QMetaObject::invokeMethod(qApp, , Qt::QueuedConnection);
QMetaObject::invokeMethod(qApp, , Qt::QueuedConnection);
}
void E2() {
qDebug() << "E2";
while (done == 0) {
QCoreApplication::processEvents();
}
QCoreApplication::exit(0);
}
void E3() {
// We never reach this
qDebug() << "E3";
done = 1;
}
int main(int argc, char *argv[])
{
QCoreApplication app(argc, argv);
QMetaObject::invokeMethod(qApp, , Qt::QueuedConnection);
app.exec();
}
As soon as some other thread posts an event E4 to the current event loop, E3
will be executed, followed by E4 as expected.
>> It is a public API and it is not marked as deprecated. If the function does
>> not behave as documented, then either the documentation is wrong or the
>> implementation has a bug or I am using it the wrong way. I don't think the
>> latter is the case, but maybe I need a minimal test case to prove that.
>
> It's not broken, that's why it's not deprecated. But that doesn't mean it's a
> good API. It's not advisable to use nested event loops. processEvents() is
> just the worst kind of nested event loops.
Sure. Unfortunately, our application relies on QScriptEngine and requires
that the engine's thread stays somewhat responsive. Now that I understand
the problem, I might be able to implement a work-around in our application.
But I would consider this behavior to be a bug in qeventdispatcher_glib. It
can never be wrong to fix bugs, even in bad APIs ;-)
https://bugreports.qt.io/browse/QTBUG-79020
Richard
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Licensing
Apologies if this something that’s been asked many times before. 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? 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. Thanks very much. Colin Worth BrainCo, Inc. ___ 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
On Saturday October 05 2019 09:29:17 René J.V. Bertin wrote:
>But Q*Animation in basic form shouldn't need to be so much more intensive,
>right? You'd be doing the same work in a finger-painting approach if you want
>the same animation parameters (here, rotate from 0 to 360 in 2s with 16ms
>intervals). Can there really be so much overhead in calculating the animation
>parameter (via QVariant)?
Confirmed, with
```
aniTimer.setInterval(1000/frequency);
QObject::connect(, ::timeout,
q, [=]() {
q->update(); // repaint new rotation
// use the actual dt obtained from a QElapsedTime instead of the
programmed dt
// the conversion from ms to s is implicit through the unit of
durationMs;
auto elapsed = aniTime.restart();
rotation += elapsed * 360.0 / durationMs;
if (rotation > 360) {
rotation -= 360;
}
});
```
I observe exactly the same CPU loads, even with the default QCoarseTimer. Am I
doing something wrong here?
Curiously I do see a bit more of an effect of running a bogus animation here
but even here loads remain high; 10% for just triggering a signal that calls a
lambda 60 times per second? What kind of overhead does QWidget::update() incur,
because when I shunt `q->update()` in the snippet above the load drops
drastically.
R.
___
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
On Friday October 04 2019 23:56:13 André Pönitz wrote: Hi, >I'd take a step back here and check what is really needed for the >purpose. That was my actual purpose here... Thing is, in order to indicate "we're busy", you can toggle a state (green becomes red), play a waiting music or display a full simulation of the thermodynamic processes in a race engine. It all depends on how you define "needed for the purpose" ;) >by a QVariantAnimation, does not really mean that one has to, >especially as soon as someone complains about performance. To be honest, I haven't yet noticed a performance implication but that's also because the widget is too new for me and I haven't looked for it. After all we're not talking about 50% CPU waste; 10-12% probably won't be apparent immediately. It's more likely that you'll start noticing a less nice "user experience" in the widget itself when the system begins to be swamped... But about using a QAbstractAnimation derivative in UI feedback: it is also used in animated (indeterminate) progressbars in many widget styles >I haven't checked, but I am ready to bet that "finger painting" >the in the paintEvent(), triggered by a timer calling update will >take significantly less resources. That would be an easy fix: the rotation already happens in the paintEvent() which apparently is far easier in there than in other parts of the code (no need to compensate scaling). I am going to check if you're right, you probably are; indeterminate progressbars are 2x less resource-intensive in my theming of the QtCurve style as they are in Fusion, and that must be due to the use of what you call finger painting. But Q*Animation in basic form shouldn't need to be so much more intensive, right? You'd be doing the same work in a finger-painting approach if you want the same animation parameters (here, rotate from 0 to 360 in 2s with 16ms intervals). Can there really be so much overhead in calculating the animation parameter (via QVariant)? R. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
