Re: [Interest] Licensing

2019-10-06 Thread Uwe Rathmann

On 10/6/19 12:03 PM, Giuseppe D'Angelo via Interest wrote:


Hey, I linked it two emails ago :-)


Ah yes, sorry.

My response was initially more explicit about FUD, before I decided, 
that it is not worth the effort.


Uwe


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


[Interest] Customizing / extending platform plugins best practices

2019-10-06 Thread Alexander Ivash
Is it possible to extend android platform plugin (in particular I'm
interested in QAndroidInputContext) without complete
re-implementation?

If yes, then what are the best practices / right workflow?

Just copy and modify 'Src\qtbase\src\plugins\platforms\android' and
include 'android.pro' as subdir project? How to distribute customized
plugin instead of original one as the part of application?

In general, is there any docs / presentations covering this topic?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Interest Digest, Vol 97, Issue 4

2019-10-06 Thread Thiago Macieira
On Saturday, 5 October 2019 14:38:17 PDT Roland Hughes wrote:
> 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

You do realise that's not how modern encryption works, right? You do realise 
that SSL/TLS rekeys periodically to avoid even a compromised key from going 
further? That's what the "data limit for all ciphersuits" means: rekey after a 
while.

You're apparently willfully ignoring the fact that the same cleartext will not 
result in the same ciphertext when repeated in the transmission, even between 
two rekey events.

> For xml you just need to find
> 
>  
> or the first 8 bytes of it (for the 64-bit block ciphers) and you are
> golden.

Which is why we don't use 64-bit block ciphers anymore. We are using 128- and 
256-bit AES, which works very differently. You can't compute a fingerprint 
database for those. And even if you could, you d still have birthday attacks: 
two keys could result in the same ciphertext for the same input, but not for 
the next input. 

And don't forget the Initialisation Vector. Even if you could compute the 
fingerprint database, you still need to multiply it by 2^128 to account for 
all possible IVs.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
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

2019-10-06 Thread Thiago Macieira
On Saturday, 5 October 2019 06:13:56 PDT Richard Weickelt wrote:
> >> 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:
[snip]

Thanks for the detailed debugging, Richard, and for the bug report you filed. 
Looks like I wasn't seeing the problem because I was looking at the UNIX event 
dispatcher, but you're running against the Glib one. I usually prefer reading 
the source of the former because I can scroll through all of it. With the Glib 
one, since it goes through Glib and comes back out via callbacks, it's hard to 
follow.

And that's exactly the problem: because of the need for callbacks, it's saving 
the state for too long. There's a difference in behaviour between the two 
dispatchers and that needs to be fixed.

> > 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.

You may want QT_NO_GLIB=1 or just not build with Glib support.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


[Interest] Centre a QDialog on macOS in a QQuickWindow

2019-10-06 Thread Dimitar Dobrev via Interest
Hello everyone,

I have a QQuickWindow which shows a QDialog. I want the QDialog to be centred 
on macOS and be window-modal. I've tried with:

windowHandle()->setTransientParent(myQQuickWindow);
windowHandle()->setFlags(Qt::WindowType::Dialog);

But the QDialog keeps behaving like a regular macOS window.

How can I achieve this?

Thank you.___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Licensing

2019-10-06 Thread Giuseppe D'Angelo via Interest

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

2019-10-06 Thread Uwe Rathmann

On 10/5/19 7:57 PM, Giuseppe D'Angelo via Interest wrote:

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).


Asking sales people if you don't need to buy a commercial license - 
don't believe, that this a good advice.


Maybe this presentation helps:
https://www.youtube.com/watch?v=bwTlCBbB3RY

Uwe

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest