Re: [Interest] copying the object in the delegate

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

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

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

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.

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

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

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

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

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

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

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-05 Thread Giuseppe D'Angelo via Interest

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

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

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

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

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

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

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?

2019-09-25 Thread Giuseppe D'Angelo via Interest

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

2019-09-22 Thread Giuseppe D'Angelo via Interest

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

2019-09-21 Thread Giuseppe D'Angelo via Interest

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()?

2019-09-18 Thread Giuseppe D'Angelo via Interest

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?

2019-09-16 Thread Giuseppe D'Angelo via Interest

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

2019-09-16 Thread Giuseppe D'Angelo via Interest

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

2019-09-16 Thread Giuseppe D'Angelo via Interest

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?

2019-09-15 Thread Giuseppe D'Angelo via Interest

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

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

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

2019-09-05 Thread Giuseppe D'Angelo via Interest

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

2019-08-29 Thread Giuseppe D'Angelo via Interest

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?

2019-08-26 Thread Giuseppe D'Angelo via Interest

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?

2019-08-26 Thread Giuseppe D'Angelo via Interest

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?

2019-08-23 Thread Giuseppe D'Angelo via Interest

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*?

2019-08-16 Thread Giuseppe D'Angelo via Interest

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

2019-08-15 Thread Giuseppe D'Angelo via Interest

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

2019-08-14 Thread Giuseppe D'Angelo via Interest

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

2019-08-14 Thread Giuseppe D'Angelo via Interest

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()?

2019-08-02 Thread Giuseppe D'Angelo via Interest

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

2019-07-24 Thread Giuseppe D'Angelo via Interest

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

2019-07-15 Thread Giuseppe D'Angelo via Interest

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

2019-07-15 Thread Giuseppe D'Angelo via Interest

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?

2019-07-03 Thread Giuseppe D'Angelo via Interest

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

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

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

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

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?

2019-05-26 Thread Giuseppe D'Angelo via Interest

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?

2019-05-25 Thread Giuseppe D'Angelo via Interest

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

2019-05-15 Thread Giuseppe D'Angelo via Interest

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

2019-05-15 Thread Giuseppe D'Angelo via Interest

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

2019-05-14 Thread Giuseppe D'Angelo via Interest

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?

2019-05-14 Thread Giuseppe D'Angelo via Interest

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?

2019-05-13 Thread Giuseppe D'Angelo via Interest

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?

2019-05-07 Thread Giuseppe D'Angelo via Interest

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?

2019-05-07 Thread Giuseppe D'Angelo via Interest

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?

2019-05-07 Thread Giuseppe D'Angelo via Interest

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?

2019-05-07 Thread Giuseppe D'Angelo via Interest

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?

2019-05-07 Thread Giuseppe D'Angelo via Interest

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

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

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

2019-05-02 Thread Giuseppe D'Angelo via Interest

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

2019-04-29 Thread Giuseppe D'Angelo via Interest

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

2019-04-18 Thread Giuseppe D'Angelo via Interest

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

2019-04-18 Thread Giuseppe D'Angelo via Interest

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

2019-04-18 Thread Giuseppe D'Angelo via Interest

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?

2019-04-15 Thread Giuseppe D'Angelo via Interest

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()?

2019-04-13 Thread Giuseppe D'Angelo via Interest

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?

2019-04-12 Thread Giuseppe D'Angelo via Interest

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?

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

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

2019-03-23 Thread Giuseppe D'Angelo via Interest

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?

2019-03-20 Thread Giuseppe D'Angelo via Interest

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?

2019-03-20 Thread Giuseppe D'Angelo via Interest

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?

2019-03-20 Thread Giuseppe D'Angelo via Interest

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?

2019-03-20 Thread Giuseppe D'Angelo via Interest

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

2019-03-18 Thread Giuseppe D'Angelo via Interest

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

2019-03-15 Thread Giuseppe D'Angelo via Interest

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.

2019-03-11 Thread Giuseppe D'Angelo via Interest

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] Rendering Qt/QML within native OpenGL or to texture

2019-03-07 Thread Giuseppe D'Angelo via Interest

Hi,

Il 07/03/19 18:33, Stefan Fabian ha scritto:

Today I've found another way to use native OpenGL to draw on top of the scene 
in OGRE after the render queue ended but couldn't work out how to paint on it 
using Qt without getting stuck at the getting the content on screen without the 
QImage copy workaround in Approach 2.


See my talk at QtWS17 about how to integrate Qt Quick 2 with OpenGL. You 
basically need the third method (QQuickRenderControl) as you don't have 
control over the GL context creation.


You can wrap a foreign OpenGL context in a QOpenGLContext using its 
setNativeHandle function. Then you can use QQuickRenderControl as 
illustrated in my talks, the accompanying code and the examples in Qt.





Unfortunately, 3D graphics and OpenGL is pretty far from my fields of expertise 
which is why I'm hoping someone who is more competent than me regarding OpenGL 
and QOpenGL can help me figure this out.
I'll attach code parts that I deem important below, if you require a working 
example I can send you the code (it's not opensource yet but I'm planning on 
releasing it in the near future) but it requires a Linux distribution (only 
tested with Ubuntu) and a ROS installation.

To summarize: I'm trying to find a way to either render directly to the 
texture, use a quicker method to copy the content from the FBO to the texture 
than getting a QImage and memcpy or, alternatively, render directly on top of 
the scene using the access to native OpenGL I've found today (here the problem 
is that I don't really know how to continue using OGRE's context when rendering 
Qt/QML).


An alternative of the above: create yourself a new OpenGL context that 
shares with the one used by Ogre. Then use this new context (again 
together with QQRC) to render Qt Quick content into a FBO (see 
QQuickWindow::setRenderTarget). Now, since your OpenGL context and 
OGRE's are sharing, the textures that you use inside your FBO are also 
visible from the OGRE context -- you just need to paint with them, no 
copies or CPU roundtrips are involved. Just beware of the headaches that 
go together with sharing OpenGL objects: there's no implicit command 
synchronization amongst contexts, you must be sure that all your drawing 
on the texture is fully realized by the GL before reading from it from 
the other context. Sync objects (or the very crude glFinish) can be used 
for this.


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] Taking back a widget from a QBoxLayout?

2019-02-22 Thread Giuseppe D'Angelo via Interest

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?

2019-02-22 Thread Giuseppe D'Angelo via Interest

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?

2019-02-22 Thread Giuseppe D'Angelo via Interest

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?

2019-02-22 Thread Giuseppe D'Angelo via Interest

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?

2019-02-22 Thread Giuseppe D'Angelo via Interest

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

2019-02-19 Thread Giuseppe D'Angelo via Interest

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


Re: [Interest] Feature Request - QtCreator - Multiple right margins

2019-02-08 Thread Giuseppe D'Angelo via Interest

Hello,

Il 08/02/19 15:19, rol...@logikalsolutions.com ha scritto:

While it would be awesome if QtCreator could let it be
completely arbitrary as Sublime does:

"rulers": [80, 100, 120],
"word_wrap": true,
"wrap_width": 120

It would be nice to be able set 2 with the farthest one being the wrap
point if wrapping is enabled. Most shops strive for 80 but put in
their "overrides" for the standard a hard limit of 130. As it stands
now we can see what we strive for or the hard wall, but not both.



Submit a "feature request" on Jira? It's the best way to have something 
like this properly tracked. Also, there's a dedicated mailing list for 
Qt Creator users, you may want to ask there as well.


Regards,
--
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 QT_POINTER_SIZE safe when cross compiling?

2019-01-28 Thread Giuseppe D'Angelo via Interest

Il 29/01/19 00:21, rol...@logikalsolutions.com ha scritto:

I tried navigating down the headers but was unsuccessful at finding
the definition. Okay, I lost patience digging for it.


Use code.woboq.org


https://code.woboq.org/qt5/qtbase/src/corelib/global/qprocessordetection.h.html#_M/QT_POINTER_SIZE






If I'm compiling on a 64-bit host for a 32-bit target, is
QT_POINTER_SIZE going to return the correct number of bytes for the
32-bit target?


Yes, the various Qt arch macros are for the target system, not the host.

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] Get http headers from web engine view?

2019-01-19 Thread Giuseppe D'Angelo via Interest

Il 19/01/19 17:16, First Last ha scritto:

I am using a qml WebEngineView to show a login/signup view (provided by a Rails 
server). On successful login, the server provides a jwt authentication token in 
the http headers of the response. How can I get this header from the web 
engine? Do I need to use a webengine widget instead of qml?


I don't think you have any access to the HTTP stack provided by web 
engine. Are you sure you don't need to perform the login using XHR and 
then using getResponseHeader() to get the value of that header?


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] QQmlApplicationEngine and antialiasing

2019-01-16 Thread Giuseppe D'Angelo via Interest

Hi,

Il 15/01/19 20:26, Jérôme Godbout ha scritto:

Ah good to known, I will keep a note about this env variables to print the info.

Seem like if I used the 3D acceleration, the AA samples is not used and stick 
to 1, but if I do not enable the 3D acceleration into my VM, I get lie and it 
tell me I have the requested samples but it is not seen into the rendering. I 
did try with 4x and 8x samples. I'm a bit confuse about this.


My gut feeling is that you simply don't have working MSAA in a VM. I 
don't think the Shape module supports any other form of AA when rendered 
through OpenGL (but I might be wrong 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] QQmlApplicationEngine and antialiasing

2019-01-15 Thread Giuseppe D'Angelo via Interest

Il 15/01/19 16:10, Jérôme Godbout ha scritto:
There is no difference between 0, 2, 4, 8 except the print 
QSurfaceFormat reported value. Is there anything else I should check? Is 
OpenGL used at all?




Export QSG_INFO=1 and run your application. What's the output?

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] QQmlApplicationEngine and antialiasing

2019-01-14 Thread Giuseppe D'Angelo via Interest

On 14/01/2019 22:10, Jérôme Godbout wrote:

Hi,

I'm trying to enable the antialiasing inside my project that use 
QQmlApplicationEngine (currently under Linux). I have some QMl Shape  
that look ugly and the antialiasing doesn't seem to work at all. What is 
the proper way to enable the AA that is cross platform and will work on 
both QtCreator debug and release mode?


Note that debug/release mode has nothing to do with this...

Assuming that you're using the OpenGL backend:

I have try to enable the default surface at the very beginning of the 
main, after the application is created or even on the QWindow surface, 
but nothing seem to work:


#include 
#include 
#include 
#include 
#include 

#define NB_AA_SAMPLE 8

void EnableAntialiasingOnEngine(QGuiApplication& app)
{
     QWindow* window = app.topLevelWindows().first();
     QSurfaceFormat surface_format; // = window->format();
     surface_format.setSamples(NB_AA_SAMPLE); // AA sampling
     window->setFormat(surface_format);
}


This is meaningless; you need to set the format on the window AND the 
context and you need to do so before they're created (in the sense of 
calling create() on them). In other words, this is incomplete and too late.



void EnableAA()
{
     QOpenGLContext ogl_context;
     QSurfaceFormat surface_format;
     surface_format.setSamples(NB_AA_SAMPLE);
     ogl_context.setFormat(surface_format);
     if(!ogl_context.create())
     {
         qWarning("Cannot create OpenGL context for AA.");
     }
}


This might be useful as a check that you CAN create an OpenGL context 
that supports MSAA. But note that the mere creation isn't enough, you 
need to get the format back from the created context (context.format()) 
and check *that*.




void EnableDefaultAA()
{
     QSurfaceFormat surface_format = QSurfaceFormat::defaultFormat();
     surface_format.setSamples(NB_AA_SAMPLE); // AA sampling
     QSurfaceFormat::setDefaultFormat(surface_format);
}


This is the correct way and should work, given you call this before 
creating QGuiApplication. If the result is still aliased, grab the root 
object, downcast it (it's going to be some QQuickWindow subclass), get 
its OpenGL context after it has been created (openglContext(), or 
connect to openglContextCreated()), and dump its format. Thus double 
checking that your implementation DOES support multisampling...


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] 5.11.3 make install failure

2019-01-14 Thread Giuseppe D'Angelo via Interest

Il 14/01/19 21:52, Jason H ha scritto:

I would have thought that make would have topologically sorted that out by now. ¯\_(ツ)_/¯ 
I mean, the makefile itself*is*  the dependency graph. Any list of files with no 
dependencies should be a pool that can be compiled in any order. I've always structure my 
source tree and made my makefiles this way, so they "just work". To do 
otherwise is to improperly wield the tool.

What would be needed to fix the issue? Is it the configure script failing, or 
some other part of the makefile generation?


Neither; just dependencies across submodules or subdirs in the same 
module not being written in the .pro files. Thus qmake doesn't generate 
dependency information, thus make will not build (if you're unlucky).


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] 5.11.3 make install failure

2019-01-14 Thread Giuseppe D'Angelo via Interest

Il 14/01/19 18:46, Jason H ha scritto:

It took repeated `make`s to finally build. Never failed repeatedly in the same 
place. I think this is a GCC issue, or some combination of linux+gcc. 
Decreasing the J made it happen less, but maybe that's just because it's 
compiling less? Without a reliable failure case I could not identify it further.


It's *way* more likely that there's a bug in the dependency ordering of 
some modules; a highly parallel build would hit the bug by trying to 
compile a module before its prerequisite. (This also means why running 
make multiple times doesn't help, and actually might make the bug "go 
away" by compiling the prerequisite.)


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] ssl and 5.12 question

2019-01-11 Thread Giuseppe D'Angelo via Interest

Il 11/01/19 12:04, Roland Hughes ha scritto:

Before I kick off a long build to find the answer out the hard way, I
thought I would ask here.

Does 5.12.x compiled on Ubuntu 18.04 support the native SSL library or
do I need to layer on the other one as I did for 5.9.7?


On 18.04 you can install the development packages for OpenSSL 1.0 or 1.1 
(but not both at the same time)¹. Qt can be built using either one, 
configure should automatically find what you've got installed and use it.


¹ But you can install both versions of the libraries at the same time; 
it's the development packages that clash.


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] Qt5 porting woes - metatype with private ctor

2019-01-07 Thread Giuseppe D'Angelo via Interest

Il 07/01/19 21:57, Matthew Woehlke ha scritto:

In Qt4, I implemented this by granting special access to
qMetaTypeConstructHelper to allow Qt's guts to access the "copy"
constructor (which is actually a move ctor, but this code predates
C++11). However, it seems in Qt5 I have to poke into the
QtMetaTypePrivate namespace in order to do this.


This has std::auto_ptr written all over it :-)

--
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] Android IRC channels

2018-12-13 Thread Giuseppe D'Angelo via Interest

Il 13/12/18 10:56, Shawn Rutledge ha scritto:
I would suggest switching to #qt-android permanently, because it follows 
the pattern (we have a lot of #qt-foo channels), whereas necessitas was 
the name of the Qt 4 port to Android. https://necessitas.kde.org/ says 
"Necessitas project was completely merged 
 
into Qt project and KDE Free Qt Foundation Agreement 
 was 
amended  to cover Qt for 
Android Port 
. 
  We suggest you all to to switch to Qt5.” So it seems to me the name is 
obsolete for us, but people could still hang out there and discuss 
issues with other versions (such as the Qt 4 version).


Side note: on Freenode you can simply set one channel to forward to the 
other.


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] efficient natural sorting

2018-11-14 Thread Giuseppe D'Angelo via Interest

Hi,

Il 14/11/18 03:28, Frank Rueter | OHUfx ha scritto:
This works nicely but I’m wondering if it’s reliable and efficient to 
implement it like this in the QSortFilterProxyModel.lessThan() method?!


|def lessThan(self, source_left, source_right): 
natural_keys(source_left) < natural_keys(source_right) |


Any thoughts on this?


You can use QCollator to implement natural sorting (by enabling the 
numeric mode). Or doesn't it work for your use 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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] [Development] QTextEdit - Line Spacing

2018-11-12 Thread Giuseppe D'Angelo via Interest

Il 11/11/18 17:15, coroberti . ha scritto:

Following Allan's advise, here's something that is starting to work
(checks omitted)

QTextDocument* doc = this->text_edit_->document();
QTextBlock currentBlock = doc->firstBlock();

 while (currentBlock.isValid()) {

 QTextCursor cursor(currentBlock);
 QTextBlockFormat blockFormat = currentBlock.blockFormat();
 blockFormat.setLineHeight(200, QTextBlockFormat::ProportionalHeight);
 cursor.setBlockFormat(blockFormat);

 currentBlock = currentBlock.next();
 }

Thank you very much!


Isn't it simpler to use a selection approach instead?

QTextBlockFormat format;
format.setLineHeight(...);

QTextCursor cursor(textDocument);
cursor.select(QTextCursor::Document);
cursor.mergeBlockFormat(format);


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Interest Digest, Vol 86, Issue 5

2018-11-05 Thread Giuseppe D'Angelo via Interest

Hi,

Il 05/11/18 16:07, rol...@logikalsolutions.com ha scritto:

Switching the containers to just be wrappers around std::
implementations would also be a dramatic break.


Assuming by "wrappers" you mean "implicitly shared wrappers", why would 
it be a break?


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt API annoyances: where to log/discuss?

2018-11-05 Thread Giuseppe D'Angelo via Interest

Hi,

On 04/11/2018 00:07, Roland Hughes wrote:

Giuseppe,

I missed the beginning of this thread and don't have enough time for one
of my usual missives. I did want to take issue with the comment about
using C++ latest.

It's _never_ a good idea to chase a standard.


[citation needed], I'm afraid. Every single time I say that "not using 
C++-latest costs more", I do it bringing technical arguments to the 
table, usually quoting which exact new feature or idiom I'm talking 
about (and what would be the advantages in the context of the 
discussion). I don't spread gossip, and I don't embrace the new 
standards blindly.


I'm simply convinced that the adding things to Qt that are also already 
covered in an excellent way by other libraries (_especially_ if it's by 
the Standard Library) simply doesn't justify its work/benefit ratio. And 
this connects to the statement of mine you quoted: if C++2a ships 
ranges, you shouldn't be looking for them into Qt. You should be looking 
for a new compiler. Of course you're free to stick to your current 
compiler, which means not using ranges from the Standard Library, which 
may have a cost for your development.




Please allow a few words of caution from a grizzled old code warrior.

I started programming before we had PCs or a C compiler for them. If you
want a loose interpretation of the time which shortly followed rent
"Halt and Catch Fire" https://www.imdb.com/title/tt2543312/ and follow
it up with "Pirates of Silicon Valley" https://www.imdb.com/title/tt0168122/

Back there and back then we had to chase the standard. The C language
itself didn't provide enough functionality to develop the applications
users wanted and we were mixing memory models trying to make them fit
under the infamous 640K barrier. By the time C++ compilers were
commercially available most compilers were so far afield from any
"standard" that you couldn't write something in Borland C++ with any
hope of it compiling under Microsoft or Watcom and yes, you could switch
the order with the statement still being true.

I used to skim the edge, but I had to because we were writing programs
for IBM "compatible as long as you didn't try to run Flight Simulator"
machines. I even subscribed to Rex Jaeschke's standards tracking blue
magazine back in the day. While I wouldn't say we were friends, we did
exchange emails before we had an Internet and email standard. We did
also exchange emails earlier this year. You can look him up here
http://rexjaeschke.com/  but might be best to dig through old Dr. Dobbs
issues. The dude really worked hard and wrote well. We all worked hard
back then.


Luckily we're not in 1991 (?) any more, we can use more than 640K of 
memory, C++ is very portable, and all major vendors ship compiler 
updates quickly.


 Didn't you hear from Microsoft? They went from being the 
slowest adopter to the fastest -- to this date, MSVC 2017.7 is the 
_only_ C++ compiler that supports the entirety of C++17! That indeed 
shows their commitment! 




Standards bodies have a tendency to jump the shark a bit too often for
my comfort. I came to this realization with the introduction of trigraphs.

https://en.wikipedia.org/wiki/Digraphs_and_trigraphs

P.J. Pluager (we DON'T exchange emails) was hailing their salvation of
mankind in "The C/C++ Users Journal" while many of us grunt coders in
the field were decrying them even being thought about. This was the
result of a select few individuals trying to solve a language problem
with an addition to a programming language. They wanted to make the C
language family "the one" to replace all others. It was the wrong
solution before the idea was even hatched. IBM and a select few others
could not wait for the correct solution, so they slammed through an
ill-formed solution and went merrily on making money. (To this day I
don't know of a single widely available programming editor which will
show you the translation of a trigraph or digraph on your screen.
Somewhere one or two might exist, but they certainly didn't exist when
this egg was laid.)

What was the correct solution you ask? UTF


Sorry, but this does not make any sense at all. Trigraphs were added to 
C because not all encodings, operating systems, editors, or keyboards 
(notably, yes, IBM's, e.g. the 3270 series) had the full set of symbols 
to properly write C code. How does using a different encoding suddenly 
make such keyboards have new physical keys?


Not to mention that trigraphs were added to C before 1989, and the first 
release of Unicode came in 1991, with UTF-1 and UTF-8 coming then in 
1992. Do you have a time machine?


Yes, people "blame" IBM for that. Yes, trigraphs have finally been 
dropped in C++17, although implementations are free to support them 
(source encoding mapping is still implementation-defined, after all).


And anyhow, are we discussing about _trigraphs_, which are purely a 
_backwards-compatibility feature_, in terms of "chasing the latest 
standard"?




There 

Re: [Interest] Chasing a standard

2018-11-05 Thread Giuseppe D'Angelo via Interest

Hi,

Il 05/11/18 12:08, Jean-Michaël Celerier ha scritto:
It's not only about breaking APIs but also breaking current observable 
behaviour - i.e. performance. Currently if you're passing data across 
threads - e.g. compute something in a thread and pass the result to the 
main thread to display it - you generally pass a QVector / QList / 
QWhatever that does implicit sharing, because the signal-slot mechanism 
will do a copy of the object in any case across threads and doing two 
atomic operations for a QVector copy is cheaper than creating a new 
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in 
shared_ptr ?


Hold on -- I don't think that anyone wants to make Qt containers NOT 
implictly shared. In other words, Qt 6 containers will be implictly 
shared just as today. It would be a gigantic break if we suddenly made 
them not shared.


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt API annoyances: where to log/discuss?

2018-11-04 Thread Giuseppe D'Angelo via Interest

Il 02/11/18 19:28, Jason H ha scritto:




The bitwise OR operator, descending multiple namespaces.
It makes my point. That these very common functional programming paradigms 
(map, reduce, etc)  are (needlessly?) obtuse in C++.


Sorry, what is the point? Is it hard to read, write, teach, learn,
understand, extend...? What is the baseline we're comparing it against?


D) All the above. I didn't understand it when I first read it and I would say I "know" 
C++ beyond the 50th percentile of people claiming to "know" C++. I'm sure others won't 
either. Can we get a vote on who understood exactly what that statement was the first time they 
read it? The baseline I'm comparing it against is Python or JavaScript.


Well, I'm sorry, but this isn't an argument, nor a quantifiable metric. 
Fear of the unknown beats comfort of the known every single time.


I could bring the counter argument that since I am a Unix programmer, I 
see a pipe operator, and I can understand what's going on (thing on the 
left being "piped" into the thing to the right) and it brings joy to my 
heart. Maybe I can't grasp its gory details, but I can envision how such 
a thing could be implemented, and I am confident that it can be realized 
without hidden costs nor subtle surprises.


But mine isn't an objective argument, either; we're just going back and 
forth on our own biases, prejudices, pre-existing cultures, flawed risk 
evaluations, and so on.


For a discussion about this, cf. Dan Sacks' keynote at CppCon:


https://www.youtube.com/watch?v=D7Sd8A6_fYU




The value proposition of Qt is that it simplifies a lot of things. If we're going to fall back on "std all the things" then Qt (pronounced "Cute", which I think has meaning here) loses a lot of value prop and I should just switch to C++-without-Qt or Python. 


Not necessarily "std". But Qt ought stop reinventing the wheel where 
such wheels are provided in an excellent way by other libraries out 
there (Boost, Abseil, GSL, to name a few).


There are at least two great ranges libraries available (Boost.Range, 
ranges-v3), one of which -- crossing fingers -- is being used as a basis 
to add ranges into C++2a, there is absolutely ZERO motivation for 
redoing the same kind of work into Qt.


If you're willing to contribute such work to Qt, by all means, go ahead; 
but expect the acceptance bar to be set extremely high.




It is my observation that C++ is becoming a language to not write programs in, but to instruct compilers on how to build your program. (Maybe this is role QML is filling?) 


This is true but up to a certain extent. Zero cost abstractions, "don't 
pay for what you don't use", "no lower language than C++" and similar 
design philosophies, together with widespread adoption in certain 
industries, make Standard C++ evolve slower than other language. 
Sometimes these philosophies also make C++ programming more awkward than 
it should be -- giving you the feeling you're programming at a very low 
level.


Luckily things are evolving. Part of this evolution is what we call 
"Modern C++".




If I have to dedicate hours per week to maintaining my C++latest skills (which 
is futile absent a useful case in my own code base) then that negatively 
impacts my perception of Qt. Which is frankly irrelevant anyway because my code 
needs to be readable **by other people**.


I don't think it's futile. But, anyhow, this is a known struggle in the 
C++ world. We don't have an answer yet, but we keep trying.


See also Kate Gregory's keynotes at MeetingC++ / CppCon:


https://www.youtube.com/watch?v=tTexD26jIN4
https://www.youtube.com/watch?v=n0Ak6xtVXno



I don't know why C++ enthusiasts are so hostile to newcomers, effectively raising the barrier to entry. 


I'm sorry if you had such a negative experience; technical people may 
sound overly aggressive, but from my little corner of experience, the 
broad C++ community is very welcoming. Just try joining something like 
CppCon or MeetingC++ or ACCU.




This plays out in non-abstract terms. C++ is the fastest declining language at 
TIOBE ( https://www.tiobe.com/tiobe-index/ ) over the past 10 years. There were 
no positive spikes around each C++0x release. This stuff is being added and 
it's not attracting users. Meanwhile Python is fastest increasing (at this 
time, it's Java, C, C++, Python, VB.NET) (I do think JavaScript is 
under-reported, as the web is not getting off JS anytime soon)


Which is why Qt for Python is a thing...



Let's look at Python's map/filter/reduce ( 
http://book.pythontips.com/en/latest/map_filter.html )

items = [1, 2, 3, 4, 5]
squared =map(lambda x: x**2, items)
less_than_zero = filter(lambda x: x < 0, items)
product = reduce((lambda x, y: x * y), items)

They are clear and readable.  What are the C++0x equivalents? (I'm really 
asking)


Let me play devil's advocate here, and pretend I'm a C++ developer who 
doesn't know Python. I can see the _intent_ of the above code, but I 
could also start 

Re: [Interest] QDateTime and std::chrono

2018-11-02 Thread Giuseppe D'Angelo via Interest

Il 02/11/18 20:51, Tomasz Siekierda ha scritto:

UTC time, according to docs
https://doc.qt.io/qt-5/qdatetime.html#toMSecsSinceEpoch


So you need C++2a's std::chrono::utc_clock, not C++11's system_clock.

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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QDateTime and std::chrono

2018-11-02 Thread Giuseppe D'Angelo via Interest

Hi,

Il 02/11/18 16:40, Jérôme Godbout ha scritto:

Maybe you can pass by a string, this would be highly inefficient but could be 
simple enough. I guess you should make the time into UTC too. You could use 
QString to std::string for the string stream. And do the following:

std::tm tm = {};
std::stringstream ss("Jan 9 2014 12:35:34"); // Change this for the QDateTime 
toString().toStdString()
ss >> std::get_time(, "%b %d %Y %H:%M:%S");
auto tp = std::chrono::system_clock::from_time_t(std::mktime());

I don't think it's the best solution, but could work easily if performance is 
not an issue. Hope someone have a better plan...


This is a tad overkill, you can use QDateTime::toMSecsSinceEpoch(), 
divide by 1000 and build a std::time_t out of it. (Remember to check for 
overflows, as you don't know what type std::time_t actually is.)


But also, why going down this route? Can't you simply build a 
std::chrono::system_clock::time_point out of a duration? I.e. 
(pseudocode, not tested):



QDateTime dt;
std::chrono::milliseconds duration{dt.toMSecsSinceEpoch()};
std::chrono::system_clock::time_point tp{duration};


Last, but not least, note that std::system_clock is a Unix clock only 
starting in C++2a; before you had no guarantees. Does anyone know if 
QDateTime::toMSecsSinceEpoch() returns UTC time or Unix time?



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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt API annoyances: where to log/discuss?

2018-11-01 Thread Giuseppe D'Angelo via Interest

Hi,

Il 01/11/18 21:14, Jason H ha scritto:

originals | ranges::view::transform([](int i) { return i * 3; });

The bitwise OR operator, descending multiple namespaces.
It makes my point. That these very common functional programming paradigms 
(map, reduce, etc)  are (needlessly?) obtuse in C++.


Sorry, what is the point? Is it hard to read, write, teach, learn, 
understand, extend...? What is the baseline we're comparing it against?




Further more, my point is made qgain with this talk about C++2a. It's something 
that can be done now, but i shouldn't have to wait, Qt can implement these 
however it can today and move to ranges when available.


A bit too convenient to just ask someone else to do a _lot_ of work for 
you... anyhow, you don't have to wait:



https://github.com/ericniebler/range-v3


And again, why should Qt invest precious development bandwidth 
reinventing half-cooked solutions for problems solved in an excellent 
way elsewhere? As I said in the other thread, not using C++-latest costs 
_you_ more. It shouldn't cost anything for Qt.


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt API annoyances: where to log/discuss?

2018-11-01 Thread Giuseppe D'Angelo via Interest

Il 31/10/18 21:59, Jason H ha scritto:
Thanks Giuseppe! That's getting closer :-) however the expression boggles my mind. "originals | ranges::view::transform" there's a lot of compiler voodoo there. I'm trying to keep up on all the C++0xYZ developments, and still trying to wrap my head around SFINAE. I had to look up CTAD, and that looks like a very good enhancement. I think Qt should hide a lot of that compiler iteration from me ;-) 


You can replace Qt with "the libraries I use". They will hide the 
complexity of compiler magic from you (where do you _see_ the magic in 
the lines I pasted?).


And every time you use C++ you have the Standard Library with you, which 
(crossing fingers) will have ranges in C++2a; why should Qt spend any 
time at all implementing something like that?


If anything, this means that QImage should be adapted to be usable 
through ranges (!).




It is an unfortunate phenomenon that I am spending more time decrypting 
compiler Voodoo.


Sorry, I don't get this. If you're just using the features, why would 
you care about they're implemented? What's there to decrypt?


Just rest assured that any feature coming from the Standard Library 
comes from the very same people building your compiler, so it will get 
implemented in the best way 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: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt API annoyances: where to log/discuss?

2018-10-31 Thread Giuseppe D'Angelo via Interest

Il 31/10/18 18:35, Jason H ha scritto:

I attempted this recently, but failed to figure out how to do the following:
QVector triple = apply(QVector {1,2,3},[](item) { return item*3;});
or
QVector originals {1,2,3};
QVector triples = originals.apply([](item) { return item*3;});


You do this:


std::vector originals{1, 2, 3};
std::vector triples = originals | ranges::view::transform([](int i) { 
return i * 3; });


(modulo typos). Possibly even without the , as std containers have 
CTAD.


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Calling QMainWindow::close() vs. clicking on close button in title bar

2018-10-31 Thread Giuseppe D'Angelo via Interest

Il 30/10/18 13:53, Andy ha scritto:
Turns out that if you have a QMainWindow containing a QWindow (e.g. by 
using QWidget::createWindowContainer()):


   - if you call QMainWindow::close(), the QWindow receives QEvent::Hide 
and does the right thing
   - if you click the close button in the title bar, the QWindow 
receives QEvent::Close which calls QWindow::destroy()


This is not what I would expect. Is this by design?

The QWidget::createWindowContainer docs don't mention this as a limitation.


Smells like a bug to me, please report 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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Find frontmost widget of specific type?

2018-10-22 Thread Giuseppe D'Angelo via Interest

Il 22/10/18 23:22, Henry Skoglund ha scritto:

Hi, just an idea, but obviously somewhere deep inside Qt's bowels
(rather, the painting system) there's knowledge of which window obscures
which etc.


There isn't. Compositing window managers have been a reality on desktop 
machines since Mac OS X 10.2 (2002), maybe even before that.


The only really robust approach is asking the WM what are the visible 
windows and their stacking order. Keeping the order in Qt is also 
feasable, modulo of course bugs in the Qt / WM interaction...


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] [Qt3D] Assimp OBJ importer can not import a file with 500MB size

2018-10-16 Thread Giuseppe D'Angelo via Interest

Il 16/10/18 16:26, Saif Suleiman ha scritto:

Hi,
As the title says, i can not import a *500MB* obj file *( 6 million 
vertices and 11 million faces )* using QSceneloader.


I know it's not a solution, but... ditching .obj for such a use case? 
You really want a real 3D format for these sizes (GLTF comes to mind).


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] proper (silent) exit in response to SIGHUP?

2018-10-12 Thread Giuseppe D'Angelo via Interest

Hi,

Il 12/10/2018 10:58, René J. V. Bertin ha scritto:

Did some backtracing in a debugger; I get an almost identical backtrace from the
event loop (and not the signal handler) when I call my slot
- through a QSocketNotifier (after writing to a pipe)
- through a QueuedConnection connection invoked from an emit in the signal
handler

The latter solution also makes it more straightforward to pass the signal number
to the actual handler.

Is this safe? If it is, wouldn't it be a nice little addition to
QCoreApplication?


It's not safe. Emitting a signal with a queued invocation will allocate 
memory. So don't do it from a signal handler.


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] proper (silent) exit in response to SIGHUP?

2018-10-08 Thread Giuseppe D'Angelo via Interest

Il 08/10/2018 09:50, René J.V. Bertin ha scritto:

That sounds real easy indeed ;)


Create a QSocketNotifier on the reading end of the pipe or on the eventfd,
connect its activation signal to a slot that does what you want.

What is the purpose of the pipe/eventfd detour? Can't I just call a function or 
signal a slot directly?



Given we're already in Linux-specific domain, also signalfd(2) comes 
into mind.


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
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Struggling with moveEvent()

2018-10-01 Thread Giuseppe D'Angelo via Interest

Il 01/10/2018 20:11, Murphy, Sean ha scritto:

So I'm not sure what I need to trigger off from to detect when I need to 
reposition the menu. I feel like I'm missing something really obvious, but not 
seeing it on a Monday apparently.


I don't think you're missing anything -- if a widget doesn't move, but 
its parent does, only the parent gets a move event, not the widget.


As a result, for your use case, I believe you need to track move events 
on the whole parent/child chain starting at the window up to your 
widget. I guess you can install event filters for this.


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
http://lists.qt-project.org/mailman/listinfo/interest


  1   2   >