Re: [Interest] L Word

[Giuseppe D'Angelo via Interest]

On 29/04/2021 00:42, Giuseppe D'Angelo via Interest wrote:

If the answer is yes, you were lying. If the answer is no, or you don't
answer, then you're trolling the mailing list. You'll get my apology;
I'll even throw in, for free, my personal congratulations for the long
trolling. But, you'll get a nice permanent ban from here.


No reply. Yes, you're not the only one who can set arbitrary deadlines 
for other people, pal.



I'll just go with the script then: you DID believe those links to be true.

Then, please accept my deepest and most sincere apologies for calling 
you a liar.


I'll state it again, very clearly, all uppercase:

YOU NEVER LIED. I WAS WRONG.

Please accept the attached fruit basket as a gesture of good will.

===

Where does this leave us, then?

At BEST, you have been trolling the mailing list, sending inflammatory 
false content with the purpose of getting a strong reaction from the 
participants.


At WORST, you have demonstrated some abysmal gross incompetence, since 
in order to win an argument you:


* googled some keywords;
* got the first couple of links that seemed to match your thesis;
* didn't even bother to read the contents;
* pasted the links here believing they were true, without questioning 
the veracity of such explosive statements;
* when busted, dug your hole even deeper by keeping arguing in that 
direction.


(...I'm not alone about bringing this possibility forward...)

Spoiler alert, the links were April fools' jokes. They have never been 
true, and it was even written in the articles that they were jokes. With 
such precedents, why should anyone believe *any* other argument you 
bring forward?


===

In either case, it is abundantly clear who's full of shit around here.

It is also clear to me that moderation on this list doesn't exist, or if 
it exists, it doesn't want to get sides, and/or considers these 
behaviours acceptable.


I don't. And I don't send ultimatums or threats of libel lawsuits 
(seriously?) around, including to the moderators, in order to force them 
to make a move.


Hence, I'll be removing myself from this list, effective immediately.


You win. Audience claps. Curtains.

Ad astra per aspera,
--
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] L Word

[Giuseppe D'Angelo via Interest]

On 29/04/2021 00:08, Roland Hughes wrote:


On 4/21/21 5:00 AM, Giuseppe D'Angelo wrote:

On your right: witness B, found to be lying multiple times in the past


I have never lied in here. Been incorrect at times? Most assuredly at 
some point. I have never lied.


https://plato.stanford.edu/entries/lying-definition/

=

(L1)To lie =_df to make a believed-false statement to another person 
with the intention that the other person believe that statement to be true.


L1 is the traditional definition of lying. According to L1, there are at 
least four necessary conditions for lying. First, lying requires that a 
person make a statement (statement condition). Second, **lying requires 
that the person believe the statement to be false**; that is, lying 
requires that the statement be untruthful (untruthfulness condition). 
Third, lying requires that the untruthful statement be made to another 
person (addressee condition). Fourth, lying requires that the person 
intend that that other person believe the untruthful statement to be 
true (intention to deceive the addressee condition).




Fantastic! Let's go with this, with a random example: did you or did you 
not believe that operator new was "deprecated in C++20 and slated for 
removal in C++23", and that smart pointers "most likely they will go 
away with "new.""?



https://lists.qt-project.org/pipermail/interest/2019-December/034245.html


If the answer is yes, you were lying. If the answer is no, or you don't 
answer, then you're trolling the mailing list. You'll get my apology; 
I'll even throw in, for free, my personal congratulations for the long 
trolling. But, you'll get a nice permanent ban from here.




Long ago I came to terms with every Usenet news group or Internet 
mailing list comes one troll with a God complex. They have skin ten 
thousands of an inch thick and consider everything a personal insult. 
For whatever reason, you've chosen to be that here. Fine.


Ha ha ha ha.


What I can't understand is why the moderators haven't yet put you on a 
forced 18+month vacation, especially given all of the emails coming 
around off-list.


Oh really? Have I contacted YOU off-list? Could you produce an example? 
(You may have noticed that my emails are cryptographically signed, so 
good luck with this).


Or someone else contacted you off-list? In which case, you must be so 
lucky at having so many dedicated fans writing directly to you. If only 
they came forward here contributing to the discussions, this mailing 
list would be much more alive.




Here's the thing.

[snip of a huge, nonsensical 


**lying requires that the person believe the statement to be false**

__OR__

You can make amends, here, publicly, and go away for a while whether it 
is imposed or not.


Failing that I will have to pursue this via other avenues.


Get out.


--
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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

22/04/21 20:38, Konstantin Shegunov:
On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest 
mailto:interest@qt-project.org>> wrote:


You should create a C++ layer (call it a "presentation" layer) that
sits
between your (possibly non-Qt) business logic and the UI. That layer
contains stuff like item models, QObjects that expose the relevant
business logic APIs, type wrappers, and so on.


Registering a struct/data class with the meta type system and/or 
marshaling it over QVariant, just so it can be visible in QML isn't 
that. Or things as natural (with C++) as having the UI raise some 
encapsulated piece of data in a signal (say some struct, say QColor or 
QVector3D) which the backend responds to isn't it either.


I think I'm missing some context: when you say "isn't that" or "isn't 
it", what "that"/"it" are you referring to?



 As a matter of 
fact, how do you tie your existing backend to QML? Say we have this nice 
encapsulated UI that's completely decoupled from the business logic, how 
do I tie a specific object from the Quick scene and connect the 
notifications back to C++? I can't do it from the business logic (i.e. 
controller side), I have to expose the backend to the QML engine and do 
it from there, am I wrong? Basically you say it's fine that the UI 
drives the controller (incl. object creation)?


"Controller" is an extremely overloaded word. Could you please clarify 
what design are you referring to?


I don't understand some of your points, like "UI that's completely 
decoupled from the business logic". What does this mean -- shouldn't the 
business logic be the one decoupled from the UI? Are you talking about 
UI testing (via a mock business implementation)?





We can agree on the principles, gladly, but this is really a gross 
oversimplification of the problem.


Sure it is! I said it myself, it's typically not just one magic 
do-it-all layer, but multiple layers. In those layers you


* adapt business logic datatypes into Qt datatypes;
* write Qt models wrapping business logic datasets;
* expose the relevant business logic in QObjects;
* create custom UI components;
* write state machines and what else is necessary to drive the UI based 
on the business logic state;


and so on. All/most of this gets done in C++. Some other bits may be 
done in QML, if it makes sense. The important message here is that such 
adaptation / UI logic layers do exist in any non trivial application, 
and the fact that from QML you just can't "just" reach into business 
logic, you need to jump through the language border, giving you a 
significant chance of making the integration more "clean".






While building this layering may be super tedious (YMMV), in the long
run, it makes your application more robust, not less. The fact that QML
_forces_ you to have this stuff becomes somehow a good thing.


Forces you? Do you mean, perhaps, that JS is somehow not supported, or 
maybe that Component.createObject is somehow hidden and/or inaccessible?


... I don't see how using JS magically allows you to call functions into 
your C++ business logic?





On widgets, well, raise your hand if you didn't at least once connect a
QPushButton to a slot declared in the widget that contains the button,
and perform some business logic from there (yay business logic in
the UI!).


Yes, it is done, and not without an honorable mention of the 
documentation, where the view-controller idiom is used extensively.  But 
then, raise your hand if you at least once didn't use an `if` (or some 
other JS piece of code) in a QML file. I can pull out for you numerous 
cases of it being done, probably too numerous to count even in the 
examples. Shooting yourself in the foot is not restricted to one 
language or another, nor to the technological solution in use is my 
point.


"You can write FORTRAN in any language".

The point I was trying to make is this: you need to write some degree of 
QML/C++ integration code to make the two worlds communicate. This, at 
least, gives you an excellent chance of clearly separating UI from 
business logic. That chance doesn't guarantee not doing a complete mess, 
but at least it's there.


(Then, as I said, you should also write most of your _UI logic_ itself 
in C++ as well. And now we have at least two layers. And so on an so forth.)


Now, am I saying that the C++/QML integration is absolutely perfect and 
you'll never write cleaner UI code? Of course not, there's still tons of 
shortcomings and annoyances that will make you say "sigh" and take 
shortcuts here and 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 crit

Re: [Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 22/04/2021 17:06, Rui Oliveira wrote:
Q_INVOKABLE, Q_PROPERTY, etc... The Qt stuff crawls into what would 
otherwise be just business logic because you need to access something.


I've linked this before: 
https://stackoverflow.com/questions/66618613/qml-c-classes-with-bring-your-own-component


Which again, is absolutely trivial do to with C++ and polymorphism. And 
a pointer/reference instead of adding macros in 20 places  and the 
Q_PROPERTY lines...


Basically we're coupling the whole backend to the GUI framework.



Wait, this sounds precisely what you shouldn't do.

You should create a C++ layer (call it a "presentation" layer) that sits 
between your (possibly non-Qt) business logic and the UI. That layer 
contains stuff like item models, QObjects that expose the relevant 
business logic APIs, type wrappers, and so on.


(Possibly even more layers. Like an cake. Or an ogre)

This way

* the business logic is agnostic of the UI framework used above (could 
be Widgets, could be Qt Quick, could be HTML)


* you can do UI testing by swapping out the business logic with a 
testing one


* you can test the business logic without the UI

and so on.


While building this layering may be super tedious (YMMV), in the long 
run, it makes your application more robust, not less. The fact that QML 
_forces_ you to have this stuff becomes somehow a good thing.



On widgets, well, raise your hand if you didn't at least once connect a 
QPushButton to a slot declared in the widget that contains the button, 
and perform some business logic from there (yay business logic in the UI!).


And/or thought "ok, I should add a controller for the UI layer that 
talks to these other 5 objects, and does this and that, and gets 
triggered by the button... or I could just #include 
"Component_Deep_Into_Business_Logic.h" and just call a method on it.". 
You know, "a little goto never hurt anyone". (Velociraptor ensues)



In other words, being "entirely" in C++ has also its downsides.

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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 22/04/2021 15:57, Jérôme Godbout wrote:
I wonder if it would be possible to totally declare the QtQuick scene 
from C++ without any Qml files actually, with Qt6 you got C++ binding 
and the Qml is compiled to C++ anyway. Maybe I miss something but it 
could be possible to actually only write C++ to create the actual scene?!




"Could" it be possible? Certainly yes, but Qt Quick never wanted to 
provide a public C++ API, only a public QML one. (Why? No idea, wasn't 
there in the room when it was decided; likely, having the freedom of 
rearrange the C++ implementation, which clashes against the strong 
API/ABI promise of Qt. Only the QML API is stable.)


AFAICR, QSkinny is an example of creating Qt Quick scenes from C++.

Of course, scene creation is just one of the aspects, you'd also then 
really want to reimplement C++ the other goodies you get in QML (e.g. 
bindings, Behavior, etc.), some of which are now coming in Qt 6.x.


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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 22/04/2021 14:55, Rui Oliveira wrote:

I know Giuseppe D’Angelo isn't a TQtC employee, but I trust KDABs stuff
in general.

https://www.qtdesktopdays.com/wp-content/uploads/2020/09/keynote.pdf

Slide 19 "Accelerate widget rendering & compositing through RHI", or I
didn't understand something?


In fact, see https://bugreports.qt.io/browse/QTBUG-74407 and related tasks.

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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 22/04/2021 13:01, Bernhard Lindner wrote:

You explained why the widgets concept is not compatible with the Quick concept. 
Can you
also explain why it was not possible to implement Quick as an additional, 
mostly widget-
independent C++ layer and then wrap it declaratively?


Do you mean, also offer C++ APIs for Qt Quick? (As well as the QML APIs 
you have today.)


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] Help a unix guy on windows qmake

[Giuseppe D'Angelo via Interest]

On 21/04/2021 19:14, Thiago Macieira wrote:

qmake does not expand environment variables at all.

$ X=A qmake Y=b /dev/stdin -o /dev/null <<<'message(r = $X $$Y)'
Project MESSAGE: r = $X b


AFAIK, there's distinct syntax for everything:

$$X is a qmake variable called X
$$(X) is an environment variable called X (evaluated when qmake is ran)
$(X) is an environment variable called X (evaluated when make is ran)

But no $X. I'm still not sure what $PROJ means.

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] Help a unix guy on windows qmake

[Giuseppe D'Angelo via Interest]

On 21/04/2021 17:49, Jason H wrote:

What is the proper scope? Allegedly these are listed in 
C:\Qt\$ver\$compiler\mkspecs, however there are no win64 ones. I'm using mingw.


mingw is the proper scope. When in doubt, look at Qt's own sources.


src/angle/src/libEGL/libEGL.pro
19:mingw:equals(QT_ARCH, i386): DEF_FILE = 
$$ANGLE_DIR/src/libEGL/$${DEF_FILE_TARGET}_mingw32.def

src/angle/src/libGLESv2/libGLESv2.pro
9:mingw: equals(QT_ARCH, i386): DEF_FILE = 
$$ANGLE_DIR/src/libGLESv2/$${DEF_FILE_TARGET}_mingw32.def




Why is there no $PROJ variable for linking when shadow building?
$PWD resolves to the shadow build dir, it seems?
How do I properly refer LIBS to $PROJ/libraries/x64/mylib.lib?
How do I properly refer INCLUDEPATH to $PROJ/libraries/mylib.h?
You know what $PROJ means, but for some reason this concept doesn't exist in 
qmake yet?


I... don't quite know what $PROJ means *for you*? :)

Do you mean $$OUT_PWD? Do you mean $$shadowed($$PWD)?


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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 21/04/2021 16:10, Rui Oliveira wrote:

Black Mesa Source?! Now that's an interesting one haha!



Yep, https://steamdb.info/depot/362894/ shows some familiar names in the 
installed libs. (That having been said, Qt is used only in the menus 
AFAIK :-))


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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 21/04/2021 17:42, Jason H wrote:
Personally, I think the exsting QtQuick element should be scrapped and 
just focus on QML versions of the existing Widget functionality. I love 
the QML syntax, hate that it's not just a layer on top of widgets.

That said, I still really like both.


Do you mean something like this

https://github.com/KDAB/DeclarativeWidgets

or actually reimplementing the widgets themselves?

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] Question about QtDeclarative Internals

[Giuseppe D'Angelo via Interest]

Hi Alex,

On 21/04/2021 15:48, Alex Shaw wrote:
I am relatively new to mailing lists, so if I am doing something wrong 
here please forgive me.


Is this the place to ask questions about the internals of Qt modules?


I'd actually recommend you to ask this question on the development@ 
mailing list. That's what most developers of Qt lurk. (interest@ is 
people who develop WITH Qt.)


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] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 21/04/2021 14:37, eric.fedosej...@gmail.com wrote:

Where are the examples of real QML desktop applications on The Qt Co. website? 
I did a quick walk through the customer showcase and cannot find them.


Well the question was about embedded :)

I'm not sure where to find QML on desktop stories, there's however a 
showroom https://showroom.qt.io/ where people can leave links to their 
applications.


These days you'll find QML in a bunch of a desktop applications, from 
Autodesk's to Zoom to Musiscore to VLC-next to Black Mesa Source. 
There's been a few  interesting talks at the past Qt Desktop Days (about 
Scrite, VLC, KDE and so on; check out the videos, they're all on 
Youtube) and some customer showcases at the past (in person) Qt World 
Summits.


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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 115, Issue 17

[Giuseppe D'Angelo via Interest]

On 20/04/2021 23:55, Roland Hughes wrote:


On 4/20/2021 4:35 PM, Giuseppe D'Angelo wrote:

On 20/04/2021 15:10, Roland Hughes wrote:

On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.

It's completely true. That tiny subset on the Web site doesn't scratch
the surface.

So there's even*MORE*  QML used in embedded than what's advertised on
TQC's website? That's great news!

I know it is difficult for you, but don't be an ass.



Or how about plain English? I'll put it in a better format:

ORIGINAL QUESTION:

"I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about..."

YOUR answer:

"Just phones and John Deere."

MY answer:

"This is false, as a quick walk through the customer showcase on TQC's
website will show."

YOUR answer:

"It's completely true. That tiny subset on the Web site doesn't scratch
the surface"


Conclusions from YOUR answer: there's many more people using QML than
the tiny subset of customers represented on TQC's website. "That tiny
subset on the Web site doesn't scratch the surface".

Which not only is what I was saying before; but it's also true, and it's
also in direct contradiction with "Just phones and John Deere.".



This is also false. SXs have never been defective CPUs.

You need to actually learn processor history or at least do some
research before you speak.

The 486SX was a marketing quirk. Intel had a high failure rate (low
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX.
When it failed testing it went down another line where they "cut some
pins" so the chip couldn't communicate with the bad FPU, put an SX on it
and sold scrap at a discount.
This has widely been debunked.

The SXs were introduced to the market_years_  after the introduction of
the DXs. Intel didn't start to have massive production problems all of a
sudden and thus decided to pull this stunt. The SXs were_designed_  to
have the FPU disabled, and their FPU was for this reason ever tested.
The only reason for the introduction of the SX was market segmentation
to compete against AMD.

Here's some links for you, given you seem to able to Google "486 sx
defective" (and leave it in the URLs that you link), but somehow
conveniently IGNORING the first couple of results, even if they include
first-hand accounts of Intel engineers who worked on the 486 that
disprove the whole defective story:

http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked
doesn't talk about those chips being "defective" DXs?
Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX

Nothing in your links debunks anything, 



Yeah, right, don't read them, don't even quote sentences from them, and
try to disprove them.

except your ability to do 
research.


Yay, personal insults, let's go!

I was at Digital Equipment Corporation when they were 
designing their 486 "Dandy" The Digital Tandy and that is __exactly__ 
what Intel told the engineers. It took more than a year of DX "low 
yield" before there was enough chips to make setting up a line to "fix" 
them worth while.



Ah ok. Thanks for NOT mentioning it before before dumping all the Google
results (well, all except the ones that disproved your thesis).

So, who should we believe?


On your left, witness A: an Intel engineer who claims to have directly
worked on the project. Now we can't easily verify that (and I don't want
to bother the person by writing directly). Witness A brings the
following evidence:

* The SX had been introduced 2 years after the DX, signalling no
production problems whatsoever (which if anything should've appeared
earlier in the process).

* The FPU had simply been disabled via a pin in the package. Technically
noone knows if they were _actually_ defective because they were not
tested at all, since the dies were built from the start to be SXs.

* The silicon process makes it very unlikely to get "just" a defective
FPU and not also affect the rest of the chip. And even if you get "just"
a defective FPU, a constant error in the fabrication process is not
something you would be fine with (the source of the defect may spread to
other components).

* The driving factor was offering a cheaper product in order to fight
competition from AMD (simple fact given the market shape at the time).



On your right: witness B, found to be lying multiple times in the past
(I like your selective quoting, by the way). Witness B says there's some
hearsay about this, back in the day, from someone at Intel. Now we can't
verify this either -- even in the crazy hypothesis of admitting hearsay
in court. But no other evidence is brought forward, nor any reasoning
about 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 20/04/2021 15:10, Roland Hughes wrote:


On 4/20/2021 5:00 AM, Giuseppe D'Angelo wrote:

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere.

This is false, as a quick walk through the customer showcase on TQC's
website will show.
It's completely true. That tiny subset on the Web site doesn't scratch 
the surface.


So there's even *MORE* QML used in embedded than what's advertised on 
TQC's website? That's great news!



It certainly doesn't encompass my customer base and I 
haven't heard anyone pipe up on here using QML for anything 
non-significant that wasn't phones or John Deere. 


Ah ok, since *you* never saw QML used on embedded projects, then it 
doesn't exist. How silly of me assuming otherwise.




QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX

This is also false. SXs have never been defective CPUs.


You need to actually learn processor history or at least do some 
research before you speak.


You need to learn to use Google before you speak.

Or actually, better not: last time you used Google you fell for *two* 
April fools' blog posts, claiming they were true. For that, we haven't 
received apologies yet. So who tells us that it's different this time?



https://lists.qt-project.org/pipermail/interest/2019-December/034255.html




The 486SX was a marketing quirk. Intel had a high failure rate (low 
yield) on the FPU. When a CPU passed DX testing it was sold as a 486DX. 
When it failed testing it went down another line where they "cut some 
pins" so the chip couldn't communicate with the bad FPU, put an SX on it 
and sold scrap at a discount.


This has widely been debunked.

The SXs were introduced to the market _years_ after the introduction of 
the DXs. Intel didn't start to have massive production problems all of a 
sudden and thus decided to pull this stunt. The SXs were _designed_ to 
have the FPU disabled, and their FPU was for this reason ever tested. 
The only reason for the introduction of the SX was market segmentation 
to compete against AMD.


Here's some links for you, given you seem to able to Google "486 sx 
defective" (and leave it in the URLs that you link), but somehow 
conveniently IGNORING the first couple of results, even if they include 
first-hand accounts of Intel engineers who worked on the 486 that 
disprove the whole defective story:


http://www.os2museum.com/wp/lies-damn-lies-and-wikipedia/

By the way, did you notice that the Wikipedia page that YOU linked 
doesn't talk about those chips being "defective" DXs?

Because that's a lie, as discussed in the talk page:

https://en.wikipedia.org/wiki/Talk:Intel_80486SX




All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier. On
the surface it seems like someone talked to people who write software on
big computers before work started. Need to dig deeper to be really
certain, but you communicate with a "loader" that can support many revs
of the API.

Are you aware that Qt has had Vulkan integration classes since 5.12 (?),
and Vulkan can be used as a Qt Quick backend in Qt 6?

The ability of painting from multiple threads (or better, to build
command buffers from multiple threads) doesn't magically solve the
problem of manipulating data structures safely from multiple threads.
The single threaded CPU-based_painting_  of the syntax highlighting has
hardly ever been an issue; its_generation_  has, as it involves
modifying a shared data structure (while also the user is modifying it)
without races and without locking against the GUI thread. QTextDocument
design is unlikely to fit the bill here; a different design sounds
anything but easy, but the underlying graphics API has very little to do
with this.


The API has a ___lot___ to do with this as the dude putting out 
featherpad is learning the hard way and every editor developer 
attempting to use Qt and only Qt before them. The single-thread-i-ness 
hits a hard wall. That's the biggest issue.


That is followed by all of the "why would anyone have done __that__" issues:

like burying the selection active inside a private internal class and 
basing it on the difference of cursor position thus making it physically 
impossible to follow numerous time honored editor traditions of Mark> . Unless you gut the class and redevelop from scratch 
you can't have an N-key key sequence for begin mark and have the editor 
class understand a selection has been enabled even though there is zero 
cursor difference.


Close on the heels of that "Why are they highlighting the whole thing?" 
when you only need the currently visible lines and possibly a screen 
up/down. Open up a 10,000 line source file in editors 

Re: [Interest] Guide me through the Qt offerings for GUIs

[Giuseppe D'Angelo via Interest]

On 18/04/2021 14:50, Roland Hughes wrote:

I guess QML is more present in embedded? Or maybe some entreprise stuff
we don't know about...
Just phones and John Deere. 


This is false, as a quick walk through the customer showcase on TQC's 
website will show.




QML was a bad idea trying to get around a legacy problem without
actually fixing the legacy problem. The legacy problem is the single
thread-i-ness of Qt. Back when Intel was selling 486 chips with a
manufacturing defect as SX


This is also false. SXs have never been defective CPUs.




All of this is why I'm so excited to read about the Vulkan stuff going
on with the CsPaint library and the Vulkan links I sent you earlier. On
the surface it seems like someone talked to people who write software on
big computers before work started. Need to dig deeper to be really
certain, but you communicate with a "loader" that can support many revs
of the API.


Are you aware that Qt has had Vulkan integration classes since 5.12 (?), 
and Vulkan can be used as a Qt Quick backend in Qt 6?


The ability of painting from multiple threads (or better, to build 
command buffers from multiple threads) doesn't magically solve the 
problem of manipulating data structures safely from multiple threads. 
The single threaded CPU-based _painting_ of the syntax highlighting has 
hardly ever been an issue; its _generation_ has, as it involves 
modifying a shared data structure (while also the user is modifying it) 
without races and without locking against the GUI thread. QTextDocument 
design is unlikely to fit the bill here; a different design sounds 
anything but easy, but the underlying graphics API has very little to do 
with this.


--
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] [EXTERNAL] Re: Send Data to JavaScript

[Giuseppe D'Angelo via Interest]

Il 14/04/21 16:15, Jérôme Godbout ha scritto:
Yeah that would be a pain, but if it work you can try to reduce the 
QVariant usage to a minimum from that point.


 1. QVariantMap
 2. QMap
 3. QMap
 4. QMap
 5. QMap>
 6. QMap>

See up to where you can reach before it fail, it will tell you which 
data type is not working for the type mapping. If they all succeed, then 
something might be wrong with the QList or QStringList if you 
prefer. Maybe the exposed type doesn’t handle the typedef properly when 
nested.




A mandatory note: a QVariant can hold _any_ data type (even 
application-defined ones). That doesn't mean you can send a QVariant 
over to JS and expect to magically manipulate its contents from over 
there. Only QVariants with _specific_ contents work.


(For comparison, in QML, all the ones with unsupported content become a 
`var` blob, that you can only copy around and eventually pass back to 
C++; but they're unusable from QML itself).


So although you can store a QMap in a QVariant, 
that doesn't mean it magically works because of the wrapping.


If the docs are not conclusive about which datatypes work and under 
which conditions, do the simple tests suggested above (exposing 
progressively more and more "complicated" types); that should quickly 
help figuring out what is actually supported and what not.


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] [EXTERNAL] Re: Send Data to JavaScript

[Giuseppe D'Angelo via Interest]

Il 12/04/21 15:56, John Schneiderman ha scritto:

On 12.04.2021 15:35, Giuseppe D'Angelo via Interest wrote:

Are you sure about the transformation? Only certain data types are
supported for the C++ <-> QML data exchange, and I don't believe the
one you're using is:

I'm not using QML in this particular case. I'm using QWebEngine and
QWebChannel for communication between C++ and the JavaScript running.


I'm sorry, I must've misread.

But a similar consideration applies: do you have any documentation 
telling you how datatypes in C++ are mapped to datatypes in JS -- and 
thus if your QMap is supposed to be supported, or 
if instead you need to "massage" it a bit?


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] Send Data to JavaScript

[Giuseppe D'Angelo via Interest]

On 12/04/2021 15:17, John Schneiderman wrote:


What I'm expecting is that mappings would be transformed on the
JavaScript side as:

mappings {

      "key" : ["abc", "def"]...

}

However, when I try to view the data in the emitted signal it's always
null. Any suggestions where I should look for more answers or perhaps
I'm going in an incorrect direction?


Are you sure about the transformation? Only certain data types are 
supported for the C++ <-> QML data exchange, and I don't believe the one 
you're using is:


https://doc.qt.io/qt-5/qtqml-cppintegration-data.html

In other words, you may need to change the datatype / transform it 
somehow before giving it to QML. (Also do you want to just _read_ it 
from QML or also write into it? The above QML syntax looks a bit sketchy...)



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] the path forward - that 7 year thing - was, , , willy-nilly

[Giuseppe D'Angelo via Interest]

On 12/04/2021 13:59, Roland Hughes wrote:


On 4/2/21 5:00 AM, Giuseppe D'Angelo wrote:

(Is there a conflict of intents here because of the massive support to
the Qt Project? I can't see how -- if anything, one could say that the
commercial decisions may drive the decisions in the Qt Project,
certainly NOT that the Qt Project has the power to "sabotage" the
commercial decisions!)


Well, when you dropped RHEL 6 you sabotaged commercial support for it.


And who's "you" here? And how exactly did that sabotage a commercial 
contract between you and whoever entity gives you commercial support on 
RHEL6?





Try fully ripping out QML. Not just conditionally compiled out. Not just
"don't use it." Fully rip it out of the OpenSource product and all
support for it such that QtC has to add it back in for every release.


How about trying triple cooked chips?

Not just conditionally double cooked chips. Not just pre-fried chips. 
Fully triple cooked, first simmered, then deep fried at low temperature, 
then deep fried at high temperature.


Supported forever.

I'm sure Opensource Qt would thrive with some triple cooked chips added 
to every release.





  >The combination of monitor+Qt is by definition part of the environment
(as far as the end-user application is concerned). Changing a monitor is
changing the environment.

No, it's not.


It is. Triple stamped, no erasies, touch blue make it true.
LA LA LA LA LA LA LA LA.




  > But wait, don't your practices tell you that you should've run a risk
analysis, filed in the holy 29 documents (all named with fancy
acronyms,I'm sure), get an independent certification and applied the new
cover sheet on your TPS reports (didn't you get the memo?) before
approving the purchase of a new monitor model on a life-critical
workstation?

That statement makes it painfully obvious you never learned Software
Engineering.


Oh, so we're back at the personal insults, I see.



No. Replacing one monitor with one of equal or higher capability does
not meet definition of RISK. "Screens look like crap" does not meet the
definition of RISK.


Good. Then run the 4K display in full HD, it will look like crap, but 
not meet the definition of RISK so nothing to complain about.


Or run it in 4K, don't enable HiDPI, it will look like crap, but not 
meet the definition of RISK so nothing to complain about.




Note for readers of the list: the above was sarcasm. Not only changing a 
monitor is changing the environment, it's also something that may simply 
not work out of the box. (But what do I know, I've never learned True 
Software Engineering™).


To give you an idea: 4k MST displays may require Xorg and kernel 
upgrades on older systems, without which they may not work at all / work 
only at limited resolutions or refresh rates / appear as two monitors 
instead of one, confusing WMs and applications / display an image on 
just one half of it rather than the entire monitor. So purchasing a 
random 4k monitor, and calling it "low risk", is a total falsehood.




Still wondering why the moderators are sleeping,
--
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] Are Qt.transparent and "transparent" different colors?

[Giuseppe D'Angelo via Interest]

On 07/04/2021 12:09, Tor Arne Vestbø wrote:

Yes, please file a bug about this.


https://bugreports.qt.io/browse/QTBUG-92588

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] the path forward - that 7 year thing - was, , willy-nilly

[Giuseppe D'Angelo via Interest]

On 01/04/2021 16:13, Roland Hughes wrote:


On 4/1/21 8:46 AM, Giuseppe D'Angelo wrote:

On 01/04/2021 13:40, Roland Hughes wrote:

We keep discussing the ability to upgrade Qt but not upgrade the rest of the
OS. I understand that Qt is a central component of the UI, but it's no less
critical than a lot of other components that you may need to upgrade in order
to deal with circumstances changing.

What you are describing is __exactly__ why companies buy commercial
licenses and pay for support contracts. They pay to have their
environment supported and not be told that they have to replace their
environment.

The terms of the Qt support with a commercial entity (being it TQC or
anyone else) have nothing to do with the Qt project decisions.


Yes, they do.

Is QtC providing code to Qt project? Is it providing hosting and
distribution services for the OpenSource code? Is it providing any other
financial support?

When the answer to any of these is yes, then what they need has a lot to
do with your decisions. When they need to support a platform for 15+
years and you rip it out after 6-7 _that_ is a real problem.


Does TQC provide hosting and other technological services for the Qt 
project? Yes, they do (thanks TQC!).


Does TQC provide the majority of code in the Qt project, and employ the 
biggest work force, therefore having a significant say in the Qt Project 
decisions? Yes.


Does TQC also provide commercial support contracts? Yes.

(Is there a conflict of intents here because of the massive support to 
the Qt Project? I can't see how -- if anything, one could say that the 
commercial decisions may drive the decisions in the Qt Project, 
certainly NOT that the Qt Project has the power to "sabotage" the 
commercial decisions!)


But the terms of your commercial Qt support with TQC (or with anyone 
else for that matter) don't change depending on the Qt Project 
decisions. (And even if they did, then you've got nothing to complain 
about -- you _signed_ for that.) If your contract with TQC says that you 
have the right of getting 15+ years of support for some given Qt 
versions on some given platforms, then you get those, or you go to 
court. This has nothing to do with what the Qt Project decides to do in 
the meanwhile, including dropping those platforms after 6-7 years.







And, by the way, we're describing scenarios where the environment*has*
changed: new hardware, new platforms, new toolchains. You're negating
the premise, and thus the argument is a fallacy.


No, your argument is the fallacy (which is not unusual.)

They replaced a *monitor* with another computer monitor that the
platform obviously supported. That's it. The video card obviously
supported 4K as did the video driver. If the *environment* maxed out at
1920xwhatever Scott wouldn't have been screwed. He and his company got
screwed because the high DPI support with the Qt they have was not good.
Between "good enough" and what they currently have his platform got dropped.

The platform already supported all of this. The Qt code did not.



The combination of monitor+Qt is by definition part of the environment 
(as far as the end-user application is concerned). Changing a monitor is 
changing the environment. If the definition of "supported" is "I connect 
it and it runs at 4K", then of course it's supported: you get the 
_native_ 4K from your Qt application, and no hidpi scaling.


But wait, don't your practices tell you that you should've run a risk 
analysis, filed in the holy 29 documents (all named with fancy acronyms, 
I'm sure), get an independent certification and applied the new cover 
sheet on your TPS reports (didn't you get the memo?) before approving 
the purchase of a new monitor model on a life-critical workstation?



(In all seriousness, of course I'm unhappy as the next person about the 
status of hidpi and Qt, and not too happy that one needs 5.15 for 
getting the bugfixes, which in turn has higher platform requirements. 
But this has nothing to do with someone having a commercial contract for 
pre-5.15 and thus with the power to get their commercial partner to 
backport those bugfixes or improvements.)



--
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] the path forward - that 7 year thing - was, willy-nilly

[Giuseppe D'Angelo via Interest]

On 01/04/2021 13:40, Roland Hughes wrote:


We keep discussing the ability to upgrade Qt but not upgrade the rest of the
OS. I understand that Qt is a central component of the UI, but it's no less
critical than a lot of other components that you may need to upgrade in order
to deal with circumstances changing.

What you are describing is __exactly__ why companies buy commercial
licenses and pay for support contracts. They pay to have their
environment supported and not be told that they have to replace their
environment.


The terms of the Qt support with a commercial entity (being it TQC or 
anyone else) have nothing to do with the Qt project decisions.


And, by the way, we're describing scenarios where the environment *has* 
changed: new hardware, new platforms, new toolchains. You're negating 
the premise, and thus the argument is a fallacy.



--
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] QtQuick over Qt3D (Qt 5.15)

[Giuseppe D'Angelo via Interest]

On 31/03/2021 17:31, eric.fedosej...@gmail.com wrote:
Qt3D was introduced in 2016 to much fanfare and was going to be the 
primary 3D solution for Qt. The idea was that Qt3D would provide a 
high-performance core capable of modern 3D graphics. Then, in 2017, Qt 
Co. had a philosophical shift and realized that rather than offering 3D 
functionality through LGPL/C++ (which could also be used by those darned 
open-source users), they could make more money in the short-term by 
locking in John Deere/others into subscription-based commercial 
licensing to display their little tractor animations. 


It's the Nth time that a certain company gets nominated without any 
reason whatsoever w.r.t. the thread in question, and in statements 
without any factual grounding (aka [citation needed]).


(In another instance, even stronger, derogatory wording has been used in 
another totally unrelated context.)


Not only all such mentions are therefore against netiquette and 
off-topic for this list (we don't discuss hearsay, we discuss how to use 
Qt), they're borderline libellous and may cause the Qt Project to having 
to protect itself and shut these lists down.



In not so many words: STOP IT 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: S/MIME Cryptographic Signature
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 114, Issue 42

[Giuseppe D'Angelo via Interest]

On 28/03/2021 20:39, Roland Hughes wrote:

On 3/28/21 12:54 PM, Giuseppe D'Angelo wrote:

Il 28/03/21 13:54, Roland Hughes ha scritto:

There is documentation and Web pages that have
replicated all over stating Qt 5 supports RHEL 6. You made something
that cannot be effectively erased untrue.

The documentation in question states that_specific_  Qt 5.x versions
support RHEL 6. There's no such thing as "Qt 5 documentation".

And ___THAT___ is the documentation and glossies management looked at
when it made the decision to use Qt in the first place. It got specified
in the Software Architecture Document.


And T H A T documentation states which Platforms are Supported 
by a given version of Qt, and also for how long that given version of Qt 
is supported by the Qt project itself.


Anyone over-promising based on that information has only themselves to 
blame.


So what is this thread about, again? A bunch of fancy acronyms?

--
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] the path forward - that 7 year thing - was, willy-nilly

[Giuseppe D'Angelo via Interest]

Il 28/03/21 13:54, Roland Hughes ha scritto:

There is documentation and Web pages that have
replicated all over stating Qt 5 supports RHEL 6. You made something
that cannot be effectively erased untrue.


The documentation in question states that _specific_ Qt 5.x versions 
support RHEL 6. There's no such thing as "Qt 5 documentation".




Management: "Qt 5 supports RHEL 6 and Qt has been around twenty years so 
you will use Qt for the UI and much of the application."


Developers: "Okay. You're the boss." [...]


Wait, weren't you the guy saying that agile is bad and you should get 
324 documents cross-checked and triple stamped before writing one single 
line of code? I assume "trust inaccurate hearsay" and "make gross 
generalization" are in those documents?



Not amused at all,
--
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] the path forward - that 7 year thing - was, , willy-nilly

[Giuseppe D'Angelo via Interest]

Il 28/03/21 15:52, Jason H ha scritto:

But it's now under the marketplace license?
https://marketplace.qt.io/collections/most-popular/products/qtpdf ($49/ 
Marketplace license)


QtPdf is still LGPLv3:


https://code.qt.io/cgit/qt-labs/qtpdf.git/tree/



AFAICS, the only thing you're paying for on the marketplace is the 
convenience of being prebuilt, rather than building it from sources 
yourself.


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] QML Image sourceSize bug (?)

[Giuseppe D'Angelo via Interest]

On 27/03/2021 15:46, Alexander Dyagilev wrote:


If I enable mipmap, it looks much better comparing to original variant,
but still worse comparing to the final one (described in my original
posting).

I can provide you all the screenshots if you want to.


I can only entertain that mipmapping in your case is going to use 
trilinear interpolation (*) between the 32x32 and the 16x16 mip. And, 
for your particular image ("artwork" / "icon"), that is giving you worse 
results than a 27x27 image scaled directly from the source via bilinear 
interpolation.


There's not much to do about this:

* mipmapping allows you to keep a good visual quality if the displayed 
size of the image changes
* sourceSize allows you to get a good scaled-down version and save on 
memory, but will look awful if now you try to make the image bigger again


(*) didn't check the actual code, just assumed a GL_LINEAR_MIPMAP_LINEAR 
setting.



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] Are Qt.transparent and "transparent" different colors?

[Giuseppe D'Angelo via Interest]

On 27/03/2021 11:58, Alexander Dyagilev wrote:

Hmmm... What is this enum for then?



In C++ APIs, it's used in QColor's constructor.

In QML, enumeration types are strange beasts (and I wish they weren't), 
sometimes being enum and sometimes being integers. I suggest to open a 
bug report suggesting to add a Qt::Color -> color type construction 
(assuming it's possible), because it's indeed supposed to "just work". 
(On the other hand, clearly, int->color should never work.)


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] QML Image sourceSize bug (?)

[Giuseppe D'Angelo via Interest]

On 27/03/2021 11:56, Alexander Dyagilev wrote:

No.

On 3/27/2021 1:24 PM, Giuseppe D'Angelo via Interest wrote:

On 27/03/2021 04:20, Alexander Dyagilev wrote:

Looks better. Why is it so?


Did you enable mipmapping for the first one? 


Well, does it improve it you enable it?

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] Are Qt.transparent and "transparent" different colors?

[Giuseppe D'Angelo via Interest]

On 27/03/2021 07:00, Alexander Dyagilev wrote:

Rectangle {color: "transparent"} - getting transparent rectangle


This is fine.


Rectangle {color: Qt.transparent} - getting rectangle filled with white
color


This one is illegal. You can't set an enum or an int to a "color" type 
in QML.


https://doc.qt.io/qt-5/qml-color.html

You are getting an error message on the console.

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] QML Image sourceSize bug (?)

[Giuseppe D'Angelo via Interest]

On 27/03/2021 04:20, Alexander Dyagilev wrote:

Looks better. Why is it so?


Did you enable mipmapping for the first one?

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] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Giuseppe D'Angelo via Interest]

Hi,

On 24/03/2021 15:57, Matthew Woehlke wrote:

...we might not be having this conversation.


Sure. I don't get called to make *that* decision, though. So I also had 
to live through that.


I've proposed helpers and cleanups for 5.15/6.0 and those didn't land 
due lack of time or API/ABI constraints. What else can one do?




We're not talking about adding many, many variations
upon this theme, just*not*  removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common*  use cases.

Can I hear some use cases then please? Because from the experience of
usages within Qt, it was a nail/hammer problem, call it an education
problem ("I know containers; I don't know algorithms; let me use
containers to solve an algorithmic problem"), of which we're entirely
responsible (Qt docs teach a lot about containers, but not about
algorithmic design.)

An example I know offhand:

https://github.com/Kitware/qtextensions/blob/0ff5b486f08435c8cdfbc9f05d2f104f63b16aed/util/qtUiState.cpp#L268

Yes, in fairness, using a set to de-duplicate is arguably an algorithm
problem. OTOH, I'm not sure I really want to trade hashed lookup for
generating a collection of an unbounded number of duplicates. Also, yes,
most programmers probably don't know offhand how to de-duplicate a
collection using algorithms. (I'd also want to see performance numbers
that the latter approach is actually more efficient, because offhand I'm
not*at all*  convinced it is, and wouldn't be surprised if it's*worse*).


You could, however, package that algorithm and hide the implementation. 
Maybe provide the bounded and unbounded versions so the caller can 
choose depending on some information they have. Maybe provide a version 
using monotonic PMR if the caller knows that the number of elements is 
going to be relatively small most of the time.


For your particular implementation, to give you another "interesting" 
datapoint, none of the code you're using is even particularly optimized 
(as it COULD be) within Qt itself. QSet::operator+=(QSet) doesn't splice 
from the argument if it's an unshared rvalue (whops!). Even the goodwill 
of using containers as algorithms gets sabotaged by the poor implementation.


(An incredibly better solution would already to be unordered_set and its 
ranged insert. But then 1) if you didn't package it now you have to 
change all over the place instead of once, and 2) obviously you don't 
have unordered_set::toList(), WHOPS!).





The reality is that using containers to solve algorithm problems (e.g.
"I'm using a map because I need the values to be sorted") is extremely
common.



Then we're spectacularly failing at educating users, to be honest.



* I need to keep the list, process it in order, but avoid processing
duplicate elements; 99% of the time the list is a handful of elements;
let me do


QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
process(elem); } }

And what, exactly, is the solution here?


KDToolBox::DuplicateTracker, courtesy of Marc.




* I've got a square peg (a QList) and a round hole (an function I made
that takes a QSet), so I need conversions to call it.

And what, exactly, is the solution here? Probably "ranges", but those
aren't available yet.


Not an easy answer, but maybe start not to have functions take/return 
specific containers.



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] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Giuseppe D'Angelo via Interest]

On 24/03/2021 13:49, Matthew Woehlke wrote:

Let's take e.g. QList::toSet as an example. The deprecation message says
to use `QSet(list.begin(), list.end())` instead. How, then, is the
correct implementation*not*:

QSet QList::toSet() { return QSet{begin(), end()}; }


That is the correct implementation, but the deprecation functions aren't 
about "how this ought to be implemented into Qt".




What was so hard about that? If that's wrong, then so AFAICT is the
deprecation message.


Probably. There's only so much space for the message in them. I'm trying 
to point out that the specific motivation here isn't even remotely 
_technical_ (e.g. is this hard to implement correctly; as you've shown, 
it's super easy), but a _design_ one (is this API *good*?).


And anyways these methods are still fully supported within Qt 5.




Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that). 


All the contrary, this is one big crux of the problem: toX() for a 
completely arbitrary closed set of X is bad API. Why QSet::toList and 
not toVector? Why QList::toSet and not, say, MULTI sets? If you want 
stability of references and can't use Q6Set but want std::unordered_set, 
why there isn't a function for that? And so on.


This is calling for a more generic toX() API. Which isn't easy to 
provide within the quality constraints of QtCore. If it were, don't you 
think Yours Truly would already have provided it? Do I sound *that* evil 
that I enjoy crippling for the sake of it? :-(




We're not talking about adding many, many variations

upon this theme, just*not*  removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common*  use cases.


Can I hear some use cases then please? Because from the experience of 
usages within Qt, it was a nail/hammer problem, call it an education 
problem ("I know containers; I don't know algorithms; let me use 
containers to solve an algorithmic problem"), of which we're entirely 
responsible (Qt docs teach a lot about containers, but not about 
algorithmic design.)



Miscellanea examples from Qt itself,

* I need to remove duplicates from my list, let me do:


list = list.toSet().toList();


* I need to keep the list, process it in order, but avoid processing 
duplicate elements; 99% of the time the list is a handful of elements; 
let me do



QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem); 
process(elem); } }
* I've got a square peg (a QList) and a round hole (an function I made 
that takes a QSet), so I need conversions to call it.



And so on.

--
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] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

[Giuseppe D'Angelo via Interest]

On 22/03/2021 17:19, Thiago Macieira wrote:

I thought we'd fixed that and reverted them. Or didn't we add toContainer?

Peppe, what was our final conclusion here?


There was no conclusion reached, unfortunately, and didn't manage to 
provide a replacement in time. I was (and still am) afraid at simply 
reintroducing .to() functions.


One reason is purely API quality: implementing them "correctly" in 
C++14/17 without ranges/concepts is not exactly funny (just look at the 
ranges::to proposal for how many corner cases are there to consider), 
and there's indeed already ranges-v3::to as the ready-made solution (so 
why spending time redoing it).
Given a half-cooked solution wouldn't be acceptable into QtCore, we'd 
need to put it somewhere else where we could be more flexible in terms 
of minor API breaks if we think we did a mistake, and we didn't find the 
right place. (KDToolBox comes to mind, eventually).


The other reason was more profound and related to the deprecation of 
these APIs, meaning that in the huge majority of usages found was a form 
of algorithmic abuse. Should we offer APIs which facilitate bad coding 
practices?


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] QML Image size vs sourceSize strange things

[Giuseppe D'Angelo via Interest]

Il 23/03/21 14:16, Jérôme Godbout ha scritto:
Do you really need to same memory by reducing the source size? I think 
you should left the source size alone and sample the image from the full 
source. Source size for SVG doesn’t make any sense, it’s vectoriel, 
doesn’t have any size, it can scale to any dimension.


This isn't accurate. SVG files have a builtin "wanted" size, which is 
IIRC what Qt would use by default:



https://www.w3.org/TR/SVG11/struct.html#SVGElementWidthAttribute


By explictly setting `sourceSize` you're asking Qt to rasterize the SVG 
at a different resolution rather than the wanted one (and downscaling 
when rendering).



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] Mixing Commercial and Open Source license for, different, projects

[Giuseppe D'Angelo via Interest]

Il 18/03/21 12:41, Christian Gagneraud ha scritto:

My main grief is that Qt doesn't seem to care about C++.
What was their last contribution to the standard?


Apart from hiring the ex-chair of the WG21 Evolution Working Group?

(Can we stop with the FUD please?)

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] Mixing Commercial and Open Source license for different projects

[Giuseppe D'Angelo via Interest]

Il 15/03/21 16:16, James Maxwell ha scritto:
Is there even a difference between the GPL creator and commercial 
creator? I feared that once I have a license, whenever I use any 
QtCreator it is commercially licensed.


But using QtCreator is not actually my main concern. If I have a 
commercial Qt license, can I still develop for projects which are going 
to be released under LGPL where also other people don't have a Qt 
license (of course assuming we only use LGPL Qt and nothing of the 
commercial only parts).


No matter what the eventual differences between commercial Creator / 
open source Creator are (if any); but would it be a problem for you to 
use commercial Qt / Qt Creator for the commercial customer, and open 
source Qt / Qt Creator for the open source code?


(Not dealing with the practical aspects of having multiple Qt 
installations and what not. Again, I'm just asking if such a setup is 
not possible for some specific reasons.)


Thank you,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Mixing Commercial and Open Source license for different projects

[Giuseppe D'Angelo via Interest]

Il 14/03/21 15:29, James Maxwell ha scritto:
For A I need a commercial license. Am I then still allowed to use 
QtCreator under my commercial license to develop a LGPL project for 
customer B?


Apart from whether it's allowed or not, is there any particular reason 
for going this way rather than using the GPL edition of QtCreator to 
develop for customer B? (I'm not being dismissive, it's an actual open 
question).


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] QML app macOS dedicated graphic card issue

[Giuseppe D'Angelo via Interest]

Hi,

Il 24/02/21 11:55, Alexander Dyagilev ha scritto:

"as soon as I start it my mac switches to dedicated nvidia graphic card
from item integrated.
which seems like unnecessary."

Why? Can anything be done to prevent this?

We use Qt 5.12.10, QML + QtQuick Controls 2.


There's been a few bugs reported against this, search in the bugtracker. 
IIRC the "solution" was to advertise that the discrete GPU is OK in your 
application's info.plist.


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] How to read screen information from QGuiApplication to put in qputenv environment variable?

[Giuseppe D'Angelo via Interest]

Il 15/02/21 12:50, Anisha kaul ha scritto:
|qreal abc = QGuiApplication::primaryScreen()->physicalDotsPerInch(); 
qDebug() << "null " << abc; qputenv("QT_SCALE_FACTOR", "2"); 
QGuiApplication app(argc, argv);|


I'm not exactly sure why would you want to do this, but you can destroy 
and recreate the QGuiApplication object.


The only annoying part is that you'll need to copy the command line 
arguments. Ignoring that issue for now:



int main(int argc, char **argv) {
  {
 QGuiApplication app(argc, argv);
 // access screen info, calculate scaling, etc.
 // qputenv
  }

  // app destroyed , recreate it

  QGuiApplication app(argc, argv);

  // rest of main

}


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] QVariant toBool() not working correctly?

[Giuseppe D'Angelo via Interest]

Hi,

Il 26/01/21 16:52, Kevin André ha scritto:


When reading a zero BIT value from the database, this outputs:

getBool called for: QVariant(QString, "\u")
getBool will convert QVariant(QString, "\u") to bool true

The docs of toBool() claim that toBool should return false for a
string value of "0".
I am using Qt version 5.12.3.
So is this a mismatch between the Qt version of the docs and the Qt
version that I am using? Or am I missing something else here?


You've been bit by a combination of two things, one is Qt not supporting 
the BIT column type natively (that's QTBUG-21326), and mapping it to a 
string. The other that the string you're getting contains a NUL 
(U+), not a literal 0 (U+0030). When converting a QVariant 
containing a string to bool, Qt maps empty strings, the string "0" and 
the string "false" (in any case) to false and everything else to true:



https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.cpp?h=5.12#n344


Therefore, work around the issue and do the conversion yourself. (An 
alternative would be using TINYINT to represent bools.)


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] QStringBuilder buffer overflow with string litteral?

[Giuseppe D'Angelo via Interest]

Hi,

Il 25/01/21 13:56, Olivier B. ha scritto:

         fields += (fields.isEmpty() ? "" : ", ") + '"' + field + '"';


QStringBuilder usage is a red herring, pay close attention at what 
you're doing in the first +: you're summing a const char * (result of 
the ternary operator) with a char; that does not do string concatenation...



Passing one/both of the operands of the ternary operator as QStrings makes the 
problem disappear.


That however kills the advantage of QStringBuilder. Use QStringView / 
QLatin1String instead.


Tip: always define QT_NO_CAST_FROM_ASCII (or the more lenient 
QT_RESTRICTED_CAST_FROM_ASCII) in any Qt project.


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] download.qt.io is down

[Giuseppe D'Angelo via Interest]

Il 19/01/21 21:08, Tuukka Turunen ha scritto:

https://qt-mirror.dannhauer.de/

https://www.funet.fi/pub/mirrors/download.qt-project.org/

https://ftp.fau.de/qtproject/

...or just use the online installer, which picks mirrors automatically.


The online installer doesn't actually work because it will try and 
download the mirror list from the master, which is offline.


One can use https://github.com/miurahr/aqtinstall instead, which allows 
to manually specify the mirror, e.g.



python -m aqt --base https://ftp.fau.de/qtproject/ --outputdir /opt/qt/ 5.15.2 
linux desktop



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] QPA display system query ?

[Giuseppe D'Angelo via Interest]

Hi,

Il 19/01/21 00:33, Nicholas Yue ha scritto:
Is there some command line query I can make to determine the QPA display 
system that is being used? For example, running that command on e.g. an 
Ubuntu box may return something like *xcb*


In general, qtdiag will tell you. However, this decision may be 
different for each application, and it's not uncommon to find 
applications that override the system default.


You can enable sufficiently verbose logging for a given application to 
find out what's going on, e.g. via


QT_LOGGING_RULES="qt.qpa.*.debug=true" yourApp

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.15 pull out of open source?!

[Giuseppe D'Angelo via Interest]

Hi,

Il 07/01/21 04:03, Jérôme Godbout ha scritto:

Hi,
is this any true?
https://www.phoronix.com/scan.php?page=news_item=Qt-5.15-LTS-Commercial-Phase


Please see the thread on development@ (no idea why the original message 
was not posted on interest@ as well.).



https://lists.qt-project.org/pipermail/development/2021-January/040798.html



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 6.0.0 build on Windows 10 - Perl related error ?

[Giuseppe D'Angelo via Interest]

Il 29/12/20 17:36, Nicholas Yue ha scritto:
   Has anyone come across this error ? I have build 6.0.0 on Windows 10 
on a different machine (with nvidia card and drivers) successfully, now 
I am rebuilding on a new Windows 10 machine (hardware different, no 
nvidia card hence using the OpenGL shipped with Windows), I am using the 
same Strawberry Perl version.


Can't help you with the actual error, but notice that PRL files have 
nothing to do with Perl -- they're qmake files used to describe 
libraries. (CMake is generating them for your build, so that code using 
Qt can still build using qmake.)



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 expose a ‘index’ property to a delegate?

[Giuseppe D'Angelo via Interest]

Il 23/11/20 14:20, Federico Ferri ha scritto:


but of course in this example it is using a non-existent ‘index’ in the 
PhongMaterial.diffuse binding.


Are you sure it's non-existing? The context in which that delegate is 
going to be created should have "index" injected into it.


Needless to say, all of this is deprecated in 5.15 (in favour of 
required properties), and even before you were never supposed to use 
unqualified properties like those. You were supposed to


1) always prefix them with model.
2) expose properties on the root of the delegate, use them internally as 
needed, and bind them when using the delegate in a view.


See > https://youtu.be/vzs5VPTf4QQ?t=2240

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] Window ID of the current screen (root window)?

[Giuseppe D'Angelo via Interest]

Il 20/11/20 14:55, Richard Moore ha scritto:
I'd hope there's a way to get the actual connection being used, rather 
than relying on looking at the environment variables. For example, what 
happens if -display is passed?


As in QX11Info::connection()?

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] how to get and purge events from queue?

[Giuseppe D'Angelo via Interest]

Il 05/11/20 05:38, David M. Cotter ha scritto:

when scrolling, the scroll for my app is a bit sluggish (do not ask about that)
which means that mouse wheel scroll events can pile up in the queue while the 
first scroll event is being processed.
meaning that a dozen more*slow*  events get handled after the user stops 
scrolling.

what i want to do is: when i get a wheel scroll event, at that moment i see if 
there are MORE scroll events in the queue. if not, i just handle this event. 
but if there ARE i want to get the most recent one, and handle only that ONE 
event, while purging the rest.


There is some sort of input event compression available through 
application flags. For the rest, you could just not act on events that 
happen too close together (either wait a bit before acting, so to get N 
events, or act on the first one and ignore the subsequent ones in a 
short time frame).


But there's just no public access to the pending event queue.

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] QSharedpointer members are not accessible: isNull and data

[Giuseppe D'Angelo via Interest]

Hi,

On 23/10/2020 14:16, Tamás Nagy wrote:

class A
{
public:

private:
 QSharedPointer m_Validator;
}

My custom program:

  if(di.Validator()->isNull())
  {
 // unfortunately the di.Validator() is null
 // some A-s in the Map can have nullptr as Validator.

 if(auto validator = di.Validator())   // di is an instance of A
 {
 if(validator != nullptr)
 {


I'm having quite a hard time understanding this code.

In the first if, you dereference the result of di.Validator(). This 
implies it's not null.


Then immediately after you fetch di.Validator() again, assign it to 
"validator", and in the second if you ask if it's not null -- but... you 
already know?.


Then in the third if you ask *again*. What's going on here?

Can you put together a minimal but complete, correct, and compileable 
testcase?


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] QPainter::drawRect incorrectly "rounds" corners

[Giuseppe D'Angelo via Interest]

Il 21/10/20 20:11, Matthew Woehlke ha scritto:

Yes (although there's a related story there; sigh). Turns out the
default corner style is... unhelpful. Ick.

I still think there's a bug; the corners should at least all be the same...


This might be QTBUG-25896 (cf. 
https://codereview.qt-project.org/c/qt/qtbase/+/200383 which 
unfortunately has been reverted).


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] question for a blocking background thread call

[Giuseppe D'Angelo via Interest]

On 20/10/2020 22:16, Scott Bloom wrote:


Essentially, on a “button click” a long running blocking function call 
is executed. I can safely call the function into a background thread, 
but I don’t want the gui flow to continue.


My idea is the following, a class that takes a lambda.

When a blocking function is called on the class, the lambda is executed 
in a background thread.  While the function waits calling processEvents 
without user events being handled (this part is easy…)


Does anyone have an example to follow for this.  Unfortunately, Im 
hitting all sorts of weirdness when getting this.




Can't you just create a QDialog and exec() it?

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] QtPdf from Qt open source online installer

[Giuseppe D'Angelo via Interest]

Il 20/10/20 17:28, Jason H ha scritto:
Then we should probably include the marketplace email address in this 
thread.


Open a bug report instead.

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] implementing rows reordering in QSortFilterProxyModel

[Giuseppe D'Angelo via Interest]

Il 12/10/20 15:31, Александр Иваш ha scritto:

Is there any example for re-ordering of QTableView entries implemented
in QSortFilterProxyModel (ideally drag-n-drop-driven)? If not, what is
the best way to implement it? I'm thinking about implementing
reordering as 'custom sorting' - but it will require me to collect all
the QModelIndex-es in the separate list (which can be then reordered
and used for custom sorting). 


Just to make sure I understood, do you need a proxy model that allows to 
reorder the rows of a given source model via DND?



The issue with such approach is that
QModelIndex-es are short-living and I need to track its lifetime
somehow Any better ideas?


QPersistentModelIndex. But it sounds like it's not _really_ needed, you 
need a way to map integers (row numbers from the source model) into 
other integers (row numbers after the proxy).


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] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)

[Giuseppe D'Angelo via Interest]

On 26/09/2020 16:53, Alexander Dyagilev wrote:

I use this helper macro for this (register a metatype in runtime):

template 
inline void qRegisterMyMetaType(const char *name)
{
     if (QMetaType::type(name) == QMetaType::UnknownType)
     qRegisterMetaType(name);
}

#define Q_REGISTER_MY_METATYPE(type) qRegisterMyMetaType(#type);


Usage example:

Q_REGISTER_MY_METATYPE(QCryptographicHash::Algorithm);



This machinery is not strictly needed -- it's perfectly fine to call 
qRegisterMetatype multiple times (you could for instance put it in 
the constructor of T itself). The point is that you have to call it 
before emitting (in case of a queued activation on an autoconnection) or 
even before connecting (in case you're forcing a queued connection).


Either way, if you forget, Qt should emit a warning telling you exactly 
what to do.


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] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)

[Giuseppe D'Angelo via Interest]

On 26/09/2020 16:48, Alexander Dyagilev wrote:
I'm not sure what you mean exactly, but I've seen many such situations 
(when connection did not work because metatype was not registered) and 
never saw any warnings anywhere.




I mean that when you do a queued connection or a queued activation and 
some arguments are not registered, you should get a warning from Qt.


The lack of such a warning is a bug. Do you have a testcase?

--
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] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)

[Giuseppe D'Angelo via Interest]

Il 26/09/20 07:55, Alexander Dyagilev ha scritto:

Yeah, it's possible that some metatype (used in signal) is registered in
Qt 5.12 and is NOT registered in Qt 5.15, thus connection does not work
between objects in different threads.

It's required to register it manually then.


Do you know of a case where this wouldn't spit the usual "arguments are 
not registered" warning? (If so, that's a bug)


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] Queued signals lost in 5.15.0 (works in 5.12.5) (Windows)

[Giuseppe D'Angelo via Interest]

Il 24/09/20 17:55, Rainer Wiesenfarth ha scritto:
- if I take the application built and running without this issue with Qt 
5.12.5 and replace the DLLs with those from Qt 5.15.0, the issue 
appears. That means there is a change in the event handling between 
5.12.5 and 5.15.0 that causes the issue to appear.


It's super hard telling what might be going wrong without a testcase.

I'd anyway start by using 5.15.1/2 (not 0) and actually recompiling the 
application, just to exclude subtle binary compatibility breaks.


You may also want to inspect the event posting and delivery (e.g. by 
overriding QCA::notify(); and/or by using ETW tracing; and/or by posting 
and dispatching your custom "metacall" events instead of using a queued 
invocation in the same thread).


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] Debugging a double dealloc

[Giuseppe D'Angelo via Interest]

Il 23/09/20 14:08, Ben Haller via Interest ha scritto:

Thanks for the suggestion.  However, this problem is only on macOS, and 
Valgrind doesn’t appear to run on any macOS later than 10.12 (“preliminary” 
support for 10.13, according to their website; I’m not sure what that means).  
I’m on macOS 10.15.6, and I’m using Qt 5.14.2 which has a minimum macOS version 
of 10.13, so Valgrind seems to be a no-go for at least one reason, perhaps two 
reasons (depending on “preliminary”).


There is a fork of Valgrind to support more modern macOS versions

https://github.com/LouisBrunner/valgrind-macos/

(Note: never used it myself, not a mac user).

Another option is getting a recent Clang version and rebuilding Qt and 
your app with AddressSanitizer.


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] Help with maintenance tool

[Giuseppe D'Angelo via Interest]

Il 21/09/20 17:19, Jason H ha scritto:

How do I use the open source version?

"No valid license available in your Qt Account for this host platform.
Please renew your license(s) from Qt Account."

How am I supposed to elect the open source version when there is no option at 
account.qt.io
Can someone fix this for me?


I literally fixed this by going back and forth in quick succession 
inside the tool while clicking around (basically doing a "monkey test") 
until it goes past that screen and you get to select if to add/remove or 
uninstall.


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] Build qt 5.14.2 from scratch; enable win32-bluetooth-support

[Giuseppe D'Angelo via Interest]

On 15/09/2020 15:54, Colin Worth wrote:
c:\qt\qt5.14.2\qtbase\include\qtcore\../../src/corelib/tools/qhashfunctions.h(201): 
error C3520: 'T': parameter pack must be expanded in this context


What's your MSVC version *exactly*? (Run cl on the command line)

How did you configure Qt?

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] QML/C++ interaction in Qt6

[Giuseppe D'Angelo via Interest]

Il 14/09/20 15:54, Jérôme Godbout ha scritto:

//

how does the Person class is link to the People name exactly?!?



QML_IMPORT_NAME does the link.

The "equivalent" of registering a QML_ELEMENT class, using the syntax of 
old registrations is something like



  qmlRegisterType("QML_IMPORT_NAME", QML_IMPORT_MAJOR_VERSION, 
QML_IMPORT_MINOR_VERSION, "CLASS_WITH_QML_ELEMENT")


In your case that translates to


  qmlRegisterType("People", 1, 0, "Person")


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] Double free in QItemDelegate editor

[Giuseppe D'Angelo via Interest]

Il 03/09/20 22:51, Kyle Edwards via Interest ha scritto:

My project (CMake GUI) has a class which extends QItemDelegate and
overrides QItemDelegate::createEditor(). However, the editor that gets
returned by this method gets double-freed, and I'm not sure exactly why.
(I did notice that QItemDelegate::destroyEditor() calls the editor's
QObject::deleteLater() by default - does the editor already get deleted
when its parent gets deleted?)


Do you have a minimal testcase? What does valgrind / ASAN say?

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] Three-file modules vs. moc

[Giuseppe D'Angelo via Interest]

Il 27/08/20 20:46, Bernhard Lindner ha scritto:

This is recommended anyway, regardless of your problem. Always #include the
module output for your headers in your corresponding .cpp files.

Can you explain that general recommendation? It seems to me that such includes 
are only
useful in special cases like mine and like .cpp files containing moc relevant 
code.


Including moc from the C++ code reduces compilation times (one "slightly 
larger" file to compile, not two) and enables the compiler to optimize 
more aggressively without resorting to LTO. As such it's always useful 
to do.


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] Three-file modules vs. moc

[Giuseppe D'Angelo via Interest]

Hi,

Can you make an example of your structure (what's exactly in each of the 
three files)? It's not entirely clear.


Il 27/08/20 13:26, Bernhard Lindner ha scritto:

Hm. I am not sure I get it. That is a global option, right? I have a LOT of 
modules, each
with a different name. When adding an -f option for each of them, each 
moc_*.cpp file
would include all *.inl includes... which would increase compile time 
exponentially. I
would like to avoid that.


You might also use a custom extra compiler -- that still invokes moc, 
but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
and so on...


--
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] Mouse/Pen input latency in Qt Quick and render loop

[Giuseppe D'Angelo via Interest]

Il 19/08/20 17:57, Daljit Singh ha scritto:

Now I think there might be some ways this could be solved:


Just as an extra data point: have you tried driving the Qt Quick render 
loop manually, using QQuickRenderControl?


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] QTranslator.load and builtin translations

[Giuseppe D'Angelo via Interest]

Il 18/08/20 16:28, Jérôme Laheurte ha scritto:

The « split(‘-‘)[0] » part looks like a big code smell to me, but what should I 
do ?


There's no need, load() should already do the split internally and 
search for the right thing. Maybe you just need to load "qtbase_" (or 
specify "_" as the prefix string). See



https://doc.qt.io/qt-5/qtranslator.html#load-1



https://doc.qt.io/qt-5/internationalization.html#example-basic-qt-modules



https://www.kdab.com/fixing-a-common-antipattern-when-loading-translations-in-qt/


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] wss:// on localhost

[Giuseppe D'Angelo via Interest]

Il 02/08/20 20:43, Alexander Carôt ha scritto:

Also I don't see a way to get access to the key - it is compiled into the 
binary and on top of it it's triple-secured/encypted


Irrespective to any other detail in this thread: this is, by definition, 
not secure (sec by obscurity).


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] Interest Digest, Vol 106, Issue 14

[Giuseppe D'Angelo via Interest]

On 15/07/2020 13:01, Roland Hughes wrote:

What I'm saying is Tweedle-Dee and Tweedle-Dum (I don't remember their
real names now, just the darting nick names; they tagged the trio I was
with Moe, Larry, and Curly; it's a darting thing) developers working at
Nokia who threw darts with me months on end every weekend Two Rivers and
even showed up a few times for Tuesday night dart league at Pockets
talked shop while we were drinking and darting and socializing. They
said repeatedly it was exactly what they were working on.


This is the *definition* of hearsay.

--
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] Roland Qml

[Giuseppe D'Angelo via Interest]

Il 14/07/20 13:35, Roland Hughes ha scritto:

When QML was first pitched back in the Nokia days, it was supposed to be
a script that ran through a pre-compiler generating the C++ widget code.

No, it wasn't.
Yes it was. I got that exact pitch. 


Are you calling the person who has maintained QtCore for the last 10+ 
years, who has worked directly first under Trolltech and then Nokia, who 
has been the release manager for a number of Qt releases (just before 
4.7, which publicly introduced Qt Declarative) a liar?



It was supposed to replace the
problem prone XML based UI files and buggy designer of the day. At that
time the designer was notorious for corrupting UI files forcing one to
open them with a different editor to fix. Having a plain text "language"
that was easy to code and would pre-compile to widget code was a great
selling point.


"Notorious" is hearsay and unwarranted.

--
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] rebooted QtWebKit for Qt4??

[Giuseppe D'Angelo via Interest]

Il 13/07/20 14:30, Roland Hughes ha scritto:

Let us not forget that QML+JavaScript is completely insecure in the
OpenSource world. All of that JavaScript gets stuffed into the binary
you ship as free text. Anyone with a decent text editor can read/extract
your super secret proprietary algorithms. Worse yet, anyone with enough
patience can change a binary in the field.


If you have the source, then why do you need to bother with extracting 
binaries?



If you meant in the *non* opensource world, then:

1) the QML compiler has been a reality for a number of years;

2) your "super secret" algorithms belong to C++, not to QML, so using or 
not using QML doesn't change the equation. And, you can obfuscate the 
JavaScript code used by your QML part.



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] Pause QTableView while model continues to update

[Giuseppe D'Angelo via Interest]

On 08/07/2020 20:20, Murphy, Sean wrote:

The only idea I have at the moment is to have a second model object, that is 
identical to the first one, except that it isn't connected to the sensor. At 
the time the user wants to pause the view, I copy the current data out of the 
main model into the second model, swap out the paused view's model out to the 
second model, and then swap it back to the main model when the user wants to go 
back live.

Am I missing something easier? The only other idea I had was that I could try 
to change the second view from a pure QTableView to one that inherits from 
QTableView and then have my own slot that disconnects/connects the signals 
between the model and that view based on the when the user wants to 
pause/resume.


This sounds much harder, hackish and difficult to test than simply 
having a "snapshotting" model like you proposed earlier.


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] Issues loading Qt's meta catalog translation files

[Giuseppe D'Angelo via Interest]

Il 02/07/20 18:16, Julius Bullinger ha scritto:


from the Qt Linguist documentation [1]:

In Qt 4, there is one big, monolithic .qm file per locale. For > example, the file qt_de.qm contains the 
German translation of all > libraries. > > In Qt 5, the .qm files were 
split up by module and there is a > so-called meta catalog file which 
includes the .qm files of all > modules. The name of the meta catalog 
file is identical to the name > of Qt 4's monolithic .qm file so that 
existing loader code works as > before provided all included .qm files 
are found.


However, loading the meta catalog with QTranslator doesn't seem to work:



I think the key part of the sentence is "provided all included .qm files 
are found". If you open up your qt_de.qm, chances are it's trying to 
reference .qm files for modules you don't have installed (e.g. QtScript).


See also the discussion here:


https://doc.qt.io/qt-5/internationalization.html#available-catalogs


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] Reason for omitted stream syntax of qFatal

[Giuseppe D'Angelo via Interest]

Il 28/06/20 19:05, Bernhard Lindner ha scritto:

Can someone tell me why exactly qFatal does not provide the stream syntax that 
was
implemented for qDebug and friends?


No real reason. Cf.

https://bugreports.qt.io/browse/QTBUG-8298
https://bugreports.qt.io/browse/QTBUG-38992

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] Set manipulation in Qt 6

[Giuseppe D'Angelo via Interest]

Il 21/06/20 20:07, Elvis Stansvik ha scritto:

I'm all for Qt offering faster way to do things. I expect that. But I
also wonder: Why remove the slower alternative for those who value
readability over optimality in the cases where the extra performance
is not needed? In the docs, the slow alternative could have pointers
to the fast alternative, and the user could make an informed choice.


Let me elaborate on what I commented on the bug report:

1) no API should lead to naturally writing bad code;

2) no API should encourage premature pessimization;

3) APIs should encourage the natural discovery of the best tool for a 
given job. If your job is to remove duplicates, the API should favour an 
algorithm for that, not the toSet().toList() combo, which is just an 
antipattern!


4) as developers of Qt: we must care about all of the above; and bad 
habits on user side shouldn't result in bad APIs, in the name of 
convenience or whatever;


5) ultimately, the most direct replacement of toContainer() is

container | ranges::to 


which isn't that much of an extra burden to learn / to type rather than 
toContainer(), and it's also obviously more general.


---

In other words: if you "don't care", you can just replace list.toSet() 
with list | ranges::to. You can do it today, using just a C++14 
compiler (and you need a C++17 compiler anyhow if you're aiming for Qt 6).


Back on to OP's issue, with this code using deprecated APIs:


QSet 
missingKeys{customLines.keys().toSet().subtract(customLinesColor.keys().toSet())};


Then the "don't care" port can be done by something like:


QSet missingKeys = customLines.keys() | ranges::to;
missingKeys.subtract(customLinesColor.keys() | ranges::to);



If nobody ever told you about toSet(), and only told you about 
ranges::to, would you be upset by toSet()'s deprecation?



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] QDateTime::toString() fails when used in exit handler

[Giuseppe D'Angelo via Interest]

Il 19/06/20 22:12, Bernhard Lindner ha scritto:

Can someone tell me what is going wrong here?


There's a wider blanket statement made by Qt: you're not allowed to 
touch _most_ Qt APIs without a QCoreApplication object being alive. 
That's the case here. In detail, QDateTime uses some global that got 
already destroyed by the time your atexit handler runs. But Qt doesn't 
even guarantee that the usage in main() is OK (because there's no QCA 
around).


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] Set manipulation in Qt 6

[Giuseppe D'Angelo via Interest]

Hi,

Il 20/06/20 08:44, Vadim Peretokin ha scritto:

QMap> customLines;
QMap customLinesColor;
// ...

#if (QT_VERSION >= QT_VERSION_CHECK(5, 14, 0))
     auto customLineKeys = customLines.keys();
     QSet missingKeys{customLineKeys.begin(), 
customLineKeys.end()};

     if (!customLinesColor.isEmpty()) {
         auto customLinesColorKeys = customLinesColor.keys();
         QSet 
customLinesColorKeysSet{customLinesColorKeys.begin(), 
customLinesColorKeys.end()};

         missingKeys.subtract(customLinesColorKeysSet);
     }
#else
     QSet 
missingKeys{customLines.keys().toSet().subtract(customLinesColor.keys().toSet())};

#endif



With my hat of the guy going around and deprecating toSet() and friends: 
the rationale for these deprecations is the terrible code that those 
methods encourage, and the



Let's just look at this last line. This is, at a minimum:


customLines.keys()


- 1 temporary allocation + #LINES temporary copies (builds a QList 
copying all the keys from the map)



.toSet()


- #LINES+1 allocations + #LINES copies (builds a QHash copying all the 
values from the list)



customLinesColor.keys().toSet()


- 1+1+#COLOR temporary allocations, 2*#COLOR temporary copies (same, but 
this is completely temporary)



Totals:

- 4 + #LINES + #COLOR allocations
- 2 * #LINES + 2 * #COLOR copies
- 3 + #LINES + 2 * #COLOR destructions at a minimum
- 3 + #COLOR deallocations at a minimum

(Luckily the keys are QStrings, and not something where the copy and 
destruction would be even more expensive, or QList would cause further 
allocations).




There are much better alternatives you can aim for with minimal effort.
Assuming that at the end you do want exactly a QSet, you can port it in 
the slightly more verbose but still straightforward:



QSet customLinesKeys(customLines.keyBegin(), customLines.keyEnd());
{
QSet customLinesColorKeys(customLinesColor.keyBegin(), 
customLinesColor.keyEnd());
customLinesKeys.subtract(customLinesColorKeys);
}


Which saves buildings the temporary QLists. Totals now:

- 2 + #LINES + #COLOR allocations
- #LINES + #COLOR copies
- 1 + #COLOR destructions at a minimum
- 1 + #COLOR deallocations at a minimum



I think it's possible to do even better -- a QMap, by definition, keeps 
its keys in order. Which means now you can use e.g. std::set_difference.


Unfortunately we can't use a QSet as an output -- let's sketch with a 
std::unordered_set for the moment:



std::unordered_set result;
std::set_difference(customLines.keyBegin(), customLines.keyEnd(),
customLinesColor.keyBegin(), customLinesColor.keyEnd(),
std::inserter(result, result.end()));


Cost of this one:

- 1 + (#LINES / #COLOR) allocations
- (#LINES / #COLOR) copies

AKA optimal.

With a QSet, the cost and the code would be identical. The problem is 
that we can't write _that_ code as QSet is not usable with std::inserter 
(QSet lacks a suitable insert() method). Then again, do you _need_ a 
QSet or would a QList output suffice?


(Which brings me to my second crusade, try stop encouraging the usage of 
Qt containers, as their API is full of holes and doesn't play nice with 
algorithms or ranges. But it's enough for this mail.)


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] [Development] Windows 7 support will be, dropped in Qt 6

[Giuseppe D'Angelo via Interest]

I've refrained from commenting in so far, but I think we're now passing 
the threshold... could we please, everyone, STAY ON TOPIC on this 
mailing list?


Thank you,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Customzie Qtablemodel and selectionmodel.

[Giuseppe D'Angelo via Interest]

Il 17/06/20 07:49, Milos Top ha scritto:

But I can not implement "SelectionModel" on this model.
For example, I want to select first record and last record.
For now, If I select the first record and scroll to down then, I can not 
keep selections because the model is changed by scrolling.


How is the model changed by scrolling, exactly?

The issue with selection is that you need an valid index representing 
the last entry. So, you may lazy load the model data (based on views' 
requests), but the row count has to be accurate immediately. More than 
doable, anyhow.


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] Connecting signal handler to Qt application - async-handler-safety

[Giuseppe D'Angelo via Interest]

Il 15/06/20 18:12, Thiago Macieira ha scritto:

No, you can't, because you need to block the signal using pthread_sigmask in
all threads, otherwise the kernel may prefer delivering the signal instead of
using the signalfd. Qt has a few background threads (like the QHostInfo thread
pool) that you don't have access to.

signalfd is a misfeature. Don't use it.


It's very unfortunate that signalfd wants to read a pending signal, 
rather than being a "special" signal handler that overrides the 
dispositions. You may get away with installing it before spawning any 
other thread. But then again, threads+signals+libraries don't exactly 
mix well together...


--
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] Connecting signal handler to Qt application - async-handler-safety

[Giuseppe D'Angelo via Interest]

Il 15/06/20 12:58, Bernhard Lindner ha scritto:


Are there any functions in Qt that are considered async-handler-safe?


No, as any of them may allocate memory.

See https://doc.qt.io/qt-5/unix-signals.html for the textbook solution 
(self pipe trick).


On Linux you can also use signalfd(2) to achieve the same without the 
burden of a custom signal handler.


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] Getting QGraphicsView from within a mouse event

[Giuseppe D'Angelo via Interest]

Il 15/06/20 03:26, Nicholas Yue ha scritto:
The return widget object does not have a viewport() method from looking 
at the QWidget - docs 


void AttributeItem::mousePressEvent(QGraphicsSceneMouseEvent* event)
{
     if (event->button()==Qt::LeftButton)
     {
         QWidget *w = event->widget();
     } else
         QGraphicsItem::mousePressEvent(event);
}


Sorry, what I meant is the other way around: the widget returned *is* 
the viewport() of your QGraphicsView. (So, typically, getting the parent 
widget of that widget will give you QGV you're looking for.)


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] Getting QGraphicsView from within a mouse event

[Giuseppe D'Angelo via Interest]

Il 15/06/20 00:50, Nicholas Yue ha scritto:

Hi,

   I understand that a QGraphicsScene may be view by multiple QGraphicsView

   When handling a mouse event, what is the Qt way to find out from 
which view the event was from ?


If you're handling a QGraphicsSceneEvent of some sort, its widget() will 
give you the viewport() of the view where the event originated, IIRC.


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] GTk QPA?

[Giuseppe D'Angelo via Interest]

Il 14/06/20 12:08, René J.V. Bertin ha scritto:

the issues I'm seeing


What issues are we talking about?

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] Handling of ~ paths

[Giuseppe D'Angelo via Interest]

On 6/11/20 8:03 PM, Scott Bloom wrote:
What is the Qt way to handle this?  It cant be to tell your users not to 
use ~.  Can it? Does everyone write their own little “analyze the string 
before actually using it, and handle ~”?


How are users entering these paths to start with?

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] how do I load massive table views instantly?

[Giuseppe D'Angelo via Interest]

Il 04/06/20 23:31, David M. Cotter ha scritto:


What table view are you talking about, specifically?


QTableView with QSortFilterProxyModel


What is the model _behind_ QSFPM?

Does that model support async loading?

Note that QSFPM may still need to load the entire source model (didn't 
check its source code) if you ask it to filter or sort. For 200k 
elements, I'd expect the source model itself to support filtering and 
sorting, without the need of a proxy in front 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] how do I load massive table views instantly?

[Giuseppe D'Angelo via Interest]

Il 04/06/20 21:12, David M. Cotter ha scritto:

alternately, if "loading only what you see" is just "how it's done", then can i 
just set the scroll bar height to be the total height?  so CAN still grab the scroll thumb, and 
drag it to the end, and see the data at the end, without waiting for all the unseen data to load?

i know other apps do this... how is it done?




What table view are you talking about, specifically?

What did you try so far?

--
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] Fail to compile qt4 on Ubuntu 20.04.

[Giuseppe D'Angelo via Interest]

Il 18/05/20 01:32, Hongyi Zhao ha scritto:

# The following step failed for Ubuntu 20.04:
$ make -j4
../../include/QtCore/../../src/corelib/tools/qpair.h:62:20: note:
because ‘QPair’ has user-provided ‘QPair& QPair::operator=(const QPair&) [with T1 = int; T2 = int]’
62 | QPair =(const QPair )
   |^~~~
make[1]: *** [Makefile:18175: .obj/release-shared/qsslsocket_openssl.o] Error 1
make[1]: Leaving directory
'/home/werner/Downloads/qt-everywhere-opensource-src-4.8.7/src/network'
make: *** [Makefile:278: sub-network-make_default-ordered] Error 2



This is missing the actual error messages, please run make -j1 and paste 
everything. From the text, it looks like a deprecation warning for a 
custom declared operator=, but that should be just a warning and not an 
error. If some -Werror is in place, find the way to remove it.


The actual error seems to be related to OpenSSL, which you should just 
disable via the respective configure switch (Qt 4 does not support 
OpenSSL 1.1).


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] unexpected result from QString::compare

[Giuseppe D'Angelo via Interest]

Il 11/05/20 10:23, Hamish Moffatt ha scritto:

Q_GLOBAL_STATIC(QThreadStorage, defaultCollator)

Why does it need an instance per thread?


Because QCollator is reentrant, not thread-safe.

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] Handling WM_QUIT messages when no window is shown

[Giuseppe D'Angelo via Interest]

Il 07/05/20 11:38, Julius Bullinger ha scritto:

How would one create a hidden, non-interactive window with Qt?


Didn't try it myself, but the idea would be


class EventWindow : public QWindow {
  bool nativeEvent(~~~) override { ~~~ }
};

EventWindow w;
w.create(); 
// never show(), etc. this window



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] Crash when signal fires

[Giuseppe D'Angelo via Interest]

On 4/22/20 1:44 AM, Ben Haller via Interest wrote:

Hi folks.  I’m seeing something weird that I don’t understand.  I have a 
connection defined for the main window of my Qt Widgets app, like so:

 connect(qApp, ::focusChanged, [this]() { updateUIEnabling(); 
});

I’m seeing a 100% reproducible crash as a result of this.  When the focusChanged 
signal fires, I end up in updateUIEnabling() as expected, but I immediately crash 
because something about the state of things is corrupted; the immediate symptom, 
according to the debugger, is that the ui pointer for my main window is equal to 
0x1 (yuck).  I try to access a button,  ui->playOneStepButton, and it crashes.  
As I said, 100% reproducible.

The weird thing is that this does*not*  happen if I change the connect 
statement to this:

 connect(qApp, ::focusChanged, this, 
::updateUIEnabling);

Now, 100% of the time, there is no problem, no crash, and my app chugs along 
happily.  No other code changes involved.  I can literally flip this connect 
definition back and forth in my code and go from 100% crashing to 100% fine.


A quick checklist:

0) I hope threads are not involved (you're not really allowed to do any 
GUI work from any other thread).


1) Never use the 3-arguments connect(). If you want to use the lambda, 
pass "this" as 3rd parameter and lambda as fourth. Why: if "this" has 
been destroyed, the first version won't disconnect automatically and 
crash. The second will disconnect and not crash.


More info: https://stackoverflow.com/a/27954502

2) ASAN, Valgrind and friends will help you locate the source of the 
crash if it's due to memory corruption. Use them.


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] QVariant compare operator

[Giuseppe D'Angelo via Interest]

(Sorry, this was meant to go to the list!)

On 4/19/20 2:21 PM, Allan Sandfeld Jensen wrote:

I don't think we need "incomparable" here.

QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().

If wanted, this can be refined to make e.g. all integral types comparable.


What about non-integral types? QVariants can't really be anything but weakly
ordered as I see it, as some of the things it contains are either non-
comparable or weakly ordered themselves.



Before bikeshedding on the actual semantics we _want_ to have: if they
don't 100% match the ones we have right now, then it's a silent breakage
for end-users, which is a very bad idea.

So, if we ever want to have the relational operators in QVariant with
"better" semantics, we need an upgrade path that clearly signals the
breakage. Any proposals for that?

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] QVariant compare operator

[Giuseppe D'Angelo via Interest]

Il 18/04/20 16:53, Bernhard Lindner ha scritto:

Not comparing for equality. Comparing for ordering.

What comes first, QSize(1, 1) or QRegularExpression("^$") ?

Well, if QVariant::canConvert() says right operand can be converted to type of 
left, then
convert and compare the result. If it can't convert, behavior should be 
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable 
cases of
undefined behavior).


The biggest problem right now is that the behaviour of QVariant 
comparisons is largely undocumented, that is, dictated by the 
implementation. Any change to the these behaviours, as sensible as it 
could be, will lead to silent breakages.


I guess that's the reason for dropping the comparisons in 6.0 and, 
eventually, reintroduce it in 7.0. With the hope that we've learned the 
lesson and proceed at _specifying_ the behaviour before implementing 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] Links in PDF printed from QTextDocument

[Giuseppe D'Angelo via Interest]

Il 13/04/20 08:47, Josh ha scritto:

Also, FYI, when I export the document to html, the internal and external
linking both work. But when I print to PDF, the link is there but doesn't
work with either okular or chrome... If anyone gets internal linking in a
PDF printed from a qtextdocument let me know.


From a quick read of the code, on the other hand, looks like internal 
links are unsupported. Mind filing a bug report?


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] Links in PDF printed from QTextDocument

[Giuseppe D'Angelo via Interest]

Il 10/04/20 23:13, Josh ha scritto:

Currently, I have my own print function which generates the PDF like
following:

...
painter.translate(xmar/scale, -page*pageHeight + ymar/scale);
myDocument->drawContents(, view);
...

Any ideas about getting links into the PDF are appreciated.


This should "just work". Are the links correctly inserted in the 
document? Does it work if you use document->print() and print directly 
on a PDF?


HTH,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Giuseppe D'Angelo via Interest]

Il 31/03/20 20:34, Elvis Stansvik ha scritto:

Do you see the absurdity? For me as manager at F, to be sure we're not
breaking the contract with Frob, we would have to stipulate our
contract with G not only that they themselves stick with paid-support
Frob tools, but that they in turn must stipulate the same in their
contracts with any H type subcontractors.

And you think this will encourage people to pick commercial Qt?


Without such a clause, you could easily incorporate a wholly owned 
subsidiary, make it do all the development as "contractors" using Open 
Source Qt, get the finished product back, slap it under Commercial Qt 
and enjoy the benefits of the commercial terms without having paid for 
it during the development. That's what the clause is protecting against.


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 Creator licensing for companies with Qt Commercial developers

[Giuseppe D'Angelo via Interest]

Il 31/03/20 15:35, Tuukka Turunen ha scritto:

The point of the "Prohibited combination" is to prevent a company or a chain of 
companies (like in a typical subcontracting scenario) from making part of the product 
with non-paid Qt and part with paid. Qt being as defined in the commercial license 
agreement, i.e. including tools and framework. This was what the person initiating this 
mail thread asked about. I do agree that it gets complex when one starts including items 
created by an independent third party. This is at the moment not listed as an allowed 
case, even though it is not something we specifically aimed to prevent.


I understand the underlying reasoning 100%, but clarity is important 
here, and the ones I brought forward aren't some "far fetched" 
hypothetical scenarios.


In a product developed with Qt commercial, anyone is going to using a 
bunch of non-Qt libraries, for instance coming with any basic Linux 
installation (e.g. glibc, libstdc++, ICU, whatever). Maybe some ad-hoc 
ones, e.g. Boost. How can one be sure that none of those has been 
developed using GPL Qt Creator? Should one just "live with" the 
possibility of infringing the commercial license, because TQC is just 
not interested at chasing this case down?



Thakns,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

[Giuseppe D'Angelo via Interest]

On 3/31/20 1:22 PM, Tuukka Turunen wrote:

For completely independent projects/products this is fine. Note that these 
really should not be same or in practice the same - or in any way depending, 
relating, using etc each other as defined in the license agreement.

See licensing FAQ question 2.7 athttps://www.qt.io/faq/  and License agreement athttps://www.qt.io/terms-conditions/  


It is still unclear if the usage of Qt _Creator_ for developing some 
code would cause such code to fall under the restrictions of commercial 
licensing.



Here's a few scenarios:

1) I have a Qt commercial license. In my project using commercial Qt I 
want to use a library developed by


1a) some other team in my company;
1b) someone else.

This other library is under a liberal license; does NOT use Qt itself in 
any way; but has been developed using Qt Creator (GPL). Can I use it in 
my product under the commercial license? Or would it fall under the 
"Prohibited Combination":



“Prohibited Combination” shall mean any means to (i) use, combine, incorporate, 
link or integrate Licensed Software with any software created with or 
incorporating Open Source Qt, (ii) use Licensed Software for creation of any 
software created with or incorporating Open Source Qt


Does "created with" here extend to GPL Creator?



2) Same as 1, but this time with the library using Qt (as in: using 
headers, linking against it). Example: a Qt-based library coming from 
KDE Frameworks, developed using Creator.



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] Qt archives corrupted?

[Giuseppe D'Angelo via Interest]

Il 30/03/20 22:29, Matthew Woehlke ha scritto:

...and what, pray tell, is the point of leaving the old archives in a
half-broken state? I would either fix them, at least as far as being
correct-if-frozen-in-the-past, or take them down entirely with a note
where the new archives are located.


I think it has been mentioned before -- to avoid overloading the mirrors 
with a lot of relatively low traffic data. I don't know how the 
mirroring works, so I don't know even _if_ there is another setup that 
would work...


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