Re: [Development] Requesting a repository for Qt Interface Framework Reference APIs
Just to add another minor downside to the current name: qtif and qtifw are already quite common shorthands for Qt Installer Framework in search keywords / discussions. Elvis Den tors 7 dec. 2023 kl 20:03 skrev Maurice Kalinowski via Development : > > You are absolutely correct that this module started with a pure automotive > focus, back then called Qt IVI. > > However, we recognized that its functionality can also be utilized in a > generic way, which was the reason for the rename and generalization efforts > done in the past. There might still be some leftovers. > > > > There are developers/customers using it in their production environment > already, also outside of the automotive sector. > > > > BR, > > Maurice > > > > > > From: Development On Behalf Of Tor Arne > Vestbø via Development > Sent: Thursday, 7 December 2023 18:37 > To: Tuukka Turunen > Cc: Macieira, Thiago ; development@qt-project.org > Subject: Re: [Development] Requesting a repository for Qt Interface Framework > Reference APIs > > > > If it’s an option to rename this module we should take the opportunity to do > so I think. > > > > The problem of the generic naming came up in the past, but the understanding > was that it was too late to change. > > > > If that is not the case after all, we should strongly consider it. > > > > The documentation at https://doc.qt.io/QtInterfaceFramework/ describes it as: > > > > "The Qt Interface Framework module provides both the tools and the core APIs, > for you to implement Middleware APIs, Middleware Back ends, and Middleware > Services. “ > > > > So is this the Qt Middleware module? > > > > On the other hand, the module seems to also provide a lot more than just core > primitives. E.g. this set of classes for in-viechle infotainment systems: > > > > https://doc.qt.io/QtInterfaceFramework/qtifmedia-module.html > > > > So is this a Qt for Automotive specific module? These APIs seem to indicate > that as well: > > > > https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-vehiclefunctions-qmlmodule.html > > > > If we do want to promote this to a Qt module, should the core functionality > be split off, and the rest stay Qt for Automotive specific? > > > > https://doc.qt.io/QtInterfaceFramework/qtinterfaceframework-module.html > > > > Cheers, > > Tor Arne > > > > On 7 Dec 2023, at 17:02, Tuukka Turunen via Development > wrote: > > > > Hi, > > > > Thiago is right, we can change the name as the module technically is not part > of Qt release > (https://download.qt.io/official_releases/qt/6.6/6.6.1/submodules/). > > > > That said, we can also decide not to change the name. Like mentioned by > Dominik, it has existing since a while with the current name > (https://doc.qt.io/QtInterfaceFramework/) and repository > (https://code.qt.io/cgit/qt/qtinterfaceframework.git/). Initially it had a > different name, so the current one is already a new name, which is probably > better than the initial at least. > > > > So the question is what should this module be called, if it would be renamed? > And another question, is it feasible to implement the renaming at this point? > > > > Moving the proposed items out from it to labs modules makes sense to me. The > naming of labs modules should then be aligned with the new naming of the > module. > > > > Yours, > > > > Tuukka > > > > From: Development on behalf of Thiago > Macieira > Date: Tuesday, December 5, 2023 at 19:06 > To: development@qt-project.org > Subject: Re: [Development] Requesting a repository for Qt Interface Framework > Reference APIs > > On Tuesday, 5 December 2023 08:54:29 PST Thiago Macieira wrote: > > Then why are you asking for a repository if it's already there? When was > > that module approved by the Qt Project? I can't find anything in the email > > archives. > > > > The first commit in this repository is "First version of the QtGeniviExtras > > module". When was it renamed and who approved it? > > This module was requested at > https://lists.qt-project.org/pipermail/development/2015-August/022859.html > > There were no objections. Tuukka said it's a good idea to have the modules > even if they aren't part of the released packages: > > > I think it is fine to create the requested repo for new module. Depending on > > the need it can then either be included or not be included in the release > > packages. > > That would explain why this isn't in the qt5.git/.gitmodules. > > But I said: > > > I am, however, questioning the design of the API that Dominik presented. > > There have been zero other discussions of "genivi" since then >
Re: [Development] Memory leak in libQt5Core.so.5.15.7
Den tis 31 okt. 2023 kl 09:49 skrev Khande, Chandrakant Gulab (DBAN) : > > Hi Team, > > > > Found the memory leak in libQt5Core.so.5.15.7 > Following is the valgrind stack, can Qt help to resolve this, any fix version > available for Rocky 8 > > ==1819== 312 bytes in 3 blocks are definitely lost in loss record 13,372 of > 14,268 > ==1819== at 0x4C388C3: operator new(unsigned long) (vg_replace_malloc.c:422) > ==1819== by 0x144555E7: QEventLoop::QEventLoop(QObject*) (in > /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1819== by 0x14283480: QThread::exec() (in /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1819== by 0x142846A2: ??? (in /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1819== by 0x14BB81C9: start_thread (in /usr/lib64/libpthread-2.28.so) > ==1819== by 0x15738E72: clone (in /usr/lib64/libc-2.28.so) > > === > ==1766== 107 (40 direct, 67 indirect) bytes in 1 blocks are definitely lost > in loss record 11,877 of 14,215 > ==1766== at 0x4C39B6F: operator new[](unsigned long) (vg_replace_malloc.c:640) > ==1766== by 0x143DEB71: ??? (in /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1766== by 0x143DA27C: ??? (in /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1766== by 0x143DA403: QProcess::start(QString const&, QStringList const&, > QFlagsQIODevice::OpenModeFlag) (in /opt/Qt/lib/libQt5Core.so.5.15.7) > ==1766== by 0x143DA5D5: QProcess::start(QString const&, > QFlagsQIODevice::OpenModeFlag) (in /opt/Qt/lib/libQt5Core.so.5.15.7) > > > > Thanks, > > Chandrakant > > PROPRIETARY: This e-mail contains proprietary information some or all of > which may be legally privileged. It is intended for the recipient only. If an > addressing or transmission error has misdirected this e-mail, please notify > the author by replying to this e-mail. If you are not the intended recipient > you must not use, disclose, distribute, copy, print, or rely on this e-mail. I think this footer is incompatible with a publicly archived list like development@qt-project.org, so please omit it from future posts. > -- > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QPair vs std::pair difference with narrowing conversion
Den lör 3 juni 2023 kl 15:08 skrev Giuseppe D'Angelo :
>
>
>
> Il sab 3 giu 2023, 14:37 Elvis Stansvik ha scritto:
>>
>> Hi all,
>>
>> I was going through some legacy code and came across a behavioral
>> difference between QPair and std::pair:
>>
>> estan@edison:~$ cat test.cpp
>> #include
>> #include
>>
>> int main(void) {
>>int i = 1;
>>QPair{i, i};
>>std::pair{i, i};
>>return 0;
>> }
>> estan@edison:~$ g++ -isystem /usr/include/x86_64-linux-gnu/qt5
>> -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Wall -fPIC -c
>> test.cpp
>> test.cpp: In function ‘int main()’:
>> test.cpp:6:31: warning: narrowing conversion of ‘i’ from ‘int’ to
>> ‘unsigned int’ [-Wnarrowing]
>>6 | QPair{i, i};
>> | ^
>> test.cpp:6:34: warning: narrowing conversion of ‘i’ from ‘int’ to
>> ‘unsigned int’ [-Wnarrowing]
>>6 | QPair{i, i};
>> | ^
>> estan@edison:~$
>>
>> Just curious if anyone know why what difference between QPair and
>> std::pair makes the narrowing conversion warning pop up in the QPair
>> case and not the std::pair case?
>
>
> Because QPair is lacking constructor 3
> https://en.cppreference.com/w/cpp/utility/pair/pair
>
> https://codebrowser.dev/qt5/qtbase/src/corelib/tools/qpair.h.html
>
> That constructor hides the narrowing into std::pair's code.
Ah yes, thanks!
>
>
>>
>> Note the warning only appears when using aggregate initialization with { }.
>
>
> It's list initialization, but it's not aggregate initialization, neither
> class is an aggregate as they have user defined constructors.
Right, my bad, had the terminology wrong.
>
>
>>
>> Using GCC 11.3.0 and Qt 5.15.3.
>
>
>
> Note: I made QPair an alias to std::pair in Qt 6.
Nice, thanks.
Elvis
>
> Hth,
>
>>
>> Cheers,
>> Elvis
>> --
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QPair vs std::pair difference with narrowing conversion
Hi all,
I was going through some legacy code and came across a behavioral
difference between QPair and std::pair:
estan@edison:~$ cat test.cpp
#include
#include
int main(void) {
int i = 1;
QPair{i, i};
std::pair{i, i};
return 0;
}
estan@edison:~$ g++ -isystem /usr/include/x86_64-linux-gnu/qt5
-isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -Wall -fPIC -c
test.cpp
test.cpp: In function ‘int main()’:
test.cpp:6:31: warning: narrowing conversion of ‘i’ from ‘int’ to
‘unsigned int’ [-Wnarrowing]
6 | QPair{i, i};
| ^
test.cpp:6:34: warning: narrowing conversion of ‘i’ from ‘int’ to
‘unsigned int’ [-Wnarrowing]
6 | QPair{i, i};
| ^
estan@edison:~$
Just curious if anyone know why what difference between QPair and
std::pair makes the narrowing conversion warning pop up in the QPair
case and not the std::pair case?
Note the warning only appears when using aggregate initialization with { }.
Using GCC 11.3.0 and Qt 5.15.3.
Cheers,
Elvis
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] New Qt example development guideline and revamping examples
Den tors 19 jan. 2023 13:34Giuseppe D'Angelo via Development < development@qt-project.org> skrev: > Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: > >> All the contrary, do NOT do that, as it results in 200+ lines unnamed > lambdas. Strongly prefer named slots. Keep the lambdas short and to the > point. Do not use unnamed lambdas. > > No, strongly prefer lambdas if they are within a reasonable size. No-one > is arguing for 200+ line lambdas. > > The reason for such a harsh rule is that "reasonable size" tends to go > out of control very quickly. Is 10 lines too much? Maybe 15? Giving it a > fixed size opens up the door to a sorites paradox. The point is that > when you write the lambda the first time, it'll be completely obvious > what it does to you, even if it's long. You'll even avoid giving it a > name and connect straight to it, as it makes "perfect sense", in the > context of the code surrounding the lambda. > > But on the long run, this makes the code worse to read and understand. > No one will understand what the lambda is _meant_ to do without > analyzing the body of the lambda, line by line (cf.: a named > lambda/slot, where a proper name tells you everything). And reasoning on > the code surrounding the lambda is also much harder as it's intermingled > with the lambda itself. > > If anything: the fact that this is seen as _questionable_ and people > disagree on it should be a good indication that examples shouldn't do > it, as examples shouldn't feature _questionable_ code styles. > Agree. Code base I'm working on now is starting to get infested with "swollen" lambdas. Happens easier than you think. Elvis > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How qAsConst and qExchange lead to qNN
Den tors 17 nov. 2022 kl 18:46 skrev Thiago Macieira : > > On Thursday, 17 November 2022 02:04:54 PST Marc Mutz via Development wrote: > > > Also, sometimes I wonder if all the work you and I do to optimise these > > > things matter, in the end. We may save 0.5% of the CPU time, only for > > > that to be dwarfed by whatever QtGui, QtQml are doing. > > > > I hear you, but I'm not ready to give in just yet. > > Nor am I. > > Though I am postponing the QString vectorisation update to 6.6 because I don't > have time to collect the benchmarks to prove I'm right before feature freeze > next Friday. Fermat's Last QString Vectorization Update :p Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Cloud Software Architect - Intel DCAI Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2.6 LTS Commercial released
Yea apologies, when I said not a big deal, I meant not a big deal to me personally. Should have been clearer. Elvis Den ons 28 sep. 2022 00:51Konstantin Ritt skrev: > Ignoring a large part of the community IS a problem. > Most people won't say they aren't ok with something. Until it is too late > to say anything at all. > > Regards, > Konstantin > > > вт, 27 сент. 2022 г. в 23:02, Elvis Stansvik : > >> Den tis 27 sep. 2022 kl 21:52 skrev Elvis Stansvik : >> > >> > Den tis 27 sep. 2022 kl 21:01 skrev Thiago Macieira < >> thiago.macie...@intel.com>: >> > > >> > > On Tuesday, 27 September 2022 09:48:01 PDT Elvis Stansvik wrote: >> > > > The typical mail here is about development of Qt, and while some of >> > > > those mails may be specialized and only may not be interesting to >> > > > *everyone*, they could potentially be interesting to *anyone* (e.g. >> > > > cover some technical topic they want to learn about etc). I don't >> > > > think that can be said of commercial-only release announcement, >> which >> > > > are for sure only interesting to a certain subset of subscribers, so >> > > > suggest keeping them on some commercial-only list. >> > > >> > > For me, what's interesting is to know the *date* of the release, >> because it >> > > sets the 12-month timer for a new open source drop. >> > >> > True :) >> > >> > Open source code drops can be announced here, but I guess there's some >> > value in knowing about the first commercial-only releases, for those >> > who want to pencil in the drop date in their calendars. >> >> I guess it's just that I can understand Konstantin's sentiment, since >> it feels kind of unsolicited. When I signed up for this list, I >> solicited Qt development conversations. There is a list for >> announcements after all. It feels like I'm getting a newsletter I >> didn't sign up for, without a way to unsubscribe without losing all >> the Qt dev conversations that I do want to follow. >> >> But if most people are OK with it, no problem. It's not a big deal. >> >> Elvis >> >> > >> > Elvis >> > >> > > >> > > -- >> > > Thiago Macieira - thiago.macieira (AT) intel.com >> > > Cloud Software Architect - Intel DCAI Cloud Engineering >> > > >> > > >> > > >> > > ___ >> > > Development mailing list >> > > Development@qt-project.org >> > > https://lists.qt-project.org/listinfo/development >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development >> > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2.6 LTS Commercial released
Den tis 27 sep. 2022 kl 21:52 skrev Elvis Stansvik : > > Den tis 27 sep. 2022 kl 21:01 skrev Thiago Macieira > : > > > > On Tuesday, 27 September 2022 09:48:01 PDT Elvis Stansvik wrote: > > > The typical mail here is about development of Qt, and while some of > > > those mails may be specialized and only may not be interesting to > > > *everyone*, they could potentially be interesting to *anyone* (e.g. > > > cover some technical topic they want to learn about etc). I don't > > > think that can be said of commercial-only release announcement, which > > > are for sure only interesting to a certain subset of subscribers, so > > > suggest keeping them on some commercial-only list. > > > > For me, what's interesting is to know the *date* of the release, because it > > sets the 12-month timer for a new open source drop. > > True :) > > Open source code drops can be announced here, but I guess there's some > value in knowing about the first commercial-only releases, for those > who want to pencil in the drop date in their calendars. I guess it's just that I can understand Konstantin's sentiment, since it feels kind of unsolicited. When I signed up for this list, I solicited Qt development conversations. There is a list for announcements after all. It feels like I'm getting a newsletter I didn't sign up for, without a way to unsubscribe without losing all the Qt dev conversations that I do want to follow. But if most people are OK with it, no problem. It's not a big deal. Elvis > > Elvis > > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Cloud Software Architect - Intel DCAI Cloud Engineering > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2.6 LTS Commercial released
Den tis 27 sep. 2022 kl 21:01 skrev Thiago Macieira : > > On Tuesday, 27 September 2022 09:48:01 PDT Elvis Stansvik wrote: > > The typical mail here is about development of Qt, and while some of > > those mails may be specialized and only may not be interesting to > > *everyone*, they could potentially be interesting to *anyone* (e.g. > > cover some technical topic they want to learn about etc). I don't > > think that can be said of commercial-only release announcement, which > > are for sure only interesting to a certain subset of subscribers, so > > suggest keeping them on some commercial-only list. > > For me, what's interesting is to know the *date* of the release, because it > sets the 12-month timer for a new open source drop. True :) Open source code drops can be announced here, but I guess there's some value in knowing about the first commercial-only releases, for those who want to pencil in the drop date in their calendars. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Cloud Software Architect - Intel DCAI Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6.2.6 LTS Commercial released
Den tis 27 sep. 2022 kl 17:19 skrev Volker Hilsheimer : > > Konstantin, > > We have users with commercial licenses and access to those releases on this > mailing list as well. And some of them contribute to Qt, and are perhaps > happy to find out that a patch they might have contributed is now available > to them through an official commercial package. > > I’m sure you can configure your email client to send all emails with subject > “.*LTS Commercial released” to the bin if these announcements are irrelevant > to you. While that is true, I think the criteria for sending something to a public mailing list should be that the mail could *potentially* be of interest to anyone on the list, otherwise you are just spamming a potentially large number of subscribers. It's basic netiquette. The typical mail here is about development of Qt, and while some of those mails may be specialized and only may not be interesting to *everyone*, they could potentially be interesting to *anyone* (e.g. cover some technical topic they want to learn about etc). I don't think that can be said of commercial-only release announcement, which are for sure only interesting to a certain subset of subscribers, so suggest keeping them on some commercial-only list. Elvis > > Volker > > > > On 27 Sep 2022, at 13:28, Konstantin Ritt wrote: > > > > Please stop announcing this kind of updates through the development mailing > > list! > > > > > > Konstantin > > > > > > вт, 27 сент. 2022 г. в 14:20, Tarja Sundqvist : > > Hi all, > > > > > > > > we have released Qt 6.2.6 LTS Commercial today. Please see the blog post: > > > > https://www.qt.io/blog/commercial-lts-qt-6.2.6-released > > > > > > > > Big thanks to everyone involved & have nice autumn! > > > > > > > > Best regards > > > > Tarja Sundqvist > > > > Release Manager > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Repository request: playground/qtscrypt
Den ons 31 aug. 2022 kl 21:34 skrev Konrad Rosenbaum : > > Hi, > > On 31/08/2022 20:57, Cristián Maureira-Fredes wrote: > > > > > > On 8/31/22 19:19, Aleix Pol wrote: > >> On Wed, Aug 31, 2022 at 4:47 PM Cristián Maureira-Fredes > >> wrote: > >>> > >>> Hey there, > >>> > >>> I would like to request a new repository on codereview.qt-project.org > >>> > >>> Name and description: qtscrypt - Script C++ with Python > >>> Responsible person: Cristián Maureira-Fredes > >>> (cristian.maureira-fre...@qt.io) > >>> Desired repository name: playground/qtscrypt > >>> URL of existing code: https://git.qt.io/crmaurei/qtscrypt > >>> > >>> Thanks > >> > >> Won't this be confusing? We have had QtScript for the longest time and > >> it looks like a typo. > > > > thanks for the comments. > > > > I was under the impression that changing the 'i' for a 'y' > > from P'y'thon was not confusing, because it was already > > mentioned in a couple of talks and nobody mentioned > > anything against it. > > Even more fun: scrypt is the name of a password encryption algorithm and > the corresponding library. Was going to point this out too. That's what I first thought it was when I saw the e-mail subject - some Qt wrapper for that lib :p Elvis > > > > I wanted to avoid qtscript-python because it's not really qtscript, > > it's just the main idea from it. > > > > Do you have any other name suggestion? > > (I really struggled with finding a name) > > QtPython > > QtPythonScripting > > QtPythonAPI > > QtYetAnotherPythonBinding > > QtNowForSomethingCompletelyDifferent > > QtBrightSide > > QtHesTheMessiah > > (SCNR) > > > Sorry for having completely missed the ball here, but what makes this > new Python binding worthwhile when there's already PyQt, Qt-for-Python > and PySide? > > > Hopefully it's not a QtDeadParrot, I'd prefer a QtHolyGrail... :-P > > > [I'll see myself out now and do something useful instead, sorry.] > > > Konrad > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Maintainance Tool
You answered two out of the five questions Konrad had. Can you answer the remaining ones? Cheers, Elvis Den lör 5 mars 2022 kl 11:08 skrev Tuukka Turunen : > > Hi Konrad et al, > > > > Like already mentioned Qt Project systems, code.qt.io repositories, github > mirror etc are not blocked. Online installer for open-source users is blocked > from Russia and Belarus based IP addresses. Plan is to block also > download.qt.io and possibly some of the qt.io websites. These are done based > on IP address. > > > > Blocking the installer and access to binaries affects a much larger number of > users than those who are active in the community. It impacts also many who > create closed source products using the open-source Qt. > > > > Yours, > > > > Tuukka > > > > From: Development on behalf of Konrad > Rosenbaum > Date: Friday, 4. March 2022 at 23.25 > To: development@qt-project.org > Subject: Re: [Development] Maintainance Tool > > Hi Tuukka, > > I believe an official statement from the Qt Company is in order - right now > people are forced to find out the hard way whether they are blocked and how > far the block goes. It is impossible to tell whether it is on purpose or not > and what the purpose would be. > > It does not matter what side people are on, they deserve to know what's > happening to them. > > It's also easier to accept and support this, if we know what "this" is. > > > > Please state very clearly: > > Who is being blocked? (Location, commercial customers, open source users, > developers, ...?) > > Why are they blocked and for how long? (We might even agree with your > reasoning.) > > What services are supposed to be blocked and which ones are not supposed to > be blocked? (Commercial vs. Open Source, Binary vs. Source Downloads, Users > vs. Contributors, ...) > > Where to report bugs in this block? (e.g. is Konstantin really supposed to be > blocked from contributing?) > > And what discussions will be redirected to /dev/null? > > > > Right now we live in a situation that we all had hoped would not occur again > in Europe. We had hoped that the hard learned lessons of our grand parents > would prevent this from happening. Let's at least try to be a voice of reason > in this situation. > > > > Konrad > > > > On 04/03/2022 17:34, Tuukka Turunen wrote: > > Hi, > > > > Like already mentioned, use of the online installer is blocked from certain > IP addresses. > > > > Access to the Qt Project source code repository has not been blocked. > > > > If you wish to discuss this, please remember > http://quips-qt-io.herokuapp.com/quip-0012-Code-of-Conduct.html > > > > Yours, > > > > Tuukka > > > > From: Development on behalf of > Konstantin Ritt > Date: Friday, 4. March 2022 at 18.23 > To: Denis Shienkov > Cc: Qt development mailing list > Subject: Re: [Development] Maintainance Tool > > Plz restrain your emotions. There is no reason to spread hysteria even more. > > > Konstantin > > > > > > пт, 4 мар. 2022 г. в 19:09, Denis Shienkov : > > Yes, it's kind of hysterical. I don't understand what the Qt company wants to > achieve in the end? What is the purpose? > > So far, it looks more like a clowning: "the circus is gone, but the clowns > remain." > > Qt Company can't stick your tongue out of the USA ass? :) > > I had a higher opinion of Qt Company up to this point ... > > This is not serious somehow, some kind of kindergarten. LOL. :) > > BR, Denis > > > > 04.03.2022 18:58, Konstantin Ritt пишет: > > As long as I can fetch sources I wouldn't take any actions. > > But anyways, bringing your own political preferences to the open source world > rules is a quite hypocritical move. > > In the adult world, it doesn't matter if your community members / > contributors have a skin tone, political or sexual preferences not like > yours, or an IP address that belongs to some particular territory. > > > > Disappointed Konstantin > > > > > > пт, 4 мар. 2022 г. в 18:01, Andy Shaw : > > Hi, > > > > It is because your IP is detected to be in a country we do not allow > downloads. If you are not able to access something you have purchased then > let me know and I will get someone to get in touch with you directly about > this. Otherwise, for the time being, this IP block will be in place. > > > > Regards, > > Andy > > > > From: Development On Behalf Of > Konstantin Ritt > Sent: Friday, March 4, 2022 1:43 PM > To: Konstantin Shegunov > Cc: Qt development mailing list > Subject: Re: [Development] Maintainance Tool > > > > I don't care. I need some explanations here, at public dev ML. > > > Regards, > Konstantin > > > > > > пт, 4 мар. 2022 г. в 15:27, Konstantin Shegunov : > > Hi, > I imagine you're using a russian IP address, so this[1] should shed some > light on the matter. > > Kind regards, > Konstantin. > > [1]: https://forum.qt.io/topic/134724/unlock-qt-in-russia > > > > > ___ > > Development mailing list
Re: [Development] Feature freeze exception for QTBUG-95587
Den tors 9 sep. 2021 kl 17:33 skrev Ulf Hermann : > > Hello, > > due to the magnitude of the above mentioned bug, I'm considerng to > introduce a new feature in Qt 6.2.1. The new "@" operator in QML > relieves you from typing "Qt.resolvedUrl" over and over. See > https://codereview.qt-project.org/c/qt/qtdeclarative/+/369987 > > Now the question is whether we want to relax the feature freeze for this > particular issue or not. From a somewhat outside (user) perspective, my language-wart alarm goes off by this. I don't think introducing completely new syntax for something as specific as URL resolution is something that should be squeezed into the language during a feature freeze. Yes, URLs are vital to QML I guess, but are they *that* vital? The bar should be quite high IMO. In the apps I've worked on, URLs and URL handling is really not central at all. That is anecdotal, but it would then be good to see examples of QML apps where the lack of an @ operator for URL resolution would be unbearable. I don't see what's inherently wrong with a plain function like Qt.resolvedUrl. It's very obvious - it says what it does on the tin. Names are good that way. @ on the other hand would be completely opaque to a newcomer. When in a later mail, you reject qsUrl as an alternative to Qt.resolvedUrl because 'it doesn't express "resolved"', I must ask: How exactly does @ express "resolved"? Could you perhaps introduce a plain function for this, like e.g. Qt.resolvedUrl, or maybe put it inside the string as "csd:foo.png", and let the question of syntactic sugar stew a bit? Taking Python as example, one could compare this to the discussions preceding the recent introductions of the walrus and union operators. Those were very long processes. Granted Python has many times the number of users, but still. Just my two cents. Elvis > > Some background: > > In Qt5, the QML engine resolves a relative URL as soon as it is assigned > to any property of type "url" or QUrl. This means that you cannot store > relative URLs in such properties, and reading such a property back in > QML gives you a different value than the one you have written. The base > URL used for resolving is the URL of the QML document where the > assignment happens. This is often not the place where the URL is meant > to be resolved. There were a number of bug reports about these > shortcomings in Qt5, especially when combined with URL interception > and/or redirection. See for example QTBUG-81244 QTBUG-88965 QTBUG-66690 > QTBUG-76879 > > In Qt6, URLs are simply not resolved anymore when assigning them to a > property. This conveniently gets rid of all the cruft and inconsistency > resulting from the Qt5 behavior. Instead the individual elements using > URLs (Image, ShaderEffect, ...) are free to resolve them to their > liking. There is suitable functionality exported from QtQml to do that. > > Now, there is one problem, QTBUG-95587: The original context where a URL > was first assigned to a property is not easily available to the final > consumer of the URL. At the same time, the element consuming the URL > might be deeply nested in the implementation details of some module and > might have a rather internal base URL. In this case, the URL as resolved > by the consumer is not very useful. > > A user can fix this by explicitly calling Qt.resolvedUrl() in order to > resolve the URL in a specific context and make it absolute. As we need > URLs rather often in QML, we will see much more Qt.resolvedUrl() in Qt6 > than we have seen in Qt5. As Qt.resolvedUrl() is quite a mouthful, there > should be a shorthand for it: the '@' operator. > > So, is this bad enough for an exception, or should we rather live with > Qt.resolvedUrl() in 6.2. I'm tentatively in favor of the exception > because 6.2 is a rather important release and this is a rather ugly wart > in the QML language. > > best regards, > Ulf > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Merging qtquickcontrols2 into qtdeclarative
Den tis 13 juli 2021 kl 10:45 skrev Oswald Buddenhagen
:
>
> >On 12 Jul 2021, at 21:19, Thiago Macieira
> >wrote:
> >> So a full history import MAY have negligible marginal impact over a
> >> squashed import (.git is compressed).
> >
> that might be the case.
>
> but the point remains that the history that didn't exist along the
> merged mainline would live elsewhere (unless we'd import all branches
> and tags as well - we actually did that in qt creator, and it looks
> kinda weird and confusing).
>
> On Mon, Jul 12, 2021 at 11:22:54PM +0200, Elvis Stansvik wrote:
> >Personally I'm always frustrated when I hit a dead end during git
> >blame.
>
> >Even if the original repo will be kept around, it's an added
> >obstacle.
> >
> a rather small obstacle, given that we have a git-qt-grafts script that
> pretty much completely automates the process (it would actually need a
> bit of a revamp by now).
Yea, I just thought it a good idea to follow Thiago's suggestion to
see what the cost would be to do a full history import. But I may have
misunderstood what is even possible and not.
As an outsider doing a sort of drive-by git blame trying to find the
rationale for something, I may not know about special tooling that Qt
has.
But yes, you folks who work day to day on Qt should decide. Just
wanted to chime in with my opinion.
>
> >And at some point, I'm sure it will no longer be available.
> >
> we keep around all repos. the remote may just need an adjustment to
> point to {graveyard}/.
Alright, that's good. In the project I was digging through the other
week, the commit that added the code didn't even say where it came
from, just something like "Code moved from old repo", and after
extensive searching I concluded that "old repo" was no longer online.
Qt being a more serious project, I'm sure you guys will leave a better
commit message and won't start bulldozing over your {graveyard}/ :)
Elvis
>
> (speaking of which, it might be actually time to do that with qt.git,
> rather than only renaming it.)
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Merging qtquickcontrols2 into qtdeclarative
Den mån 12 juli 2021 kl 22:45 skrev Tor Arne Vestbø : > > > > > On 12 Jul 2021, at 21:19, Thiago Macieira wrote: > > So a full history import MAY have negligible marginal impact over a squashed > import (.git is compressed). I recommend trying both and seeing by how much > the qtdeclarative repository increases, then deciding whether "git blame" and > "git log" working out of the box without a "git replace" is worth the extra > cost. > > > That’s a good point. Concur. Personally I'm always frustrated when I hit a dead end during git blame. Even if the original repo will be kept around, it's an added obstacle. And at some point, I'm sure it will no longer be available. Just the other week I was trying to find the rationale for something in a (non-Qt) project, and hit that kind of dead end. The code had been moved in from another repo, without history, and the original repo was not available anymore. Elvis > > Cheers, > Tor Arne > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Moving IRC from Freenode to Libera.Chat, voting thread
Thanks for taking care of this Peppe. Elvis Den lör 29 maj 2021 kl 18:24 skrev Giuseppe D'Angelo via Development : > > Hi, > > On 28/05/2021 00:06, Giuseppe D'Angelo via Development wrote: > > On 22/05/2021 03:06, Giuseppe D'Angelo via Development wrote: > >> == DEADLINE FOR VOTING == > >> > >> 23.59 CEST of Thursday 27 May 2021. > > We have unanimous consent. > > == Update == > > This is now in effect. We have control over the #qt-* channels on > Libera. Our official presence is there now. > > Most of the channels in the #qt-* namespace have been re-registered, > incl. #qtwebkit, #qtwebengine, #qbs. Please contact me (in private > email) if you want to manage some of those. > > The online communities wiki page has been updated. > > > == What does this mean for me == > > Simply make your IRC client to irc.libera.chat/6697 (TLS), join the same > channels. If you prefer Matrix, a bridge has been set up. > > The first time you connect, consider re-registering your nick, and > configure your client to authenticate there. That's it. > > > == Next steps == > > 1) I'd like some volunteers as backup community contacts, so I'm not the > SPOF of the whole operation. Please write to me (in private email) if > you're interested. > > 2) We'll (slowly) rebuild the ACLs. Approvers and other channel > "owners", if you wish, please write to me (in private email!) telling me > your nick registration on Libera, so I can give you powers on #qt-labs. > Similarly please tell me if you want a hostname cloak. > > 3) I'm not changing topics nor auto-join messages in the Freenode > channels, for a few more days at least, to give people an opportunity > to move quietly. It seems that the sole mention of Libera.Chat is > sufficient for the Freenode staff to forcibly take the channels over, > and I would like to avoid "drama" if possible. Still, this is an active > threat, so the sooner people move, the better. > > https://i.imgur.com/laFn6MM.png (#qt-fr being seized) > > https://www.devever.net/~hl/freenode_abuse2 > > > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Freenode's IRC
Den fre 21 maj 2021 kl 20:25 skrev Giuseppe D'Angelo via Development : > > On 21/05/2021 20:03, Tuukka Turunen wrote: > > > > Before simply voting for new irc provider, I would still prefer to have > > the QtCS discussion on the topic. > > > > We should also discuss and define what is the intention / intentions of > > the channels, because this can affect the choice. > > I am NOT proposing any changes of the current intentions, usages, > administration, policies; just a mere move of the network. Any further > discussion on the evolution of the online chat services can certainly > happen at QtCS. Really, this thread blew completely out of scope. I'm > pretty sure that if the whole Freenode thing didn't explode, no one > would be discussing the point of "improving the Qt communities" (given > no one has EVER raised that objection in the last, dunno, N years). > > Right now, the reality is that freenode is short-staffed, being rallied > by spambots (which are not being stopped promptly because... > short-staffed), and several people (including me) don't want to spend > there one second more than necessary. A lot of big projects have already > decided to move. For those who still care about IRC, waiting another > month to get a decision is fundamentally a death sentence for those > channels. > > > > If it is for contributors to discuss with each other and release team > > meetings it may be different than if intention is to discuss with Qt > > users. For the latter purposes we should have a bit wider discussion and > > also plan how to best link this to the needs of today. For the former we > > should also consider how to attract new contributors, not only think > > what works best for existing. That being important as well. > > > > Another important thing to note is that everyone developing Qt is now > > pretty much focused in completing thing for Qt 6.2 FF. So now is not the > > best time to plan how to develop the communication channels. > > And in fact I'm not asking for ANY change whatsoever, except for a > network move. Then, keep exactly what we're doing today. > If people can find the time to participate to Dev/Des, and are on IRC, > they can find 10 minutes to express their preference on this matter. > Even a failed vote is OK: it means Libera.Chat can release the block on > the #qt* namespace, and the Qt community there can re-acquire and > re-organize those channels. I vote move to Libera.Chat, and also agree discussions about other chat services should be held later. Elvis > > > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] gst-plugins-bad Merge request: 1950 wasapi
Wrong mailing list? :p Elvis Den sön 25 apr. 2021 kl 15:48 skrev Jonas Kvinge : > > Hi > > Is there anything stopping this from being merged? > > https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1950 > > wasapi is not usable without this fix. > > Jonas > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] State of "binary JSON" in 5.15+?
Den tors 15 apr. 2021 kl 21:17 skrev Thiago Macieira : > > On Thursday, 15 April 2021 07:36:08 PDT Stottlemyer, Brett (B.S.) wrote: > > On 4/14/21, 12:53 AM, "Development on behalf of Thiago Macieira" > > > > wrote: > > > No, that was it. I assume you're caching templates which you need to > > modify slightly for each reply, not plain-text JSON. > > > > Ahh, no. Sorry for not being clear. I'm the consumer of the REST API, not > > the producer. > > This made it even less clear. > > I was trying to draw the distinction between prepared JSON in a QString or > QByteArray and a template that you needed to fill in. For example, suppose you > need to send a POST with JSON data but you need to fill in some information in > that POST before sending, such as a URI or an ID. > > Because if the contents don't change, there's no need to use QJsonDocument, > binary or not, to cache the request or reply. You can do that in QString or > QByteArray form. With the risk of muddling things even more, but the way I understood > Think geographic data, where I can prefetch at low-priority, and load/process > data on-demand as location changes. was that his use case was: 1. In the background, proactively fetch some JSON that might be needed soon, parse it and store it as "binary JSON". 2. When the time comes and the data is needed, it can be loaded fast from disk with fromBinaryJson. And with 5.14, step (2) was faster than loading from JSON text due to the mmapping, but in 5.15 it is slower (due to the change in change in in-memory format). It's quite possible I've misunderstood though. Elvis > > > In Qt 5, the existing methods in QJsonDocument continue to work like > > they have done since 5.0. > > > > I think you are saying this with a different use-case in mind, and I'd like > > to understand your use-case. For my use-case, I disagree with your > > statement. Qt 5.14 could memcpy and cast a QByteArray into a QJsonDocument > > (untested, but by inspection of the Woboq code and the documentation saying > > binary JSON was "fast for mmap"). Qt 5.15 can't, although the > > fromBinaryJson API is still supported. > > The in-memory format of QJsonDocument and related classes has indeed changed. > But from your point of view that's not relevant. If you cache the prepared > template in the form of a QJsonDocument, the behaviour and performance should > be the same in either 5.14 or 5.15. > > But that also means there's no reason to talk about the binary format any > more. It's not a caching technique. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
Den tis 23 feb. 2021 21:27Joerg Bornemann skrev: > On 2/23/21 8:52 PM, Thiago Macieira wrote: > > On Tuesday, 23 February 2021 00:00:22 PST Joerg Bornemann wrote: > >> On 2/20/21 2:44 AM, Thiago Macieira wrote: > >>> Besides, doesn't Windows now have symlinks? > >> > >> For admin users only unless an admin user enables them for everyone. > >> Hard-links are available though on NTFS. > > > > Can we use the hard-links then? > > CMake supports creating hard links with file(CREATE_LINK). > > "cmake --install" does not directly support creating hard links. One > would probably have to use install(SCRIPT) with a script that runs > file(CREATE_LINK). > > For the installer, 7zip supports storing hard links since 9.33. > > Without trying anything, it looks like using hard links could work. > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but I don't know if that's a thing. Could be considered an edge case and documented not to work. Elvis > > Cheers, > > Joerg > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
Den fre 19 feb. 2021 01:26Thiago Macieira skrev: > On Thursday, 18 February 2021 08:30:16 PST Elvis Stansvik wrote: > > I think just suffix all the binaries (all of them) everywhere, and update > > the docs everywhere. See how simple it would be. Yes it will cause some > > breakage, but definitely worth it in my opinion. > > We don't even need to cause breakage. Just install both names and update > the > docs to the new names. > Yea that would work, but what about Windows that doesn't really have symlinks? Would you install copies of the executables under both names? With everywhere I meant including the SDK from TQtC. Elvis > On a source build, make the public bindir == private bindir. For > system-wide > builds, the distributor chooses to separate. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 co-installability with Qt 5
I think just suffix all the binaries (all of them) everywhere, and update the docs everywhere. See how simple it would be. Yes it will cause some breakage, but definitely worth it in my opinion. Elvis Den tors 18 feb. 2021 17:25Thiago Macieira skrev: > On Thursday, 18 February 2021 01:56:55 PST Tor Arne Vestbø wrote: > > > Make that "mac building" too, because it shall apply to Homebrew. > > > > > > Sorry, no. If Homebrew renames binaries, that’s a Homebrew documentation > > installation documentation issue. How Qt is built from source on macOS > has > > no relation to that. > > The point is that it applies to more than one platform, including mac. > Therefore, it should be more visible than "linux-building". > > Also, Qt when built from sources should match the majority of build styles > too. Or put another way: what do we lose by having the common name that > everyone shares in the default? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Applications using -fno-rtti
Den sön 21 juni 2020 kl 14:37 skrev Konstantin Ritt : > > > I think we then had discussions when moving from Qt 4 to Qt 5, that we will > > start requiring RTTI. > > However this was never promoted, and now you're saying people who ported > their projects with no-rtti to Qt5 had to enable rtti years ago or expect > crashes?) > > Thanks to Alberto for pointing this issue now, when the majority didn't > switch to the new LTS yet. > I, for example, didn't know the issue with dynamic_cast across dll boundaries > is not an issue anymore. > > Plz make sure the documentation is up to date and `CONFIG += rtti_off` does > nothing as of 5.15. Don't touch CONFIG += rtti_off, since QMake can be used for non-Qt projects, who may want the ability to toggle this. Agree the docs should be updated, and it should have been more clearly communicated. The -no-rtti configure switch for Qt itself was removed with https://codereview.qt-project.org/c/qt/qtbase/+/182660 (since Qt 5.8). Elvis > > Regards, > Konstantin > > > вс, 21 июн. 2020 г. в 14:23, Lars Knoll : >> >> >> >> > On 21 Jun 2020, at 13:10, Giuseppe D'Angelo via Development >> > wrote: >> > >> > Il 20/06/20 22:45, Thiago Macieira ha scritto: >> >> On Saturday, 20 June 2020 11:31:25 PDT Alberto Mardegan wrote: >> >>> I think I missed an announcement about Qt applications having to use >> >>> RTTI; on the opposite, I thought that the whole point of QMetaObject was >> >>> not to require RTTI support; has this changed? >> >> As you can see from the commit, no provision was made for no-RTTI builds. >> >> I >> >> don't think they've ben allowed since 5.0. >> > >> > The Qt coding policy document still says that no RTTI facilities are >> > allowed within Qt: >> > >> >> https://wiki.qt.io/Coding_Conventions >> > >> > (Unchanged since 2015; before, I'm sure that document was somewhere else, >> > with the same contents regarding this matter.) >> > >> > Where/when was such a change of policy decided? >> >> We didn’t want it in earlier versions of Qt for mainly two reasons. Early >> implementations had quite an overhead on library size, and dynamic_cast >> didn’t work reliable between DLL boundaries on Windows. Both problems have >> gone away many years ago. >> >> I have to go by what I remember now, but I think we then had discussions >> when moving from Qt 4 to Qt 5, that we will start requiring RTTI. The >> reasons where that dynamic_cast<> and typeid require it and it has very >> little overhead on library size (as opposed to exceptions which are still >> optional). By that time (or maybe even earlier), we also started compiling >> Qt with RTTI enabled on all platforms. >> >> But it looks like nobody ever adjusted the wiki page :/ >> >> We are making use of dynamic_cast and typeid in Qt nowadays, so I guess it’s >> high time we adjust the wiki. >> >> Cheers, >> Lars >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
Den tis 9 juni 2020 kl 16:30 skrev Matthew Woehlke : > > On 09/06/2020 03.55, Joerg Bornemann wrote: > > The description of QT_NO_MAKE_TESTS is: "Should tests be built as part > > of the default 'all' target." Meaning this variable controls whether > > tests are build by default. > > Might I suggest a less obtuse name? Something along the lines of > QT_TESTS_EXCLUDE_FROM_ALL would be more typical. +1 > > -- > Matthew > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Multimedia as Add-on in Qt 6
Den fre 22 maj 2020 kl 21:40 skrev Giuseppe D'Angelo via Development : > > On 5/22/20 7:43 PM, Jason H wrote: > > I guess to some degree it depends on how you define "essential". > > The definition is: > > "Qt Essentials define the foundation of Qt on all platforms. They are > available on all supported development platforms and on the tested > target platforms." Let me include more of that quote [1]: "[...] Essential modules are general and useful for a majority of Qt applications. A module that is used for a special purpose is considered an add-on module even if it is available on all supported platforms." I agree that according to that definition, QtMultimedia (and arguably QtSQL?) is not essential. Though it's going to be hard in some cases to determine if something is clearly useful for a majority of Qt applications.. I mean, what about QtNetwork? One could say that is "special purpose", but somehow I don't think it's going to be dropped from Essentials :) Elvis [1] https://doc.qt.io/qt-5/qtmodules.html#qt-essentials > > This summarizes two distinct requirements: > > 1) a technical requirement: the module must work on all platforms. > > 2) a maintenance requirement: the module maintainers must ensure it will > work on all platforms throughout Qt 6.x lifetime (and if it doesn't, on > ANY platform, it becomes a release blocker). > > > QtMM may satisfy 1) (at the moment, cf. making it work on RTOS or so) > but you can't argue with the maintainer about 2). > > > On the other hand: "addon" does not mean "deprecated" or "unsupported" > or any of the sorts. Qt3D, QtDbus, QtWebEngine, QtImageFormats and many > others are "addon" modules and they are fully supported. > > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QString and related changes for Qt 6
Den tors 14 maj 2020 15:46Marc Mutz via Development < development@qt-project.org> skrev: > On 2020-05-13 17:17, Matthew Woehlke wrote: > [...] > > Non-owning QString is dangerous. QStringLiteral is less dangerous > > because it is almost never used with non-rodata storage (and indeed, I > > would consider any such usage highly suspect, if not outright broken). > > QString::fromRawData is dangerous, but "obviously" so. > > > > We should not implement any way of creating a non-owning QString that > > is not explicit, and if we adhere to that, I don't see us *not* > > wanting QStringView in many instances. > > I must be crazy, but ... +1! > *chuckle* :) > Thanks, > Marc > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
Den tors 23 apr. 2020 kl 13:38 skrev André Pönitz : > > On Thu, Apr 23, 2020 at 12:48:45PM +0200, Elvis Stansvik wrote: > > Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs : > > > > > > That depends on the number of the functions affected, and how commonly > > > those > > > are used. If we are talking about just a few virtual functions here and > > > there > > > which are not expected to be overriden by a vast majority of applications > > > (such as the QIconEngine example), then changing the signatures is > > > probably > > > acceptable. After all, Qt 6 will have a number of source compatibility > > > breaks > > > (typically in less commonly used APIs) anyways, let's have no illusions > > > here. > > > So on its own this should not be an argument for reprioritizing the > > > tainted > > > QList name. > > > > > > For years we have been teaching people to stay away from QList and treat > > > it as > > > a legacy thing in the API, and that it may change in a future major > > > release. > > > Any newly introduced public APIs (in the graphics-related areas at least) > > > for > > > the past 5-6 years are using QVector. It is odd to turn this over just > > > like > > > that. > > > > I have to agree with Laszlo here. The message has been that QList due to its > > duality etc is problematic and may become deprecated, so we've put in work > > on > > changing it to QVector in our code bases [...] > > Was that work more than s/QList/QVector/ ? No, not really, plus looking through the code in each case to make sure it didn't rely on some QList peculiarity. But it was not much work. As I said, I'll accept whatever is decided, but think it would be a little strange to make this turn in the recommendations at this point. Everyone who has done this change to QVector will then have to go back to QList. Elvis > > >and used QVector in newly written > > code. It's a bit annoying if QList is now to become the name to be used. > > I'll > > accept whatever is decided, but think it's a little unfortunate if we'd > > have to > > change all that code back to QList again. > > Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Deprecate QVector in Qt 6
Den tors 23 apr. 2020 kl 11:45 skrev Laszlo Agocs : > > That depends on the number of the functions affected, and how commonly those > are used. If we are talking about just a few virtual functions here and there > which are not expected to be overriden by a vast majority of applications > (such as the QIconEngine example), then changing the signatures is probably > acceptable. After all, Qt 6 will have a number of source compatibility breaks > (typically in less commonly used APIs) anyways, let's have no illusions here. > So on its own this should not be an argument for reprioritizing the tainted > QList name. > > For years we have been teaching people to stay away from QList and treat it > as a legacy thing in the API, and that it may change in a future major > release. Any newly introduced public APIs (in the graphics-related areas at > least) for the past 5-6 years are using QVector. It is odd to turn this over > just like that. I have to agree with Laszlo here. The message has been that QList due to its duality etc is problematic and may become deprecated, so we've put in work on changing it to QVector in our code bases, and used QVector in newly written code. It's a bit annoying if QList is now to become the name to be used. I'll accept whatever is decided, but think it's a little unfortunate if we'd have to change all that code back to QList again. Elvis > > Best regards, > Laszlo > > > > > From: Simon Hausmann > Sent: Thursday, April 23, 2020 10:52 AM > To: Laszlo Agocs ; Jaroslaw Kobus ; > Lars Knoll > Cc: Qt development mailing list > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > Hi, > > If we did the search & replace and use QVector throughout our API, won't that > make it harder for our users to maintain a code base with 5 and 6? For > example if we change the signature of virtual functions. > > I think we'd do our users a favour by sticking to QList - I'm not concerned > about the popularity of Qt in online forums but rather about the practical > difficulties of developing with Qt. > > > Simon > > From: Laszlo Agocs > Sent: Thursday, April 23, 2020 10:41 > To: Jaroslaw Kobus ; Lars Knoll ; > Simon Hausmann > Cc: Qt development mailing list > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > -1 for QList. Why reuse and prioritize a name that has been tainted by plenty > of past discussions and comes with a lot of past baggage? Any Google etc. > search will bring up plenty of "QList-bad QVector-good" materials for years > to come, potentially leading to lots of Qt 5 vs Qt 6 confusion. Also, Qt 5.x > is not going to disappear overnight. > > The current status quo of QList being an alias to QVector in Qt 6, with > QVector being the primary and recommended name, is pretty good IMHO, it is > not clear to me why this would need any further changes. An additional search > & replace (QList->QVector) round in the public headers does not sound like a > bad idea at all. > > Best regards, > Laszlo > > > > > From: Development on behalf of Jaroslaw > Kobus > Sent: Thursday, April 23, 2020 10:20 AM > To: Lars Knoll ; Simon Hausmann > Cc: Qt development mailing list > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > +1 for QList. > > (6) No need to remane QStringList into QStringVector for consistency reasons. > > Jarek > > > From: Development on behalf of Lars > Knoll > Sent: Thursday, April 23, 2020 9:53 AM > To: Simon Hausmann > Cc: Qt development mailing list > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6 > > I’ve had similar thoughts lately as well. I can see a few more reasons to > keep QList as the name of the class: > > (3) Less ambiguity with QVector(2/3/4)D > (4) QList is the known type and the one promoted in our API so far, so no > need for people to re-learn Qt > (5) a lot less code churn for us and our users > > So I’m in favour of doing this and keeping QList as the name for the class. > > Cheers, > Lars > > On 23 Apr 2020, at 09:43, Simon Hausmann > mailto:simon.hausm...@qt.io>> wrote: > > Hi, > > In dev we've had QVector being an alias for QList for a while now. For the > 6.0 release this particular topic (QList/QVector) suggests two goals (among > others): > > (1) Use the same type throughout the public API of Qt. > > (2) Make it easy for our users to maintain a code base that works with Qt > 5 and 6. > > > In the light of those two goals, I think we should keep using QList as the > type in the public API. I don't think we should do a search and replace > activity and switch to QVector. In the light of that, I would like to propose > simply deprecating QVector and stick to QList everywhere. > > > What do you think? > > > Simon > ___ > Development mailing list >
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now
Den tors 6 feb. 2020 kl 20:36 skrev André Pönitz : > > On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote: > > > > > -Original Message- From: Development > > > On Behalf Of Thiago Macieira > > > > > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote: > > > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira > > > > > > > > wrote: > > > > > The correct signal for an error situation is errorOccurred, like in > > > > > QLocalSocket and QProcess. > > > > > > > > Actually both QLocalSocket and QAbstractSocket renamed the "error()" > > > > getter > > > > to keep using "error()" signal as opposed to many other Qt modules > > > > "errorOccurred()" signals. > > > > > > Which is the opposite of QProcess and violates the naming convention. > > > Signals > > > are named after verbs in the past tense and properties & property getters > > > are > > > simple nouns. So "error" is the getter, "errorOccurred" is the signal. > > > > Either option solves the ambiguity. What's more important to our users - a > > consistent naming convention > > or an early warning/compile error when adopting Qt 6? > > Consistent naming will be beneficial for a much longer time than any > short term incentive to adopt Qt 6. I'm with André, please focus on getting it consistent. It's one of the things I think many love about Q - they can guess what name a function will have (even without auto-complete). If this is not done for Qt 6 (a major) release, then what should it be done? (Never?). The gotcha introduced can be advertised in the release announcement, I think that's enough. My 2 cents. Elvis > > Andre' > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Den lör 1 feb. 2020 kl 14:48 skrev Sona Kurazyan : > > > > > -Original Message- > > From: Elvis Stansvik > > Sent: Friday, January 31, 2020 7:20 PM > > To: Sona Kurazyan > > Cc: development@qt-project.org > > Subject: Re: [Development] Make a decision for asynchronous APIs > > > > > > > > Additionally, there are some discussions about QFuture being a mix > > between a “Task” and a “Future”. One of the options of improving this > > situation is to make a QTask (or QJob) out of the current QFuture. But then > > the question is: should we also support a “classic” QFuture? Is there a > > value > > in having it, when there are already some very advanced implementations of > > a future? > > > > I don't have too much to comment on this. Would the alternative to QFuture > > in this scenario be a future class from somewhere else (std::future, ...)? > > And > > the Qt goodies like cancel/pause/resume/progress API would be on QTask? > > Yes, that would be my preference as well. Alright, thanks. That sounds reasonable to me too. Elvis > > Best regards, > Sona ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Make a decision for asynchronous APIs
Den fre 31 jan. 2020 kl 17:25 skrev Sona Kurazyan : > > Hi everyone, > > > > It's been a while since we've started discussions on this topic. I would like > to summarize the outcome of these discussions and propose improvements to our > asynchronous APIs based on the feedback we've received so far. > > > > First of all, there was a question weather we should keep QtConcurrent and > QFuture (and related classes) at all, and the answer seems to be "yes", > because the corresponding STL alternatives are still lacking a lot of > features: std::future still doesn't support continuations, its API is not > finalized yet, no executors are supported for parallel algorithms in C++17, > etc. Additionally, Qt's asynchronous APIs have extensions like cancelling, > pausing, resuming and progress reporting (although not everyone agrees that > these extensions fit with a typical future, but they can be useful in > Qt-specific use-cases, for example GUI applications). > > > > On the other hand, there are couple of improvements to be applied to > QtConcurrent and QFuture* , to make them more useful and keep them in Qt 6. > Here's the list of suggestions I've collected: > > > > QFuture (and related classes) > > Officially document QFutureInterface and rename it to QPromise > (https://bugreports.qt.io/browse/QTBUG-81586) > Add support for continuations to QFuture > (https://bugreports.qt.io/browse/QTBUG-81587) > Provide a way of integrating QFuture with signals > (https://bugreports.qt.io/browse/QTBUG-81589) > Improve the error reporting of QFuture > (https://bugreports.qt.io/browse/QTBUG-81588) > > > > QtConcurrent > > Rename QtConcurrent::run to qAsync() and modernize it > (https://bugreports.qt.io/browse/QTBUG-81590) > Allow passing a QThreadPool* as a parameter to QtConcurrent algorithms to > avoid exhausting all system threads. > Fix the algorithms which do not work with lambdas > (https://bugreports.qt.io/browse/QTBUG-33735) > Add initial values to map/filter reduce > (https://bugreports.qt.io/browse/QTBUG-73240) Even if I've not read all the links, to me as a user of QtConcurrent these all sounds like great improvements, bringing significant value. > > > > It would be nice to hear some opinions, to see whether this is a right > direction to go, and if it makes sense to put our effort on these > improvements. Is there anything important I’m missing in the list? Or maybe > some of these items do not add much value? > > > > Additionally, there are some discussions about QFuture being a mix between a > “Task” and a “Future”. One of the options of improving this situation is to > make a QTask (or QJob) out of the current QFuture. But then the question is: > should we also support a “classic” QFuture? Is there a value in having it, > when there are already some very advanced implementations of a future? I don't have too much to comment on this. Would the alternative to QFuture in this scenario be a future class from somewhere else (std::future, ...)? And the Qt goodies like cancel/pause/resume/progress API would be on QTask? Elvis > > > > Please share your thoughts! > > > > Thanks, > > Sona > > > > > > From: Development on behalf of Karsten > Heimrich > Sent: Thursday, December 19, 2019 2:12 PM > To: development@qt-project.org > Subject: [Development] Make a decision for asynchronous APIs > > > > Hi, > > we are planning to continue some work on the QFuture, QtConcurrent APIs, > either improve up on the existing implementation or deprecate and remove them > completely for Qt6. We’ve created a user story in Jira and like to gather > some feedback here. So if this topic is of interest for you, I would like to > point you to https://bugreports.qt.io/browse/QTBUG-80908 to place some > comments there. > > > > BR, Karsten > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den ons 29 jan. 2020 kl 06:46 skrev Thiago Macieira : > > On Tuesday, 28 January 2020 21:03:49 PST André Somers wrote: > > On 29/01/2020 04:27, Thiago Macieira wrote: > > > So you're advocating being acquired by a bigger company that has a > > > different business and regards Qt only as a means to an end? > > > > > > Can you spell "Nokia" ? > > > > Can you explain what was so bad about the Nokia period (well, before the > > burning platform Elop...)? I remember it as a period where a lot of good > > things happened for Qt actually. > > The end of it (burning platform, Elop). Big companies with deep pockets are > good for you... while they last. Then people get reassigned without notice, > departments get laid off, sites in high-cost countries get closed. And medium- > sized companies can get acquired. > > The moment they change strategy, the project you're working on and depending > on can be left to the roadside. Just go to the GitHub organisation page of any > big company (including the one I work for) and you can find hundreds of open > source projects that aren't being updated any more. Heck, at github.com/intel > you're going to find multiple EOLed projects for the same objective! > > I admire Ktiware and their commitment to CMake, but Qt is at least two orders > of magnitude more complex than CMake. I doubt the same model would work. Just want to add here: Even if CMake is probably the Kitware project with the largest number of users if counting developers, I don't think it's their flagship product. That would be the VTK framework (2500 classes, 1 MLoC) and associated libraries/applications (ParaView, CTK, ...). I think Kitware makes most of its money doing consulting/projects using those libraries for medical/defense/research/HPC. CMake just sort of fell out from their development process. So CMake is not the central part to their business strategy I think. I think they also employ quite a big of domain experts in the fields where they consult (i.e. it's not just consulting as "VTK experts"). If there's a Kitwarer here please correct me if I'm wrong. Elvis > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den tis 28 jan. 2020 kl 08:01 skrev Elvis Stansvik : > > Den tis 28 jan. 2020 kl 03:19 skrev Thiago Macieira > : > > > > On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich > > wrote: > > > I would expect a significant negative effect on the quality of Qt > > > shipped in Linux distributions and thus negative effect on the > > > Qt-based applications and Qt reputation. > > > > That is debatable since most Linux distributions do not align with the Qt > > LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but > > for > > all other LTSes, open source Linux distros seem to choose whichever version > > was latest at the time they reached feature-freeze. > > > > Current versions in: > > * Debian stable: 5.11.3 > > * Debian oldstable: 5.7.1 > > * Fedora 31: 5.12.5 > > * Fedora 30: 5.12.1 > > * Fedora 29: 5.11.1 > > * Fedora 28: 5.10.1 > > * CentOS 8.1: 5.11.1 > > * openSUSE 15: 5.9.4 (15.1 now has 5.9.7) > > * openSUSE 42.3: 5.6.2 > > * openSUSE 42.2: 5.6.1 > > * (K)Ubuntu 19.10: 5.12.4 > > * Ubuntu 18.10: 5.11.1 > > * Ubuntu 18.04 LTS: 5.9.5 > > * Ubuntu 16.04 LTS: 5.5.1 > > * KDE Neon: 5.13.2 > > * Manjaro 18.1.0: 5.13.0 > > > > There are a couple of alignments with Qt LTS above but they could be > > coincidences. openSUSE 15 was released around 6 months after the 5.10.0 > > release (and less than 3 after 5.10.1, which is when they seem to make > > upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought > > Fedora > > 31 was trying to align, but then I went to search for the current version > > and > > F32-in-development has already upgraded out of the LTS to 5.13.2. > > > > Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only > > legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would > > be the first, after 4 years of having LTS releases. > > I think they are intending to try to get Qt 5.14.1 packaged for Ubuntu > 20.04. At least that's what I've seen from the discussions in > #ubuntu-qt on freenode. So they will be de-aligning if they get that > done on time. Forgot links to back up my claim: Dec 12: https://irclogs.ubuntu.com/2019/12/12/%23ubuntu-qt.html Jan 8: https://irclogs.ubuntu.com/2020/01/08/%23ubuntu-qt.html Elvis > > Elvis > > > > > So it's completely understandable to have concluded that the LTS releases > > weren't useful to Linux distributions. > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel System Software Products > > > > > > > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den tis 28 jan. 2020 kl 03:19 skrev Thiago Macieira : > > On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich wrote: > > I would expect a significant negative effect on the quality of Qt > > shipped in Linux distributions and thus negative effect on the > > Qt-based applications and Qt reputation. > > That is debatable since most Linux distributions do not align with the Qt > LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but for > all other LTSes, open source Linux distros seem to choose whichever version > was latest at the time they reached feature-freeze. > > Current versions in: > * Debian stable: 5.11.3 > * Debian oldstable: 5.7.1 > * Fedora 31: 5.12.5 > * Fedora 30: 5.12.1 > * Fedora 29: 5.11.1 > * Fedora 28: 5.10.1 > * CentOS 8.1: 5.11.1 > * openSUSE 15: 5.9.4 (15.1 now has 5.9.7) > * openSUSE 42.3: 5.6.2 > * openSUSE 42.2: 5.6.1 > * (K)Ubuntu 19.10: 5.12.4 > * Ubuntu 18.10: 5.11.1 > * Ubuntu 18.04 LTS: 5.9.5 > * Ubuntu 16.04 LTS: 5.5.1 > * KDE Neon: 5.13.2 > * Manjaro 18.1.0: 5.13.0 > > There are a couple of alignments with Qt LTS above but they could be > coincidences. openSUSE 15 was released around 6 months after the 5.10.0 > release (and less than 3 after 5.10.1, which is when they seem to make > upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought Fedora > 31 was trying to align, but then I went to search for the current version and > F32-in-development has already upgraded out of the LTS to 5.13.2. > > Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only > legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would > be the first, after 4 years of having LTS releases. I think they are intending to try to get Qt 5.14.1 packaged for Ubuntu 20.04. At least that's what I've seen from the discussions in #ubuntu-qt on freenode. So they will be de-aligning if they get that done on time. Elvis > > So it's completely understandable to have concluded that the LTS releases > weren't useful to Linux distributions. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den mån 27 jan. 2020 kl 23:16 skrev Cristián Maureira-Fredes : > > Hello David, > > On 1/27/20 11:00 PM, David Edmundson wrote: > >> All security fixes are made available to everyone, for all Qt versions that > >> they affect, provided it's still a supported Qt version (or it was easy to > >> make the fix). > >> > > If we could have that explicitly in writing from TQC, that would mean a lot. > > The blog post states: > > "We are changing our process in R to push all bug fixes to the main > development branch first, and then backport selected bug fixes back into > stable release branches. This process ensures that the latest version of > Qt will always contain all bug fixes. This process change was discussed > during the last Qt Contributor Summit – we communicate the exact process > details when Qt 5.15 will be released. Otherwise, development processes > and the governance model will not change." > > This means that you still have access to all the fixes for 5.15 > that happen after 5.15.2-3, since they will be on the dev branch. > > > > I can easily envision a situation that affects only Qt5.15, but not > > Qt6.0 at which point it's not covered by what has been suggested > > officially so far as there would be nothing to cherry-pick. > > > > David > > If there is a bug on 5.15 and not on 6.0, > a fix will be pushed to the dev branch, then cherry pick to the > commercial LTS version, but the patch will still be there, so you > can just added to your local Qt version. Sorry if I'm misunderstanding something, but what if the bug only exists in 5.15, not in dev? I think that's the situation David is thinking of. Elvis > > The Qt Contributors Summit discussion can be found here too: > https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Branch_Policy > > > Cheers > > -- > Dr. Cristián Maureira-Fredes > R Manager > > The Qt Company GmbH > Erich-Thilo-Straße 10 > D-12489 Berlin > https://qt.io > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den mån 27 jan. 2020 kl 19:30 skrev Tuukka Turunen : > > > Hi, > > I do not know why the link does not work. But I remember that post very well. > > On hindsight, it was too much of a rush back then to ask everyone to create a > Qt account immediately. > > As I wrote in my earlier reply, situation is different now: > > Most users have already Qt account So? I have an account because I want to contribute. Does not mean I want to log in to download (especially not from CI). > Marketplace needs it This is not a non-reason. It is based on the assumption that everyone wants to use the Marketplace, which I very much doubt is the case. > More common to be connected Now I guess you're talking about the artificial pulling of offline installers, and not the Qt Account requirement. In any case, just because I have a connection does not mean I want to use it, nor provide a login to download. I may want to download the offline installer and use it X times. > > If someone does not want to use Qt account, it is possible to build from > source. No comment. Elvis > > Yours, > > Tuukka > > > Lähettäjä: Development käyttäjän > Giuseppe D'Angelo via Development puolesta > Lähetetty: maanantaina, tammikuuta 27, 2020 8:13 ip. > Vastaanottaja: development@qt-project.org > Aihe: Re: [Development] Changes to Qt offering > > Il 27/01/20 16:57, Benjamin TERRIER ha scritto: > > We do hope that this eases your concerns, and that we can continue with your > trust. > > > https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer > > > That blog post is now removed. The URL is correct, as it's cross referenced > from other blog posts. > > I won't comment on how professional this sounds. > > Anyhow: > > https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer > > > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Den mån 27 jan. 2020 kl 19:12 skrev Giuseppe D'Angelo via Development : > > Il 27/01/20 16:57, Benjamin TERRIER ha scritto: > > We do hope that this eases your concerns, and that we can continue with your > trust. > > > https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer > > > That blog post is now removed. The URL is correct, as it's cross referenced > from other blog posts. > > I won't comment on how professional this sounds. Seriously TQtC, wtf? After 20+ years of using Qt, all of this ass-hattery put together is seriously making me consider leaving and not looking back. Elvis > > Anyhow: > > https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer > > > -- > Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Rationalizing qApp and qGuiApp
Den lör 18 jan. 2020 kl 11:05 skrev Sze Howe Koh : > > Currently, > > * The qApp macro changes type depending on which headers are included, > and in what order. (If you #include but instantiate > a QCoreApplication, qApp returns a QGuiApplication pointer) > * The documentation says that the qApp macro is only valid if a > QApplication was instantiated. [1] > * The qGuiApp macro doesn't change types like qApp; it is always a > QGuiApplication pointer. > * There is no equivalent of qGuiApp for QCoreApplication and QApplication. > > To resolve this inconsistency, I propose that we do one of the > following for Qt 6: > > A) Update the documentation to say that qApp can change types. Leave > the qApp macro as-is. > > B) Leave the documentation as-is. Make the qApp macro disappear from > qcoreapplication.h and qguiapplication.h unless compatibility mode is > enabled. > > C) Rename "QApplication" -> "QWidgetApplication", keeping the former > as a typedef. Leave the qApp macro as-is but deprecated. Add the > qCoreApp and qWidgetApp macros (analogous to qGuiApp) > > Thoughts? How about deprecating the q*App variables altogether, and recommend using e.g. QCoreApplication::, QGuiApplication:: et.c. instead? Static analysis will warn when calling static functions through an instance anyway [1]. Though now I realize there are also non-static functions on these classes, so probably not reasonable to do that *facepalm*. As a user I think your suggestion sounds good. Elvis [1] https://clang.llvm.org/extra/clang-tidy/checks/readability-static-accessed-through-instance.html > > > Regards, > Sze-Howe > > [1] https://codereview.qt-project.org/c/qt/qtbase/+/174414 > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTCS2019 Notes from QtQml session
Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
:
>
> @Ekke
> I think you should redesign your qml the other way around. For your problem
> there're multiple solutions
> 1) Use some sort of StackView.view attached property. This is *usually*
> implemented with a simple upward hierarchy lookup of the first instance of a
> StackView.
> In this way you get the reference of the StackView from leaf nodes.
> 2) Pass a StackView reference to the Page at the point of instantiation
> Page1 {
>id: page1
>view: stackView // used inside Page implementation
> }
> 3) JUST DO THE RIGHT THING. Your page qml should not have code that directly
> calls the the StackView (This couples the Page to know that there's a
> StackView).
> Instead your page should just expose signals or items. The wiring between
> these signals and view is done outside.
> For example instead of:
>
> // Page1,qml
> Item {
> Button { onClicked: stackView.doSomething() } // Reference StackView by
> id..magically...awful!!
> }
>
> Do like this
> // Page1.qml
> Item {
> property alias loginButton: button
> Button { id: button }
> }
>
> // Somewhere.qml
>
> Page1 {
>loginButton.onClicked: stackview.doSomething() // Logic outside view
> }
I agree. An analog to this in Qt/C++ land would be doing something like
auto foo = static_cast(parent());
// Use foo
in a child widget, which is certainly a code smell (making assumptions
about the context).
The changes suggested would hurt our code base a little, because I
know we're guilty of this transgression in some places of our QML as
well. But I think it's worth it and the changes needed would improve
our code.
Just my 2 cents.
Elvis
>
> This solution allows Page1 to be just a view (like an old .ui file).
> In other words Page1 interface implies that there's a button or a clicked
> signal but you're free to connect its
> clicked signal to a StackView or SwipeView since wiring is done outside it.
>
> A even better solution is to delegate this to a FSM
>
> Page1 {
> loginButton.onClicked: fsm.login()
> }
>
> And then use a state of the FSM for handling the current page of the StackView
>
> StackView {
> currentPageComponent: {
> if (fsm.loginState.active) {
>return loginPageComponent
> } else if (fsm.connectedState.active) {
> return connectedState.Compononent
> }
> }
> }
>
> Best regards,
>
> Filippo
>
>
> Il giorno lun 25 nov 2019 alle ore 16:54 ekke ha
> scritto:
>>
>> Am 25.11.19 um 15:53 schrieb Ulf Hermann:
>> >> Yeah, that's going to make using QML in actual applications a whole lot
>> >> harder. For instance, sometimes access to some root node is needed even
>> >> from deep leaf files. Removing that capability is quite a drastic measure.
>> > Yes, but the problems with this construct are the same as with generic
>> > context properties: Your QML component requires some context that it
>> > doesn't declare. Therefore your code is not reusable and brittle wrt
>> > addition of properties in other places.
>>
>> h :(
>>
>> because of my own project rules my code is re-usable through all my projects
>>
>> from discussions here I learned to use SingletonInstance which can
>> replace the properties I set in my root (main.qml)
>>
>> but there are many other situations where I thinkl this won't help
>>
>> per ex
>>
>> main.qml --> StackView --> Page1 --> Page2 --> Popup
>>
>> from main there are some StackViews (+ Pages) switchedby Drawer
>>
>> Page1 or Page2 can be used on top of different StackViews
>>
>> there are some properties and functions from StackView used by Pages or
>> Popup. Can access them via id because all my StackViews have same id
>>
>> any idea how this should be refactored for QML 3 without loosing all the
>> cool flexibility ?
>>
>> >
>> > Mind that all those dynamic lookups will still live on in QML 2, and we
>> > will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.
>>
>> of course my goal is to go to QML 3
>>
>> ekke
>>
>> >
>> > Ulf
>> > ___
>> > Development mailing list
>> > Development@qt-project.org
>> > https://lists.qt-project.org/listinfo/development
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
>
>
> --
> Filippo Cucchetto
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Two-digit dates: what century should we use ?
Den tis 5 nov. 2019 15:48Kari Oikarinen skrev: > > > On 5.11.2019 15.44, Edward Welbourne wrote:> Hi all, > > > > Prompted by [0], I'm looking at what century to use for years, when the > > text being read is expected to be in a "short format" that only includes > > two digits. > > * [0] https://bugreports.qt.io/browse/QTBUG-74323 > > > > tl;dr - how do folk feel about (in Qt 6) a century-wide window, ending a > > decade or three ahead of QDate::currentDate(), and placing any two-digit > > year in that range ? > > > > Before anyone says "Don't Do That" (or "why would anyone use two-digit > > years after the mess of y2k ?"), bear in mind that CLDR (the Unicode > > consortium's common locale data repository, on which QLocale's data is > > based) provides short date formats, many of which use two-digit years. > > > > We currently fail to round-trip dates via such formats because 1900 is > > used as default year when no year is specified and (thus) 19 is used as > > default century number when only the later digits are (understood to be) > > specified. As we get further into the twenty-hundreds (as it were), > this > > shall grow to be an increasing jarring flaw in date format handling. > > I think even in the future many two-digit year formatted dates will > refer to 19xx (either because they are old or because that's the > assumption widely). So correct handling of those formats will be > impossible anyway. They don't contain enough information. But it's of > course unfortunate if the dates you stored yourself can't be read back > correctly. > > > I'm considering changing that: since it's a material behaviour change, > > it clearly needs to happen as part of Qt 6, which at least gives me a > > few months to discuss it and see what folk think is a better plan than > > what we have. > > > > It's notable that ECMAScript's Date constructor adds 1900 to any year > > number from 0 through 99 (even if supplied as one of a sequence of > > integer arguments, not a string), causing problems for the > > representation of dates from 1 BCE through 99 CE. (I must remember to > > tease my friend on the ECMA 262 committee about that - his excuse will > > be that it was copied from an early version of Java, I suspect - and see > > if he can coax them into changing it.) Likewise, C's struct tm (used by > > mktime and friends) has a 1900 offset on its year number: that's > > probably never going to change, perverse as it is and shall increasingly > > be. > > Surely that's not a comprehensive list. I don't expect either of these > to change and staying in line with other software can avoid surprises. > > I thought almost everyone would assume 1900-1999 as the range. > Apparently that's not true though. Python uses the range 1969-2068 and > C# depends on locale but appears to at least sometimes be 1930-2029. > Using two-digit years is a much worse idea than I thought since there > doesn't seem to be consensus. > > > Folk still talk about "The fifties" and mean the 1950s; probably > > likewise the forties, thirties and even twenties. That last, at least, > > shall soon be something of a problem. Folk can see more of the past > > than of the future, so perhaps it's not much of a surprise that common > > nomenclature reserves short phrases for the past at the expense of the > > future: "The sixties" shall be in the past for a few decades yet, I > > think. So rather than having a default century, and maybe changing it > > abruptly to 20 at some point in the next fifty years, I think it would > > be better to have two-digit years coerced into a century-wide window > > about the (forever moving) present. > > > > Perhaps we should make that a narrower window and treat roughly a decade > > near the wrap-around as error - e.g. using 1945--2035 as our year range, > > with two-digit years 36 through 44 treated as undecodable. > > > > The question then arises: what year-range should we use ? > > > > Two things I'm fairly sure should be true are: > > * the current year (i.e. QDate::currentDate().year(), naturally) should > >be included in the range; > > I don't think it's that obvious. Many systems start at the UNIX epoch > and then may get the current time from network later. That might > result in the year-range changing during application lifetime, which > sounds horrible. You wouldn't know what certain input results into > when reasoning statically. > Agree with this 100%. I think changing the behavior depending on what date it is is a bad idea and would risk leaving software that works one day but breaks the next. I think it's better to leave people dealing with two digit dates in the awkward spot they already are, rather trying to guess what they want by using a moving window. I think it's better Qt have one fixed behavior compiled in, even if it means at some points in the future we'll have breaking behavior changes in the library, probably in major releases, as Qt
Re: [Development] QWidget font settings propagation parent to child
Den ons 23 okt. 2019 kl 20:18 skrev Ville Voutilainen : > > On Wed, 23 Oct 2019 at 18:49, Elvis Stansvik wrote: > > > > Den ons 23 okt. 2019 16:29Henry Skoglund skrev: > >> > >> Hi, > >> > >> I use Qt Creator's excellent Form Editor, however sometimes I've noticed > >> an inconsistency in the font settings, because I'm lazy I usually only set > >> the font property for the top MainWindow and relying on it to "trickle > >> down" and affect the widgets as well. Except sometimes it doesn't trickle > >> down :-( So I wrote a test app, just a main.cpp: > > > > > > I don't want to be that person who always asks "why are you even doing > > this", but.. Why are you even doing this? :p > > > > Changing the font is normally not recommended. I think the best practice is > > to let the font remain as the platform plugin decided, so that the user's > > choice of font is respected. > > And if the user changes their choice, should it be possible to reflect > that dynamically on a running application? I have no trouble coming up > with dozens of use cases where you want to change the font of an > application, or a part of its widget hierarchy. I believe you get that for free if you leave the font alone. At least my Qt applications change when I change my system font choice under KDE. Elvis ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWidget font settings propagation parent to child
Den ons 23 okt. 2019 16:29Henry Skoglund skrev:
> Hi,
>
> I use Qt Creator's excellent Form Editor, however sometimes I've noticed
> an inconsistency in the font settings, because I'm lazy I usually only set
> the font property for the top MainWindow and relying on it to "trickle
> down" and affect the widgets as well. Except sometimes it doesn't trickle
> down :-( So I wrote a test app, just a main.cpp:
>
I don't want to be that person who always asks "why are you even doing
this", but.. Why are you even doing this? :p
Changing the font is normally not recommended. I think the best practice is
to let the font remain as the platform plugin decided, so that the user's
choice of font is respected.
I guess there are exceptions, like wanting fixed-width in some place, or
changing the font size, but changing the font family for the entire
application seems very invasive.
You may of course have valid reasons, and of so I'm afraid I can't help.
What you describe sounds like a bug/oversight to me.
Elvis
>
> #include "QtWidgets"
>
> int main(int argc, char** argv)
> {
> QApplication a(argc,argv);
> QMainWindow w;
>
> auto listFonts = []
> {
> for (auto pKid :
> w.findChildren("",Qt::FindDirectChildrenOnly))
> qDebug() << pKid->metaObject()->className() <<
> pKid->font().family();
> };
>
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
>
> qDebug() << "Before w.show();"; listFonts();
>
> w.show(); // start the party
>
> qDebug() << "\nAfter w.show();"; listFonts();
> }
>
> The above app simulates what Qt Creator's Form Editor does (or, rather
> what the generated code in ui_mainwindow.h does), i.e. it sets the font
> prop for the MainWindow and then adds the children. If you run this program
> on Linux, the debug output is as expected:
>
> Before w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Courier"
> QTableWidget "Courier"
>
> After w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Courier"
> QTableWidget "Courier"
>
> Everything is nice and dandy. However, running the same program on Windows
> gives this output (the Before part is the same)
>
> ...
> After w.show();
> QTextEdit "Courier"
> QLabel "Courier"
> QPushButton "Courier"
> QCalendarWidget "Courier"
> QListWidget "Tahoma"
> QTableWidget "Tahoma"
>
> Lost 2 font propagations there. And on the Mac it's even worse (the Before
> part is the same here, but):
>
> ...
> After w.show();
> QTextEdit "Courier"
> QLabel ".AppleSystemUIFont"
> QPushButton ".AppleSystemUIFont"
> QCalendarWidget "Courier"
> QListWidget ".AppleSystemUIFont"
> QTableWidget ".AppleSystemUIFont"
>
> Lost another 2, i.e. only 33% hit rate.
>
> Now. the obvious solution is of course to always set the font properties
> explicitly for all widgets on my MainWindow. But it's so convenient to be
> able to change only the topmost font prop. Also the documentation for
> QWidget says "font propagation" should always occur. And sure, on Linux the
> docs are correct. But what about us running Windows or Macs?
>
> Well, the first thing I tried was to reshuffle the lines in my test app:
> ...
> // w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
> w.setFont(QFont("Courier"));
> ...
>
> Setting the font *after* adding the children does the trick, the hit rate
> is now 100% also on Windows and Mac. But, the problem is that this isn't
> the way the Form Editor (ui_mainwindow.h) works, it is hardwired to
> always set the properties for the MainWindow before adding any children.
>
>
> So as a workaround, I've resorted to adding one line of code in the
> MainWindow constructor in my Qt widget-flavored programs:
> ...
> {
> ui->setupUi(this);
>
> auto f = font(); setFont(QFont("Grapefruit")); setFont(f);
> ...
>
> Why the grapefruit? It's needed to "shake the tree", because when setting
> the same font as the code in ui_mainwindow.h does. it's ignored. You need
> to change to another font first, then the setFont(f) call will register
> properly (and propagate 100% to the kids). This can be illustrated if we
> change the test program to:
> ...
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
> new QCalendarWidget();
> new QListWidget();
> new QTableWidget();
> w.setFont(QFont("Courier"));
> ...
>
> That version behaves exactly like the first version above (with the
> misses), i.e. like the 2nd setFont() call does not exist. But adding the
> dummy font call:
> ...
> w.setFont(QFont("Courier"));
> new QTextEdit();
> new QLabel();
> new QPushButton();
>
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 4 okt. 2019 12:39Morten Sørvig skrev: > > > > On 3 Oct 2019, at 09:44, Mark De Wit wrote: > > > > Is there a chance that the high-dpi work will fix the dpi-awareness of > the Fusion theme as reported in > https://bugreports.qt.io/browse/QTBUG-74100 ? > > Yes, looks like an easy fix: > https://codereview.qt-project.org/c/qt/qtbase/+/276261 > > > > > Last time I checked there was a fair amount of drawing code that didn't > check what screen a widget was on, and hence used "global" scaling (if any). > > QPainter picks up the correct factor via the paint device, so the > draw-on-widget case should work without checking the screen. But there > might be other cases such as painting on a intermediate pixmap which needs > fixing. > I also think there might be some wonkiness in generation of pixmaps from SVG icons specified via theme lookup. I think it was due to the icon theme engine possibly not using the correct overload... Something like that.. Don't have the bug number (on my phone on a train atm) and it may already have been fixed. We have some manual workaround code for that issue in our app. Been meaning to look into what the status in recent Qt is (we unfortunately must work well with the 5.9 in Ubuntu 18.04 until 20.04 is out). Elvis > Morten > > > > > Mark > > > >> -Original Message- > >> From: Development On Behalf Of > >> Christoph Cullmann > >> Sent: 01 October 2019 22:19 > >> To: development@qt-project.org > >> Subject: Re: [Development] Updated high-DPI support for Qt 5.14 > >> > >> Hi, > >> > >> actually, unrelated to how one can configure the stuff, at the moment, > I see > >> still a lot of Qt internal rendering artifacts for fractional scaling. > >> > >> See https://bugreports.qt.io/browse/QTBUG-66036 > >> > >> For some I made now hacky workarounds in KTextEditor, see > >> https://bugs.kde.org/show_bug.cgi?id=390451 > >> > >> Some still remain for factors like 1.1 and text selections... > >> > >> And one should think about if it is really a good idea to accept > factors like 1.1 > >> and not round them to some at least 1 / 2^x factor that doesn't lead to > >> interesting accumulating rounding errors. (in addition to the opt-out of > >> fractional scaling at all) > >> > >> Greetings > >> Christoph > >> > >> -- > >> Ignorance is bliss... > >> https://cullmann.io | https://kate-editor.org > >> ___ > >> Development mailing list > >> Development@qt-project.org > >> https://lists.qt-project.org/listinfo/development > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den tors 26 sep. 2019 kl 04:51 skrev Thiago Macieira : > > On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote: > > Large parts of the world did not grow up with inches. I know I'd have > > a hard time to hold up my fingers to show an inch... > > For most people, "DPI" is an arbitrary number ranging from 72 to 288... Yep, although I'd revise that to "for most people, DPI means nothing, but for some people it's an arbitrary number ranging from 72 to 288..." :) I just wanted to argue that working in terms of a percentage of the current size is more intuitive to most people, compared to working in some arbitrary DPI number they may or may not have heard about. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den ons 25 sep. 2019 kl 20:51 skrev Kai Pastor, DG0YT : > > Am 25.09.19 um 20:08 schrieb Elvis Stansvik: > > Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke > > : > >> On 25/09/2019 08.54, Morten Sørvig wrote: > >>> I see two differences between setting the DPI vs a factor: > >>> > >>> - You set one value per screen (DPI) instead of two (DPI & factor) > >>> > >>> - Qt can compute the factor, according to policy set by the > >>> application (as mentioned above) > >>> > >>> [...] > >>> > >>> If possible, I’d like us to move away from relying on setting > >>> environment variables, and/or switch to specifying per-screen DPI > >>> instead of a scale factor. > >> Has anyone considered whether or not this is *user* friendly? > >> > >> As a user, I don't want to have to know/measure/compute the DPI of my > >> display device. I just want to make "stuff" bigger or smaller. I *also* > >> don't necessarily want the same physical size of "stuff" across devices. > >> On my phone, I may want smaller "stuff", because my phone is usually > >> quite close to my eyes. On my 4K 75" television, I may want larger > >> "stuff" because I'm sitting 10' to 15' away. Maybe I have really good > >> (or really bad) eyesight. > >> > >> Fiddling with "fake DPI" as a way of adjusting things has always felt > >> like a hack. Setting display scaling "just makes sense". From a user > >> perspective, it's obvious that scaling is also going to affect icons, > >> style margins, frame thicknesses... basically, *everything*. DPI, > >> historically, only affected font sizes and *maybe* some margins. If the > >> only knob I have is DPI, how do I know (or control) what size my icons > >> will be? How am I supposed to guess what will be the relation between > >> "virtual" pixels and physical pixels, keeping in mind that I, as a user, > >> am trying to achieve a particular value for that? > >> > >> There are a few instances, such as when representing physical objects, > >> when it makes sense to try to achieve a particular physical size. In > >> almost *every other case*, which is to say *always* for interface > >> elements, there is no fixed correlation between "desirable" size and > >> actual physical size, and anyone that designs their application > >> otherwise is doing their users a disservice. > > Agree 100%. There's no reason for a user to have to fiddle around with > > a strange number like 192, 96, or whatever. > > > > As a user I want 2 things: > > > > - Sane defaults and good autodetection, so a hopefully good automatic > > scale factor that makes things reasonably sized given the physical > > dimensions of the output device and its intended viewing distance > > - ..but if I want to tune the size for whatever reason, I want to do > > that in percentages of what it is *now*. > > > > It's easy enough for most folks to judge what % of the current size > > that would get them where they want to be. It's not friendly to > > present them with say 192 DPI, and when they want say 80% of that, > > leave them to do the math. Or even asking them to relate the DPI to > > physical inches (though I guess the DPI we're talking about here is > > some intermediate virtual one?). > > > > Large parts of the world did not grow up with inches. I know I'd have > > a hard time to hold up my fingers to show an inch... > > > > Elvis > > > > PS. Nevermind that in the KDE version I'm using, it's actually not > > possible to tweak the scale factor per screen under X11 in the kscreen > > KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to > > dabble with that. But if I do want to dabble, I want to dabble in > > percent. DS. > > There is nothing wrong with preferring simplicity for the most common > case. But please provide a clear way how to get accurate sizes when > desired, e.g. for 1:1 drawing or for print preview. With "clear" > including uniform cross-platform. Yes, absolutely, I want that use case to just work too of course. I was speaking only of the "i want to change the size of buttons and text on my computer" use case, not about print preview / desktop publishing types of use cases (those are important too of course, and should just work, irregardless of the user's desktop screen scaling settings). Elvis > > Kai > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den ons 25 sep. 2019 kl 18:34 skrev Matthew Woehlke : > > On 25/09/2019 08.54, Morten Sørvig wrote: > > I see two differences between setting the DPI vs a factor: > > > > - You set one value per screen (DPI) instead of two (DPI & factor) > > > > - Qt can compute the factor, according to policy set by the application (as > > mentioned above) > > > > [...] > > > > If possible, I’d like us to move away from relying on setting > > environment variables, and/or switch to specifying per-screen DPI > > instead of a scale factor. > Has anyone considered whether or not this is *user* friendly? > > As a user, I don't want to have to know/measure/compute the DPI of my > display device. I just want to make "stuff" bigger or smaller. I *also* > don't necessarily want the same physical size of "stuff" across devices. > On my phone, I may want smaller "stuff", because my phone is usually > quite close to my eyes. On my 4K 75" television, I may want larger > "stuff" because I'm sitting 10' to 15' away. Maybe I have really good > (or really bad) eyesight. > > Fiddling with "fake DPI" as a way of adjusting things has always felt > like a hack. Setting display scaling "just makes sense". From a user > perspective, it's obvious that scaling is also going to affect icons, > style margins, frame thicknesses... basically, *everything*. DPI, > historically, only affected font sizes and *maybe* some margins. If the > only knob I have is DPI, how do I know (or control) what size my icons > will be? How am I supposed to guess what will be the relation between > "virtual" pixels and physical pixels, keeping in mind that I, as a user, > am trying to achieve a particular value for that? > > There are a few instances, such as when representing physical objects, > when it makes sense to try to achieve a particular physical size. In > almost *every other case*, which is to say *always* for interface > elements, there is no fixed correlation between "desirable" size and > actual physical size, and anyone that designs their application > otherwise is doing their users a disservice. Agree 100%. There's no reason for a user to have to fiddle around with a strange number like 192, 96, or whatever. As a user I want 2 things: - Sane defaults and good autodetection, so a hopefully good automatic scale factor that makes things reasonably sized given the physical dimensions of the output device and its intended viewing distance - ..but if I want to tune the size for whatever reason, I want to do that in percentages of what it is *now*. It's easy enough for most folks to judge what % of the current size that would get them where they want to be. It's not friendly to present them with say 192 DPI, and when they want say 80% of that, leave them to do the math. Or even asking them to relate the DPI to physical inches (though I guess the DPI we're talking about here is some intermediate virtual one?). Large parts of the world did not grow up with inches. I know I'd have a hard time to hold up my fingers to show an inch... Elvis PS. Nevermind that in the KDE version I'm using, it's actually not possible to tweak the scale factor per screen under X11 in the kscreen KCM, so I have to manually set QT_SCREEN_SCALE_FACTORS if I want to dabble with that. But if I do want to dabble, I want to dabble in percent. DS. > > -- > Matthew > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den mån 16 sep. 2019 kl 09:44 skrev Paul Tvete : > > On Friday, 13 September 2019 17:14:32 CEST Thiago Macieira wrote: > > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > QT_AUTO_SCREEN_SCALE_FACTOR was deprecated in 2016. The recommended > replacement is QT_ENABLE_HIGHDPI_SCALING. > > It looks like QT_SCREEN_SCALE_FACTORS was briefly broken, but I see there was > a fix by David Faure that was merged last week: > https://codereview.qt-project.org/c/qt/qtbase/+/273182 Phew. Thanks! Elvis > > - Paul > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 13 sep. 2019 kl 17:51 skrev Thiago Macieira : > > On Friday, 13 September 2019 08:35:59 PDT Elvis Stansvik wrote: > > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > > > > I wonder too. I assume they've not been removed? The latter is the one that > > KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command > > line for testing. What would be the new way to set per-screen scale factors? > > I'm going to make a different request: unless the meaning has changed, keep > the same names. We already went through a round of having people migrate their > variables from the old names to those I listed. Let's not do it again without > strong reason. +1 > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Updated high-DPI support for Qt 5.14
Den fre 13 sep. 2019 17:15Thiago Macieira skrev: > On Friday, 13 September 2019 06:43:30 PDT Morten Sørvig wrote: > > * Environment variables for development and testing: > > > > - QT_SCALE_FACTOR : enables devicePixelRatio scaling in > > QtGui, applies a global scale factor. - QT_ENABLE_HIGHDPI_SCALING [new] > : > > enables devicePixelRatio scaling in QtGui; applies per-screen scale > factors > > computed from on screen DPI. - QT_FONT_DPI [now x-platform] : > overrides > > the DPI for all screens > > What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS? > I wonder too. I assume they've not been removed? The latter is the one that KDEs kscreen KCM manipulates AFAIK, and I occasionally use it from command line for testing. What would be the new way to set per-screen scale factors? Elvis > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
Den ons 21 aug. 2019 kl 21:36 skrev Henry Skoglund : > > Yes, I also used app-local deployment, problem is that Microsoft has not > committed 100% to allow it (as far as I know), instead they have a > seesaw approach, saying "you can temporarily use app-local deployment but.." > > Anyway, my ultimate goal is to create and distribute my Qt apps the same > way as Qt's installation program (you can tell I really admire that > program a lot :-) > i.e. link *everything* statically and build myself a ~ 20 MB humongous > .exe file (which only needs msvcrt.dll). And that kind of linking, > Microsoft has never supported nor allowed it. Alright, yes, your argument (and Kyle's) make sense I guess. I was mostly speaking from a practicality perspective (that deployment is really not that awkward with the right tools). I know that Microsoft once said it would no longer support app-local deployment of the Universal CRT, but then changed their mind back in 2015 (see the bullet point 6 in the list at https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/). I don't know if they've changed their mind again, which I think would be required to really call it a seesaw approach :) But yea, I too prefer the simplicity of an MIT licensed compiler to Microsofts agreement. Elvis > > > On 2019-08-21 21:22, Elvis Stansvik wrote: > > Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund : > >> Please, don't drop MinGW, it's in my meaning the best compiler on Windows. > >> > >> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe > >> file which is runnable directly on the user's desktop (no installation). > >> This is *verboten* when using VS, you have to send along the > >> distribution dlls (ucrtbase.dll etc.) and install them. > > Why not just ship those DLLs? I wouldn't call that "verboten" > > (forbidden), just a bit more to do for deployment. > > > > We do app-local deployment (putting the DLLs next to our application), > > which is still supported, and makes it possible for us to deliver a > > portable ZIP in addition to an installer. You don't have to go the > > route of launching the redistributables installer. > > > > To make it less inconvenient we use CMake's > > InstallRequiredSystemLibraries module along with setting > > CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are > > also bundled. > > > > Elvis > > > >> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have > >> also switched from using Visual Studio to MinGW. I believe for the same > >> reason as mine above, except MaintenanceTool.exe didn't include any VS > >> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to > >> start, because no VS2015 runtime was installed. > >> > >> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be > >> present, and tbat .dll always gonna be there (just like the VB6 runtime > >> etc.) > >> > >> This is one of the few places where Windows still shines: Qt's OOBE on > >> Windows. On that platform, you don't need any chmod +x or waiting for a > >> .dmg to unpack, just double-click on the .exe file. > >> > >> Rgrds Henry > >> > >> > >> > >> On 2019-08-21 20:35, Mathias Hasselmann wrote: > >>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira: > >>>> PPS: can we drop MinGW support in Qt 6? > >>> What alternative do you propse? > >>> ___ > >>> Development mailing list > >>> Development@qt-project.org > >>> https://lists.qt-project.org/listinfo/development > >> ___ > >> Development mailing list > >> Development@qt-project.org > >> https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)
Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund : > > Please, don't drop MinGW, it's in my meaning the best compiler on Windows. > > I've switched from VS to MinGW, the #1 reason: I can distribute an .exe > file which is runnable directly on the user's desktop (no installation). > This is *verboten* when using VS, you have to send along the > distribution dlls (ucrtbase.dll etc.) and install them. Why not just ship those DLLs? I wouldn't call that "verboten" (forbidden), just a bit more to do for deployment. We do app-local deployment (putting the DLLs next to our application), which is still supported, and makes it possible for us to deliver a portable ZIP in addition to an installer. You don't have to go the route of launching the redistributables installer. To make it less inconvenient we use CMake's InstallRequiredSystemLibraries module along with setting CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are also bundled. Elvis > > Also, big wheels like Qt's installer program (MaintenanceTool.exe) have > also switched from using Visual Studio to MinGW. I believe for the same > reason as mine above, except MaintenanceTool.exe didn't include any VS > .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to > start, because no VS2015 runtime was installed. > > Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be > present, and tbat .dll always gonna be there (just like the VB6 runtime > etc.) > > This is one of the few places where Windows still shines: Qt's OOBE on > Windows. On that platform, you don't need any chmod +x or waiting for a > .dmg to unpack, just double-click on the .exe file. > > Rgrds Henry > > > > On 2019-08-21 20:35, Mathias Hasselmann wrote: > > Am 21.08.2019 um 19:38 schrieb Thiago Macieira: > >> PPS: can we drop MinGW support in Qt 6? > > What alternative do you propse? > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: QStringLiteral
Den ons 21 aug. 2019 kl 12:22 skrev Lars Knoll :
>
>
> > On 21 Aug 2019, at 13:01, Tor Arne Vestbø wrote:
> >
> >
> >
> >> On 21 Aug 2019, at 11:50, Bogdan Vatra via Development
> >> wrote:
> >>
> >> Am I the only one which finds situations silly ? Of course there are more
> >> examples with the other String wrappers/functions in Qt, but I think is
> >> enough
> >> to show how crazy is the situation.
> >
> > You are not!
> >
> > I completely agree, and I think it’s a detriment to Qt’s promise of easy to
> > use APIs that these optimised versions are not automagic and hidden behind
> > the scenes, or don’t have a clear cut story for when to explicitly use.
>
> +1. Things are getting overly complex. And in the end most people will write
> less optimal code simply because they do now know which class is the best to
> use in which use case. If people on this list are confused, you can be
> certain that 98% of our users will not get the subtle differences.
I'm in that category of users. I've never even bothered to learn what
the non-QString stuff (QLatin1Literal, QStringLiteral, ...) about,
despite it having been around for quite a while and me knowing about
their existance, and just use QString or "" everywhere. This is
non-optimal but I do it because, because a) it's less to type and
read, b) string operations has never been a bottleneck in the
applications I've worked on and c) it's one less set of rules I (and
my coworkers) have to remember. The situations is probably different
for library developers (e.g. Qt developers), which have to strive for
optimality (within reason).
Elvis
> >
> >> // Even more
> >> QHash test;
> >> test[QLatin1String("key1")] = QLatin1String("some text %1").arg(1); //
> >> wrong
> >> test[QStringLiteral("key1")] = QStringLiteral("some text %1").arg(1); //
> >> wrong
> >> again
> >> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> >> still
> >> wrong
> >> test[QLatin1String("key1")] = QStringLiteral("some text %1").arg(1); //
> >> victory !!!
> >
> > This should just be test[“key”] = “value”. How do we get there?
>
> One way would be by enforcing utf8 as source encoding for Qt based projects.
> It’s a huge shame that C++ doesn’t specify the encoding of source code as
> opposed to pretty much any other programming language (hell even JS got that
> one right…).
>
> So I think it might be worthwhile enforcing that for Qt 6. But it leaves the
> question of what to do with QL1String.
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Den tors 11 juli 2019 kl 05:54 skrev Jason McDonald : > > On Tue, Jul 9, 2019 at 1:39 AM Shawn Rutledge wrote: > > > On 8 Jul 2019, at 16:24, Volker Hilsheimer > > > wrote: > > > > > > Hi, > > > > > > Executive summary: > > > > > > * QTest::mouseMove seems to be broken > > > * when simulating QEvent::MouseMove events by constructing event objects, > > > always construct them with global position > > That's good advice for now. I think it would be worth filing a bug to > see if this part of testlib can be fixed/improved in the future. At I think https://bugreports.qt.io/browse/QTBUG-5232 could be re-used/re-opened for this. It was closed with resolution "Won't Do", but with a comment ""Won't Do" => actually we will do this. In Qt 6 we will drop some legacy code paths and this stuff will start working fine." comment from Gatis. Elvis > the very least, it will make it clear that we're aware of the issue. > > I also recall that there used to be a wiki page that listed some > best-practices for writing unit tests. If that list still exists > somewhere, this advice should be added there. > > >>That there is no overload that takes modifiers and keys is also strange. > > Most likely this omission is simply because nobody ever asked for such > an overload. I'm fairly sure that that part of testlib existed before > modifiers and keys were part of the Qt API and testlib never caught up > when those were added elsewhere. > > > Yep. Cursor support can be disabled, I think that’s one reason at least. > > Another is that some platforms (i.e. Wayland) don’t allow applications to > > set cursor position. Anyway it’s heavy-handed and slow. But tests that > > need to simulate mouse hover or mouse enter/exit by sending events do need > > to ensure that the cursor is _not_ on top of the window, to avoid getting > > spurious events… and that’s usually done by QCursor::setPos(); so we can’t > > seem to get rid of it after all. > > > > https://codereview.qt-project.org/c/qt/qtbase/+/5290 seems to have put it > > into its current state… it’s old. > > I think it got that way a bit earlier than that patch. The patch > appears to just move code around without modifying any functionality. > > > But before that was https://codereview.qt-project.org/c/qt/qtbase/+/4462 > > which comments out QCursor::setPos() and sends a platform event instead… at > > least in one case. Too bad the commit message is so sparse. > > Unfortunately, our approval process wasn't followed very well for > either of those patches. Both patches were pushed through very > quickly outside the working hours of the testlib maintainer (me, in > GMT+10 timezone, where the patches were each pushed through in my > evening). If I had had an opportunity to review them I would > certainly have objected to the uninformative commit message. (Those > who were around in the Trolltech and Nokia days may remember my vocal > campaigns for meaningful commit messages, motivated by the fact that > for some years I was the poor sucker who had to read thousands of > commit messages every few months and turn them into release notes.) > > > I suppose there’s the usual tradeoff between the philosophy that real > > platform testing should involve real platform events (in this case: if you > > really move the system mouse cursor, then the window system will hopefully > > send a mouse move event to the window, and aren’t you making the test more > > realistic that way?) vs. the practical tendency for that kind of testing to > > be less reliable, with unpredictable latency, needing to use QTRY_ much > > more because you don’t know how long to wait until the window system > > reacts, etc. > > I have always been a little uncomfortable with the part of testlib > that handles mouse and keyboard events because it feels like some of > it crosses the line from unit testing into integration and system > testing, and thus really belongs in a separate system-level test > framework rather than in testlib. The system-level tests that > masqueraded as unit tests were always more likely to be flaky than > 'pure' unit tests. > > In the period before Qt 5, I had been hopeful that there would be an > opportunity to tidy this up and cleanly separate the true unit tests > from the others. At that time there was a team working on a separate > system-level testing framework for Qt, but that team was in Brisbane > and evaporated when the decision was made to eject Qt from Nokia and > the new system-test framework was never completed. > > Cheers, > -- > Jason > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QTestlib: how not to test mouseMoveEvent handling
Den mån 8 juli 2019 kl 16:26 skrev Volker Hilsheimer : > > Hi, > > Executive summary: > > * QTest::mouseMove seems to be broken > * when simulating QEvent::MouseMove events by constructing event objects, > always construct them with global position > > > The details: > > While trying to fix https://bugreports.qt.io/browse/QTBUG-76765 to not update > the mouse cursor when the cursor-fied QGraphicsItem the mouse is on top of is > disabled, I noticed the following pattern in the respective test: > > QTest::mouseMove(localPoint, widget); > QMouseEvent event(QEvent::MouseMove, localPoint, Qt::NoButton, 0, 0); > QApplication::sendEvent(widget, ); > > > which confused me a bit. Shouldn’t QTest::mouseMove already have sent the > event? Apparently not. That there is no overload that takes modifiers and > keys is also strange. > > In the end, when running the test locally on my Mac, I never got it ot pass. > > What seems to happen is this: > > * for QWidget receivers, QTest::mouseMove just calls QCursor::setPos > > QCursor::setPos is not guaranteed to generate mouse events. The documentation > of some overloads of that function [1] in fact explicitly advises against > using that function in unit tests. > > > * QMouseEvent uses QCursor::pos if no global position has been explicitly > provided > > A lot of tests don’t explicitly calculate and provide the global mouse > position, but some widgets use the global position (QGraphicsView, for > instance). > > Since QCursor::setPos doesn’t do much of anything on my mac when I’m logged > in (the visible mouse pointer on the screen didn’t move when running tests), > the mouse events received are not the ones the test expects to be received, > and the tests fail. > > I tried to fix this case now by always constructing QMouseEvent objects with > both local and global positions. That is easy, but a bit tedious, and that we > don’t use QTest::mouseMove suggests that this function has not been working > as one would expect for a while. We've run into this in our app's unit tests as well, and found this old bug about it: https://bugreports.qt.io/browse/QTBUG-5232 (That one was sort of inverted to what you're describing though, it would work on Mac, but not X11/Windows, but yea, it's old..) We also construct the events manually and send them. Elvis > > Perhaps someone can enlighten me why QTest::mouseMove doesn’t simulate a > QEvent like QTest::mousePress does? An overload that takes modifiers and > keys, and simply simulates the event, would be a good addition, perhaps? > > > Volker > > > [1] https://doc.qt.io/qt-5/qcursor.html#setPos-1 > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud : > > On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, wrote: >> >> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote: >> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote: >> > > You can download a CMake static binary (https://cmake.org/download/) that >> > >> > (...) >> > >> > I would prefer that our requirements be present in Linux distributions we >> > declare are supported build environments. If nothing else, our CI will >> > benefit from this. >> >> Let's not pull CI into it. It already > > > Wow! Let's not pull in the system which only goal is to validate the > "supported platforms" promise, is it what you mean? > If I need a special cmake to build Qt, then this should be shipped as part of > Qt itself, another third-party source tree. > And then it means that I will need to build qt's build system. In other > words, I'll have to bootstrap Qt build system. > I thought that it was a big no-no. The main argument to ditch qmake and qbs... Hm, what is the problem with using the official CMake binaries? Isn't that what you'd do on Windows / macOS anyway? If distro X (e.g. *buntu 20.04) happen to ship a sufficient version when it arrives, then great. But having to install the build tool from the vendor instead of the distro package manager surely can't be a blocker? Elvis > > Chris > > >> covers installation of the cmake in >> order to test wip/cmake branch (https://code.qt.io/cgit/qt/qt5.git/tree/coin/ >> provisioning/common/linux/cmake_linux.sh?h=wip/cmake) >> >> Cheers, >> Jędrek >> >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik : > > Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development > : > > > > On 2019-06-06 12:24, Lars Knoll wrote: > > >> On 6 Jun 2019, at 11:08, Simon Hausmann > > >> wrote: > > >> > > >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development: > > [...] > > >>> I have the feeling that some participants of these discussions > > >>> thought > > >>> they joined an adulation club for Qt API lovers instead. > > >> > > >> I don't quite understand what you're trying to say with adulation > > >> club > > >> for Qt API lovers. Could you explain this, please? Am I supposed to > > >> feel > > >> insulted or offended? > > > > > > Not sure what to say to this neither. > > > > > > Let’s remember that a large part of Qt’s success has been due to > > > its API. Making programming easy and fun has been at the core of what > > > we’re doing and it has to stay that way, or we’re really loosing > > > the core of what made and makes Qt successful. > > > > > > Many of our users strongly feel (and IMO rightfully so) that STL is a > > > difficult API that’s maybe very powerful for the things it does, but > > > at the same time hard to use and where it’s very easy to get things > > > wrong. Qt solved a lot of that pain. > > > > > > Yes, our classes might not be quite as performant in all cases, but > > > they do get the job done. And they do help our users to write code > > > they feel comfortable maintaining, something that is in most cases > > > much more important to them than another few percent of performance. > > > > You are equating Qt users and Qt implementers. You can maintain the Qt > > API, but use more efficient data structures in the implementation. You > > seem to be implying that these two things cannot be separated. > > > > None of the changes where I replaced QMap changes the public API at all > > (except adding an overload because we can). No user is affected by this > > in any way, except that they have a few pages of memory more free than > > before. > > > > Please explain to me how any of those changes makes _users_ of Qt have > > to revert to the STL? > > > > And please explain to me how it can possibly be worthwhile to generate > > 8KiB of code _just_ to not have to use lower_bound? Which argument could > > *possibly* be made against a lower_bound? Esp. seeing as many attempts > > to write one by hand have failed. I remember a bug about shortcuts being > > mapped to the wrong key, because the hand-rolled binary search was > > unstable. > > > > I'm sorry, but we have a lot of code that is less readable than any of > > the changes I uploaded. It just cannot be an argument to say that it's > > unreadable because it uses an STL algorithm. This sentiment has caused > > so very, very many quadratic loops because people get the impression > > that std::remove_if is toxic, and in each one the solution was to use > > remove_if, because the hand-rolled alternative would be totally > > unreadable. > > > > I'm sad to see that Qt devs think so lowly of themselves as to be unable > > to understand a piece of code that uses an STL algorithm. Really. I'm > > out of words. > > Since you've repeated this a few times now: I don't think anyone has > suggested that they cannot understand the STL code. What they have > said is that the find it _less_ readable/maintainable, not > _un_readable. Someone jump in and correct me if I understood them > wrong, in which case I join Marc in the shocked camp :) Also, Qt developers will of course have to work out what policies you want to have for the implementation of Qt, but my take as a user is that I don't have the expectation that Qt is always optimal, just because it is a library. I trust that Qt developers always make case-by-case judgement between 1) API for the user, 2) Size/speed of the code, 3) Maintainability of the code. The case-by-case because there are some parts which quite obviously won't be called often, or classes which won't have many instances. For example in the QDrag patch, where you made an ad-hoc inline implementation of a mapping on top of a vector (roughly doubling the LoC), instead of using a datatype that expresses what it is (QMap), in order to save 4KiB and some allocations, I guess it's to be expected that some people disagree with the priorities and give you a -1. I would say I'm on the fence on that particular one. But perhaps the best course of action is,
Re: [Development] Views
Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development : > > On 2019-06-06 12:24, Lars Knoll wrote: > >> On 6 Jun 2019, at 11:08, Simon Hausmann > >> wrote: > >> > >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development: > [...] > >>> I have the feeling that some participants of these discussions > >>> thought > >>> they joined an adulation club for Qt API lovers instead. > >> > >> I don't quite understand what you're trying to say with adulation > >> club > >> for Qt API lovers. Could you explain this, please? Am I supposed to > >> feel > >> insulted or offended? > > > > Not sure what to say to this neither. > > > > Let’s remember that a large part of Qt’s success has been due to > > its API. Making programming easy and fun has been at the core of what > > we’re doing and it has to stay that way, or we’re really loosing > > the core of what made and makes Qt successful. > > > > Many of our users strongly feel (and IMO rightfully so) that STL is a > > difficult API that’s maybe very powerful for the things it does, but > > at the same time hard to use and where it’s very easy to get things > > wrong. Qt solved a lot of that pain. > > > > Yes, our classes might not be quite as performant in all cases, but > > they do get the job done. And they do help our users to write code > > they feel comfortable maintaining, something that is in most cases > > much more important to them than another few percent of performance. > > You are equating Qt users and Qt implementers. You can maintain the Qt > API, but use more efficient data structures in the implementation. You > seem to be implying that these two things cannot be separated. > > None of the changes where I replaced QMap changes the public API at all > (except adding an overload because we can). No user is affected by this > in any way, except that they have a few pages of memory more free than > before. > > Please explain to me how any of those changes makes _users_ of Qt have > to revert to the STL? > > And please explain to me how it can possibly be worthwhile to generate > 8KiB of code _just_ to not have to use lower_bound? Which argument could > *possibly* be made against a lower_bound? Esp. seeing as many attempts > to write one by hand have failed. I remember a bug about shortcuts being > mapped to the wrong key, because the hand-rolled binary search was > unstable. > > I'm sorry, but we have a lot of code that is less readable than any of > the changes I uploaded. It just cannot be an argument to say that it's > unreadable because it uses an STL algorithm. This sentiment has caused > so very, very many quadratic loops because people get the impression > that std::remove_if is toxic, and in each one the solution was to use > remove_if, because the hand-rolled alternative would be totally > unreadable. > > I'm sad to see that Qt devs think so lowly of themselves as to be unable > to understand a piece of code that uses an STL algorithm. Really. I'm > out of words. Since you've repeated this a few times now: I don't think anyone has suggested that they cannot understand the STL code. What they have said is that the find it _less_ readable/maintainable, not _un_readable. Someone jump in and correct me if I understood them wrong, in which case I join Marc in the shocked camp :) Elvis > > Thanks, > Marc > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development : > > On 2019-06-03 14:27, Bernhard Lindner wrote: > >> > > > So, yes, this is borne out of frustration with the lack of > >> > > > maintenance > >> > > > of QtCore plumbing. I don't see that changing and I acknowledge and > >> > > > understand that the focus of development has shifted towards QML. > >> > > Suppose you implement all planned actions for Qt6 (see your original > >> > > e-mail). Are > >> > > the > >> > > remaining components (those that are neither deprecated nor removed) > >> > > of Qt6 well > >> > > maintained and are there enough staff available not only to maintain > >> > > them > >> > > indefinitely > >> > > but to actively develop them further? > >> > > >> > No answer to my question above? > >> > >> Who do you expect an answer to this question from? > >> > >> The Qt Company? The Qt community? Marc? Thiago? > > > > Whoever believes being able to make a realistic assessment. > > > > If there is no such person/group in this list, which can do an > > estimate how much of Qt is > > affordable, an important aspect of the Qt 6 discussion can not > > actually be discussed. How > > can Marc think about removing (or significantly changing) Qt due to > > ressource limits or > > new strategic goals if the limits or goals are unknown? > > > > Actions out of frustration are never a good idea. And pushing into a > > (technical) direction > > that does not solve the underlying (strategical) problem is futile. > > I think it's pretty clear that some parts of Qt thrive (e.g. QString) > and others, incl. the other containers, lag behind. I can't speak for > TQC, but I do wonder where all the manpower that is now proposed to make > Qt containers wrappers around std ones, etc, suddenly should come from > when it was lacking for the last decade. > > An example: The Qt docs made fun of how hard it is to iterate backwards > using STL containers, as opposed to Java-Style ones > (https://doc.qt.io/archives/qt-4.8/containers.html#java-style-iterators), > yet, in roughly the same time it took to write that nonsense, a > developer could have implemented rbegin()/rend() on Qt containers. > Likewise, since I added rvalue-push_back to QVector a few years ago, > no-one stepped up to implement this for everyone's favourite container, > QList. Nor any other Qt container. Not _one_. This, and many other such > instances, show me that the Qt containers are considered good enough, > and there's absolutely no interest in bringing them forward into the > 21st century. If you believe otherwise, prove it. > > But containers are one of the cornerstones of programming, and there's a > reason that we now have emplacement, node_handle, move-only payload type > support, splicing, etc. etc. Where are those functions on Qt containers? > For that matter, why is there no Qt version of std::set? I removed at > lest three implementation of an OrderedSet that used a QMap to > imitate a std::set from QtCore alone. Where is that container, please? > Where is QDeque? Where is QForwardList? Where is the 25-year-old > optimisation that implements Container in terms of Container. > IIRC, even the original STL had that. Where is the const_iterator > overload of QVector::erase()? In particular with CoW, only detaching if > you actually found the object should be something that everyone yearns > for. People complain that std::mutex is slower than QMutex, but they > don't complain that erase(const_iterator) is missing. > > You don't need a crystal ball to see that there's not even enough > manpower to bring in the "recent" (well, C++98 is 20 years ago) changes > from the STL, let alone innovate. > > If users use a QMap because they have an aversion against > std::set, for one reason or another, where _is_ the Qt answer? Since > 4.0, the answer has been "you're on your own". So, the honest answer > would be that Qt doesn't care about it's container classes any more, and > recommends every user to move over to the STL versions where-ever they > can. > > But some people still live in a bubble universe where, contrary to > historic proof, the Qt containers will be made great again, any-time > soon now. Just wait for it... I think you said it near the beginning of your mail: > [...] This, and many other such instances, show me that the Qt containers are > considered good enough [...] I guess that is the case. At least I haven't craved for any of the features you list in the 15 or so year's I've developed with Qt. The plumbing has been good enough both for my personal and professional projects, and I guess that may be the case for many others as well. Don't get me wrong, I absolutely think there are cases where the lack of these container features is a sore point, just wanted to say that I haven't spent a lot of time thinking about it, and the same may be true for many others as well. Elvis > > Thanks, > Marc > ___ > Development mailing
Re: [Development] Configure command lines of official Qt releases
Den mån 3 juni 2019 kl 20:29 skrev Richard Weickelt : > > > > I think this was asked on the interest list back in January [1]. > > I did search on the Qt mailing lists, but even when I type exactly the > subject of the thread you referred to, google doesn't find it. I would > expect "Official builds configuration options site:lists.qt-project.org" to > bring this post up: > https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but > it seems like google hasn't even indexed it. Strange! Perhaps something for the Qt web server administrators to look at, I would also expect it to be indexed by now. Elvis > > The answer is here: > > > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > Great. Thanks. > > Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik : > > Hi Richard, > > I think this was asked on the interest list back in January [1]. > > The answer is here: > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > I seem to remember some recent Qt developer thread about making these > more accessible, but can't find it now. Found it, but I remembered somewhat wrong. I was thinking of this note by Volker in the recent "A monologue about platforms in the Qt world" thread [1]: "Why don’t we make the exact way of turning a clean Linux distro-install into a "Qt reference configuration" available to everyone else? The way build machines are provisioned in Coin is rather opaque, even with some of the respective provisioning scripts available in the qt5.git repo [1]. Having to document on a (notoriously outdated) wiki how to set up things to build Qt from source, when we have that knowledge literally codified somewhere for Coin, doesn’t seem effective." So that was more about making the provisioning process for a "reference" build machine more transparent. Elvis [1] https://lists.qt-project.org/pipermail/development/2019-May/035773.html > > HTH, > Elvis > > [1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html > > Den mån 3 juni 2019 kl 18:56 skrev Richard Weickelt : > > > > Hi, > > > > where can I find the configure command lines that have been used for Qt > > binary releases provided at https://download.qt.io/official_releases/qt/ ? > > > > Is there also more information available about the environment they have > > been built on? I am particularly interested in the Linux release. > > > > Thanks > > ___ > > Development mailing list > > Development@qt-project.org > > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
Hi Richard, I think this was asked on the interest list back in January [1]. The answer is here: https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config I seem to remember some recent Qt developer thread about making these more accessible, but can't find it now. HTH, Elvis [1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html Den mån 3 juni 2019 kl 18:56 skrev Richard Weickelt : > > Hi, > > where can I find the configure command lines that have been used for Qt > binary releases provided at https://download.qt.io/official_releases/qt/ ? > > Is there also more information available about the environment they have > been built on? I am particularly interested in the Linux release. > > Thanks > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
Den tis 21 maj 2019 kl 10:57 skrev Giuseppe D'Angelo via Development : > > Il 21/05/19 10:26, Elvis Stansvik ha scritto: > > They will not show up in the web search (I think). > > > > They are however available in the debian-debug archive, see > > https://wiki.debian.org/AutomaticDebugPackages > > [snip] > > Genuine question, are those just the debug builds of a release build, or > are those debug builds? There is a difference when compiling Qt itself > (amongst other things, release builds do not have Q_ASSERTs in them). I'm not 100% sure, I think they are just packages containing symbols, so the build is the same (a release build). I think Debian packagers hang on this list so they would know for sure. That would mean Q_ASSERT is a no-op then, even with those packages installed, so they are just good for getting better backtraces. Elvis > > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What's the status of a moved-from object?
Den tis 21 maj 2019 kl 09:55 skrev Konstantin Shegunov : > > On Tue, May 21, 2019 at 9:49 AM Mutz, Marc via Development > wrote: >> >> Oh, a nullptr deref is pretty clear in a backtrace. > > > Indeed, but my point is that it's relatively useless for the user (or for the > developer for that matter). As you pointed out the dev sees the nullptr > dereferencing instantly, the user just gets a crash. The assert is just > superfluous is what I'm saying. > >> >> Even in a release >> build, if you installed the debug symbol package that does with the >> distribution's version of Qt. > > > Humor me, will you? [1] They will not show up in the web search (I think). They are however available in the debian-debug archive, see https://wiki.debian.org/AutomaticDebugPackages "The automatic dbgsym packages are available from a separate archive. Please fetch these from http://deb.debian.org/debian-debug/ (backed by http://debug.mirrors.debian.org/debian-debug/). They are also available on http://snapshot.debian.org/. They are only available for stable, proposed-updates, backports, testing, unstable and experimental at this point in time, optionally also under the release's codename. " E.g. I if you run testing, think you would add: deb http://deb.debian.org/debian-debug/ testing-debug main to your sources.list. For Ubuntu, I think the archive is called http://ddebs.ubuntu.com. E.g. I have deb http://ddebs.ubuntu.com bionic main restricted universe multiverse deb http://ddebs.ubuntu.com bionic-updates main restricted universe multiverse here on Kubuntu 18.04, and I have e.g: [estan@newton ~]$ apt-cache policy libqt5widgets5-dbgsym libqt5widgets5-dbgsym: Installerad: 5.9.5+dfsg-0ubuntu2 Kandidat:5.9.5+dfsg-0ubuntu2 Versionstabell: *** 5.9.5+dfsg-0ubuntu2 500 500 http://ddebs.ubuntu.com bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 5.9.5+dfsg-0ubuntu1 500 500 http://ddebs.ubuntu.com bionic/main amd64 Packages [estan@newton ~]$ Cheers, Elvis > >> >> Please, you debug against a release build, and complain that you don't >> get debug checks? > > > To take your previous example. > > QPen pen1 = ~~~; > QPen pen2 = std::move(pen1); > > // ... Some code > > pen1.color(); // Ooops > >> You're missing out on 4000 other checks that way, too! > > > Yes, I already aknowledged that. And it's fine if I'm debugging into Qt. If > not, I get segfault. And as it happens I have enough builds, so even if that > happens and I can't switch kits and step into Qt, not every one user does > have that at their fingertips, however. > Having documentation that spells such behaviour clearly, would be > satisfactory to me, that's why I was inquiring on *how* the problem, which is > a real one, can be mitigated. > >> >> That said, I'm pretty sure that a static analyzer can find uses of >> objects in partially-formed state with local analysis. > > > QPen pen; > QColor color = pen.color(); > > If the analyzer can see the above as dangerous, i.e. touching an object with > an invalid state (i.e. d-ptr is null) as dangerous, I'm satisfied. > > [1]: > https://packages.debian.org/search?suite=testing=all=any=names=libqt5core > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den mån 8 apr. 2019 kl 15:40 skrev Elvis Stansvik :
>
> Den sön 7 apr. 2019 kl 20:21 skrev Elvis Stansvik :
> >
> > Den sön 7 apr. 2019 kl 18:45 skrev Olivier Goffart :
> > >
> > > On 06.04.19 10:40, Elvis Stansvik wrote:
> > > > Hi all,
> > > >
> > > > I'm looking for someone who knows the inner workings of QIcon and the
> > > > icon engines.
> > > >
> > > > In our application, we almost exclusively use SVG icons, and we use a
> > > > single SVG file for each icon (no @2x versions) that we try to design
> > > > to work reasonably well at all sizes, since we do not have the
> > > > resources to make custom variations for each target size.
> > > >
> > > > We put these SVG icons into an XDG icon theme, that we ship inside the
> > > > application resources (.qrc) in the expected XDG layout and with an
> > > > icon theme index file. We can then use
> > > > QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> > > > through the .ui file or in code).
> > > >
> > > > The problem we've run into is that when the application is launched in
> > > > a mixed-DPI setup, for example a retina Mac laptop with an external
> > > > lower-DPI monitor, the icons appear too large and get cropped. In
> > > > effect, it seems to always use the DPI of the primary screen (the
> > > > built-in retina screen) when calculating the size of the pixmaps it
> > > > generates for the icons.
> > >
> > >
> > > Not sure if this is your problem, but it seems that
> > > QSvgIconEngine::virtual_hook does not handle the
> > > QIconEngine::ScaledPixmapHook
> > > call, which is needed for the QIcon::pixmap(QWindow *window, ...) call.
> >
> > Thanks Olivier,
> >
> > I'm not familiar with the code, but it sounds like that could be it.
> >
> > I'll try to make a minimal test case tomorrow.
>
> I've now created a minimal test case:
>
> dirac:~ insight$ find testcase
> testcase
> testcase/testcase.cpp
> testcase/icons
> testcase/icons/mytheme
> testcase/icons/mytheme/index.theme
> testcase/icons/mytheme/scalable
> testcase/icons/mytheme/scalable/actions
> testcase/icons/mytheme/scalable/actions/test-icon.svg
> testcase/testcase.pro
> testcase/testcase.qrc
> dirac:~ insight$
>
> testcase.cpp:
>
> #include
> #include
> #include
>
> int main(int argc, char *argv[]) {
> QApplication app(argc, argv);
>
> app.setAttribute(Qt::AA_UseHighDpiPixmaps);
>
> QIcon::setThemeName("mytheme");
>
> // Create icon from file name -> Size of pixmap is correct on both screens
> QToolButton button1;
> button1.setIcon(QIcon("icons/mytheme/scalable/actions/test-icon.svg"));
> button1.show();
>
> // Create icon from theme -> Size of pixmap is correct only on primary
> screen
> QToolButton button2;
> button2.setIcon(QIcon::fromTheme("test-icon"));
> button2.show();
>
> return app.exec();
> }
>
> This is the result when running on the external lower-DPI monitor:
>
>
> Note how the right button icon (button2), which is created using
> QIcon::fromTheme has the wrong pixmap size for that monitor (it's appropriate
> for the internal retina screen).
>
> And it really does seem like the Qt::AA_UseHighDpiPixmaps application
> attribute has a finger in the game here, because if I remove setting of that
> attribute, the problem goes away.
>
> Attaching the full test case as a ZIP.
>
> Should I report this as a bug?
I couldn't find an issue quite like this in JIRA, so I went ahead and filed:
https://bugreports.qt.io/browse/QTBUG-75039
Please continue any discussion there.
Elvis
>
> Elvis
>
> >
> > Elvis
> >
> > >
> > >
> > >
> > >
> > > >
> > > > To work around this, we've had to put in special code in all of our
> > > > widgets that use icons. The code reacts to screen change events (or
> > > > changes to the underlying QWindow in some cases), and in that code, go
> > > > through each and every one of our icons and do this monkey dance:
> > > >
> > > > auto pixmap =
> > > > someButton->icon().pixmap(someButton->iconSize());
> > > >
> > > > pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
> > > > someButton->setIcon(QIcon(pixmap))
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den mån 8 apr. 2019 kl 15:40 skrev Elvis Stansvik :
>
> Den sön 7 apr. 2019 kl 20:21 skrev Elvis Stansvik :
> >
> > Den sön 7 apr. 2019 kl 18:45 skrev Olivier Goffart :
> > >
> > > On 06.04.19 10:40, Elvis Stansvik wrote:
> > > > Hi all,
> > > >
> > > > I'm looking for someone who knows the inner workings of QIcon and the
> > > > icon engines.
> > > >
> > > > In our application, we almost exclusively use SVG icons, and we use a
> > > > single SVG file for each icon (no @2x versions) that we try to design
> > > > to work reasonably well at all sizes, since we do not have the
> > > > resources to make custom variations for each target size.
> > > >
> > > > We put these SVG icons into an XDG icon theme, that we ship inside the
> > > > application resources (.qrc) in the expected XDG layout and with an
> > > > icon theme index file. We can then use
> > > > QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> > > > through the .ui file or in code).
> > > >
> > > > The problem we've run into is that when the application is launched in
> > > > a mixed-DPI setup, for example a retina Mac laptop with an external
> > > > lower-DPI monitor, the icons appear too large and get cropped. In
> > > > effect, it seems to always use the DPI of the primary screen (the
> > > > built-in retina screen) when calculating the size of the pixmaps it
> > > > generates for the icons.
> > >
> > >
> > > Not sure if this is your problem, but it seems that
> > > QSvgIconEngine::virtual_hook does not handle the
> > > QIconEngine::ScaledPixmapHook
> > > call, which is needed for the QIcon::pixmap(QWindow *window, ...) call.
> >
> > Thanks Olivier,
> >
> > I'm not familiar with the code, but it sounds like that could be it.
> >
> > I'll try to make a minimal test case tomorrow.
>
> I've now created a minimal test case:
>
> dirac:~ insight$ find testcase
> testcase
> testcase/testcase.cpp
> testcase/icons
> testcase/icons/mytheme
> testcase/icons/mytheme/index.theme
> testcase/icons/mytheme/scalable
> testcase/icons/mytheme/scalable/actions
> testcase/icons/mytheme/scalable/actions/test-icon.svg
> testcase/testcase.pro
> testcase/testcase.qrc
> dirac:~ insight$
>
> testcase.cpp:
>
> #include
> #include
> #include
>
> int main(int argc, char *argv[]) {
> QApplication app(argc, argv);
>
> app.setAttribute(Qt::AA_UseHighDpiPixmaps);
>
> QIcon::setThemeName("mytheme");
>
> // Create icon from file name -> Size of pixmap is correct on both screens
> QToolButton button1;
> button1.setIcon(QIcon("icons/mytheme/scalable/actions/test-icon.svg"));
> button1.show();
>
> // Create icon from theme -> Size of pixmap is correct only on primary
> screen
> QToolButton button2;
> button2.setIcon(QIcon::fromTheme("test-icon"));
> button2.show();
>
> return app.exec();
> }
>
> This is the result when running on the external lower-DPI monitor:
>
>
> Note how the right button icon (button2), which is created using
> QIcon::fromTheme has the wrong pixmap size for that monitor (it's appropriate
> for the internal retina screen).
>
> And it really does seem like the Qt::AA_UseHighDpiPixmaps application
> attribute has a finger in the game here, because if I remove setting of that
> attribute, the problem goes away.
>
> Attaching the full test case as a ZIP.
>
> Should I report this as a bug?
As I was browsing through bugs containing the word "UseHighDpiPixmaps"
I came across this comment on a closed one (which was similar, but not
the same):
https://bugreports.qt.io/browse/QTBUG-50251?focusedCommentId=304908=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-304908
Quoting the comment:
"I have patched this in late '14 but it did not got integrated.
Problem is icons are loaded by a style. Styles do not have access to a
QWindow*. To load the dpi-correct icon a QWindow* is needed right now,
and in current case it just defaults to app default - biggest scale
factor.
My patch added an API to QIcon which used QPainter* instead of
QWindow* to query and load the right icon. With this addition fixing
the mac style is trivial.
Probably even more generic API can be added to QIcon, where
devicePixelRatio is directly passed as an qreal. This will also make
the problem fixable."
This seems possibly related to my issue.
Elvis
>
>
> Elvis
&
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den sön 7 apr. 2019 kl 20:21 skrev Elvis Stansvik :
>
> Den sön 7 apr. 2019 kl 18:45 skrev Olivier Goffart :
> >
> > On 06.04.19 10:40, Elvis Stansvik wrote:
> > > Hi all,
> > >
> > > I'm looking for someone who knows the inner workings of QIcon and the
> > > icon engines.
> > >
> > > In our application, we almost exclusively use SVG icons, and we use a
> > > single SVG file for each icon (no @2x versions) that we try to design
> > > to work reasonably well at all sizes, since we do not have the
> > > resources to make custom variations for each target size.
> > >
> > > We put these SVG icons into an XDG icon theme, that we ship inside the
> > > application resources (.qrc) in the expected XDG layout and with an
> > > icon theme index file. We can then use
> > > QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> > > through the .ui file or in code).
> > >
> > > The problem we've run into is that when the application is launched in
> > > a mixed-DPI setup, for example a retina Mac laptop with an external
> > > lower-DPI monitor, the icons appear too large and get cropped. In
> > > effect, it seems to always use the DPI of the primary screen (the
> > > built-in retina screen) when calculating the size of the pixmaps it
> > > generates for the icons.
> >
> >
> > Not sure if this is your problem, but it seems that
> > QSvgIconEngine::virtual_hook does not handle the
QIconEngine::ScaledPixmapHook
> > call, which is needed for the QIcon::pixmap(QWindow *window, ...) call.
>
> Thanks Olivier,
>
> I'm not familiar with the code, but it sounds like that could be it.
>
> I'll try to make a minimal test case tomorrow.
I've now created a minimal test case:
dirac:~ insight$ find testcase
testcase
testcase/testcase.cpp
testcase/icons
testcase/icons/mytheme
testcase/icons/mytheme/index.theme
testcase/icons/mytheme/scalable
testcase/icons/mytheme/scalable/actions
testcase/icons/mytheme/scalable/actions/test-icon.svg
testcase/testcase.pro
testcase/testcase.qrc
dirac:~ insight$
testcase.cpp:
#include
#include
#include
int main(int argc, char *argv[]) {
QApplication app(argc, argv);
app.setAttribute(Qt::AA_UseHighDpiPixmaps);
QIcon::setThemeName("mytheme");
// Create icon from file name -> Size of pixmap is correct on both
screens
QToolButton button1;
button1.setIcon(QIcon("icons/mytheme/scalable/actions/test-icon.svg"));
button1.show();
// Create icon from theme -> Size of pixmap is correct only on primary
screen
QToolButton button2;
button2.setIcon(QIcon::fromTheme("test-icon"));
button2.show();
return app.exec();
}
This is the result when running on the external lower-DPI monitor:
[image: testcase.png]
Note how the right button icon (button2), which is created using
QIcon::fromTheme has the wrong pixmap size for that monitor (it's
appropriate for the internal retina screen).
And it really does seem like the Qt::AA_UseHighDpiPixmaps application
attribute has a finger in the game here, because if I remove setting of
that attribute, the problem goes away.
Attaching the full test case as a ZIP.
Should I report this as a bug?
Elvis
>
> Elvis
>
> >
> >
> >
> >
> > >
> > > To work around this, we've had to put in special code in all of our
> > > widgets that use icons. The code reacts to screen change events (or
> > > changes to the underlying QWindow in some cases), and in that code, go
> > > through each and every one of our icons and do this monkey dance:
> > >
> > > auto pixmap =
someButton->icon().pixmap(someButton->iconSize());
> > >
pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
> > > someButton->setIcon(QIcon(pixmap));
> > >
> > > So essentially taking the pixmap out of the icon, set its DPR to that
> > > of the current screen, and then set that pixmap back on the icon.
> > >
> > > This "works", the icons now look correct on both the retina screen and
> > > the external one, and adjust themselves when the application is moved
> > > back and forth, or when the external monitor is activated/deactivated.
> > >
> > > But surely this kludge should not be necessary? We've provided Qt with
> > > an SVG, so it should be able to work out on its own that the screen
> > > has changed, and regenerate an appropriate pixmap in response to that?
> > >
> > > Some more details:
> > >
> > > - We are running with the
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den mån 8 apr. 2019 kl 09:35 skrev Mark De Wit :
>
> Are you using Fusion theme by any chance? I'm facing the same issue, I even
> tried writing my own Icon Engine to try and improve matters, but turns out
> widgets are simply requesting the wrong size icon - nothing the icon engine
> can do to "second-guess" such requests...
We're using the Cocoa theme on Mac.
>
> I have filed one such issue here:
> https://bugreports.qt.io/browse/QTBUG-74100, and in general I feel that Qt's
> geometry handling in mixed DPI is still rather poor. I will often have my
> application start up at ridiculous sizes (3/4 offscreen etc) because it has
> completely nonsensical geometry coordinates for windows (Qt applying scaling
> to coordinates when it's not required etc).
Sounds from the description that you've identified another way this
could be explained (using the wrong pixmap(...) overload), apart from
what Olivier brought up.
But it sounds good to me if our problem is either of these, as it
sounds like it should be fixable.
Elvis
>
> Mark
>
> -----Original Message-
> From: Development On Behalf Of Elvis
> Stansvik
> Sent: 07 April 2019 19:21
> To: Olivier Goffart
> Cc: development@qt-project.org
> Subject: Re: [Development] What to expect from QIcon/the icon engine on
> screen changes
>
> Den sön 7 apr. 2019 kl 18:45 skrev Olivier Goffart :
> >
> > On 06.04.19 10:40, Elvis Stansvik wrote:
> > > Hi all,
> > >
> > > I'm looking for someone who knows the inner workings of QIcon and
> > > the icon engines.
> > >
> > > In our application, we almost exclusively use SVG icons, and we use
> > > a single SVG file for each icon (no @2x versions) that we try to
> > > design to work reasonably well at all sizes, since we do not have
> > > the resources to make custom variations for each target size.
> > >
> > > We put these SVG icons into an XDG icon theme, that we ship inside
> > > the application resources (.qrc) in the expected XDG layout and with
> > > an icon theme index file. We can then use
> > > QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> > > through the .ui file or in code).
> > >
> > > The problem we've run into is that when the application is launched
> > > in a mixed-DPI setup, for example a retina Mac laptop with an
> > > external lower-DPI monitor, the icons appear too large and get
> > > cropped. In effect, it seems to always use the DPI of the primary
> > > screen (the built-in retina screen) when calculating the size of the
> > > pixmaps it generates for the icons.
> >
> >
> > Not sure if this is your problem, but it seems that
> > QSvgIconEngine::virtual_hook does not handle the
> > QIconEngine::ScaledPixmapHook call, which is needed for the
> > QIcon::pixmap(QWindow *window, ...) call.
>
> Thanks Olivier,
>
> I'm not familiar with the code, but it sounds like that could be it.
>
> I'll try to make a minimal test case tomorrow.
>
> Elvis
>
> >
> >
> >
> >
> > >
> > > To work around this, we've had to put in special code in all of our
> > > widgets that use icons. The code reacts to screen change events (or
> > > changes to the underlying QWindow in some cases), and in that code,
> > > go through each and every one of our icons and do this monkey dance:
> > >
> > > auto pixmap = someButton->icon().pixmap(someButton->iconSize());
> > >
> > > pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
> > > someButton->setIcon(QIcon(pixmap));
> > >
> > > So essentially taking the pixmap out of the icon, set its DPR to
> > > that of the current screen, and then set that pixmap back on the icon.
> > >
> > > This "works", the icons now look correct on both the retina screen
> > > and the external one, and adjust themselves when the application is
> > > moved back and forth, or when the external monitor is
> > > activated/deactivated.
> > >
> > > But surely this kludge should not be necessary? We've provided Qt
> > > with an SVG, so it should be able to work out on its own that the
> > > screen has changed, and regenerate an appropriate pixmap in response to
> > > that?
> > >
> > > Some more details:
> > >
> > > - We are running with the Qt::AA_UseHighDpiPixmaps application
> > > attribute turned on. I'm not sure this is relevant for this issue
> > >
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den sön 7 apr. 2019 kl 18:45 skrev Olivier Goffart :
>
> On 06.04.19 10:40, Elvis Stansvik wrote:
> > Hi all,
> >
> > I'm looking for someone who knows the inner workings of QIcon and the
> > icon engines.
> >
> > In our application, we almost exclusively use SVG icons, and we use a
> > single SVG file for each icon (no @2x versions) that we try to design
> > to work reasonably well at all sizes, since we do not have the
> > resources to make custom variations for each target size.
> >
> > We put these SVG icons into an XDG icon theme, that we ship inside the
> > application resources (.qrc) in the expected XDG layout and with an
> > icon theme index file. We can then use
> > QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> > through the .ui file or in code).
> >
> > The problem we've run into is that when the application is launched in
> > a mixed-DPI setup, for example a retina Mac laptop with an external
> > lower-DPI monitor, the icons appear too large and get cropped. In
> > effect, it seems to always use the DPI of the primary screen (the
> > built-in retina screen) when calculating the size of the pixmaps it
> > generates for the icons.
>
>
> Not sure if this is your problem, but it seems that
> QSvgIconEngine::virtual_hook does not handle the QIconEngine::ScaledPixmapHook
> call, which is needed for the QIcon::pixmap(QWindow *window, ...) call.
Thanks Olivier,
I'm not familiar with the code, but it sounds like that could be it.
I'll try to make a minimal test case tomorrow.
Elvis
>
>
>
>
> >
> > To work around this, we've had to put in special code in all of our
> > widgets that use icons. The code reacts to screen change events (or
> > changes to the underlying QWindow in some cases), and in that code, go
> > through each and every one of our icons and do this monkey dance:
> >
> > auto pixmap = someButton->icon().pixmap(someButton->iconSize());
> >
> > pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
> > someButton->setIcon(QIcon(pixmap));
> >
> > So essentially taking the pixmap out of the icon, set its DPR to that
> > of the current screen, and then set that pixmap back on the icon.
> >
> > This "works", the icons now look correct on both the retina screen and
> > the external one, and adjust themselves when the application is moved
> > back and forth, or when the external monitor is activated/deactivated.
> >
> > But surely this kludge should not be necessary? We've provided Qt with
> > an SVG, so it should be able to work out on its own that the screen
> > has changed, and regenerate an appropriate pixmap in response to that?
> >
> > Some more details:
> >
> > - We are running with the Qt::AA_UseHighDpiPixmaps application
> > attribute turned on. I'm not sure this is relevant for this issue
> > though, because AFAIK that attribute is only about picking 2x versions
> > of icons (we have a couple of those, where we have PNGs with 2x
> > versions).
> >
> > - We are not running with Qt's built-in scaling activated, but relying
> > on the Mac platform scaling (I'm not even sure Qt's built-in scaling
> > is applicable on Mac). The application runs with
> > NSHighResolutionCapable set to True in its Info.plist (which I also
> > think is the default nowadays).
> >
> > - I have not investigated yet whether this problem also occurs on a
> > mixed-DPI Linux setup, with Qt's high-dpi scaling activated. Nor have
> > I checked if it happens on Windows using it's artificial "screen
> > scaling" (we do not use Qt's built-in scaling on Windows either,
> > trying to follow the advise in the docs to avoid that for new
> > applications). So for now this is only about Mac retina + external
> > monitor.
> >
> > Any advise on this would be highly appreciated, because the code
> > required to re-trigger pixmap generation on screen changes is a real
> > kludge all over our code base, and often it happens that we add
> > buttons et.c. with icons, but forget to update this machinery.
> >
> > I'm not at the office at the moment, but can provide a little test
> > program that mimics what we're doing on Monday.
> >
> > Thanks in advance,
> > Elvis
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> >
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] What to expect from QIcon/the icon engine on screen changes
Den lör 6 apr. 2019 kl 10:40 skrev Elvis Stansvik :
>
> Hi all,
>
> I'm looking for someone who knows the inner workings of QIcon and the
> icon engines.
>
> In our application, we almost exclusively use SVG icons, and we use a
> single SVG file for each icon (no @2x versions) that we try to design
> to work reasonably well at all sizes, since we do not have the
> resources to make custom variations for each target size.
>
> We put these SVG icons into an XDG icon theme, that we ship inside the
> application resources (.qrc) in the expected XDG layout and with an
> icon theme index file. We can then use
> QIcon::fromTheme("our-app-some-icon") to reference an icon (either
> through the .ui file or in code).
>
> The problem we've run into is that when the application is launched in
> a mixed-DPI setup, for example a retina Mac laptop with an external
> lower-DPI monitor, the icons appear too large and get cropped. In
To clarify: This happens when the application is on the external
screen. On the retina screen it looks correct
> effect, it seems to always use the DPI of the primary screen (the
> built-in retina screen) when calculating the size of the pixmaps it
> generates for the icons.
>
> To work around this, we've had to put in special code in all of our
> widgets that use icons. The code reacts to screen change events (or
> changes to the underlying QWindow in some cases), and in that code, go
> through each and every one of our icons and do this monkey dance:
>
> auto pixmap = someButton->icon().pixmap(someButton->iconSize());
>
> pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
> someButton->setIcon(QIcon(pixmap));
>
> So essentially taking the pixmap out of the icon, set its DPR to that
> of the current screen, and then set that pixmap back on the icon.
>
> This "works", the icons now look correct on both the retina screen and
> the external one, and adjust themselves when the application is moved
> back and forth, or when the external monitor is activated/deactivated.
>
> But surely this kludge should not be necessary? We've provided Qt with
> an SVG, so it should be able to work out on its own that the screen
> has changed, and regenerate an appropriate pixmap in response to that?
>
> Some more details:
>
> - We are running with the Qt::AA_UseHighDpiPixmaps application
> attribute turned on. I'm not sure this is relevant for this issue
> though, because AFAIK that attribute is only about picking 2x versions
> of icons (we have a couple of those, where we have PNGs with 2x
> versions).
>
> - We are not running with Qt's built-in scaling activated, but relying
> on the Mac platform scaling (I'm not even sure Qt's built-in scaling
> is applicable on Mac). The application runs with
> NSHighResolutionCapable set to True in its Info.plist (which I also
> think is the default nowadays).
>
> - I have not investigated yet whether this problem also occurs on a
> mixed-DPI Linux setup, with Qt's high-dpi scaling activated. Nor have
> I checked if it happens on Windows using it's artificial "screen
> scaling" (we do not use Qt's built-in scaling on Windows either,
> trying to follow the advise in the docs to avoid that for new
> applications). So for now this is only about Mac retina + external
> monitor.
>
> Any advise on this would be highly appreciated, because the code
> required to re-trigger pixmap generation on screen changes is a real
> kludge all over our code base, and often it happens that we add
> buttons et.c. with icons, but forget to update this machinery.
>
> I'm not at the office at the moment, but can provide a little test
> program that mimics what we're doing on Monday.
>
> Thanks in advance,
> Elvis
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] What to expect from QIcon/the icon engine on screen changes
Hi all,
I'm looking for someone who knows the inner workings of QIcon and the
icon engines.
In our application, we almost exclusively use SVG icons, and we use a
single SVG file for each icon (no @2x versions) that we try to design
to work reasonably well at all sizes, since we do not have the
resources to make custom variations for each target size.
We put these SVG icons into an XDG icon theme, that we ship inside the
application resources (.qrc) in the expected XDG layout and with an
icon theme index file. We can then use
QIcon::fromTheme("our-app-some-icon") to reference an icon (either
through the .ui file or in code).
The problem we've run into is that when the application is launched in
a mixed-DPI setup, for example a retina Mac laptop with an external
lower-DPI monitor, the icons appear too large and get cropped. In
effect, it seems to always use the DPI of the primary screen (the
built-in retina screen) when calculating the size of the pixmaps it
generates for the icons.
To work around this, we've had to put in special code in all of our
widgets that use icons. The code reacts to screen change events (or
changes to the underlying QWindow in some cases), and in that code, go
through each and every one of our icons and do this monkey dance:
auto pixmap = someButton->icon().pixmap(someButton->iconSize());
pixmap.setDevicePixelRatio(window()->windowHandle()->screen()->devicePixelRatio());
someButton->setIcon(QIcon(pixmap));
So essentially taking the pixmap out of the icon, set its DPR to that
of the current screen, and then set that pixmap back on the icon.
This "works", the icons now look correct on both the retina screen and
the external one, and adjust themselves when the application is moved
back and forth, or when the external monitor is activated/deactivated.
But surely this kludge should not be necessary? We've provided Qt with
an SVG, so it should be able to work out on its own that the screen
has changed, and regenerate an appropriate pixmap in response to that?
Some more details:
- We are running with the Qt::AA_UseHighDpiPixmaps application
attribute turned on. I'm not sure this is relevant for this issue
though, because AFAIK that attribute is only about picking 2x versions
of icons (we have a couple of those, where we have PNGs with 2x
versions).
- We are not running with Qt's built-in scaling activated, but relying
on the Mac platform scaling (I'm not even sure Qt's built-in scaling
is applicable on Mac). The application runs with
NSHighResolutionCapable set to True in its Info.plist (which I also
think is the default nowadays).
- I have not investigated yet whether this problem also occurs on a
mixed-DPI Linux setup, with Qt's high-dpi scaling activated. Nor have
I checked if it happens on Windows using it's artificial "screen
scaling" (we do not use Qt's built-in scaling on Windows either,
trying to follow the advise in the docs to avoid that for new
applications). So for now this is only about Mac retina + external
monitor.
Any advise on this would be highly appreciated, because the code
required to re-trigger pixmap generation on screen changes is a real
kludge all over our code base, and often it happens that we add
buttons et.c. with icons, but forget to update this machinery.
I'm not at the office at the moment, but can provide a little test
program that mimics what we're doing on Monday.
Thanks in advance,
Elvis
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Looking for Feedback QDeferred
Looks nice! From an API perspective I would call the provider APIs fail(...) and succeed(...) instead of reject(...) and resolve(...), and the corresponding consumer APIs onSucceeded(...) and onFailed(...) (or whenSucceeded(...) / whenFailed(...)). Or something else that makes the connection between the two clear. But that's just my 2 cents. Cheers, Elvis Den mån 11 feb. 2019 kl 12:50 skrev Juan Gonzalez Burgos : > > Hi guys, > > Sorry to bother you with yet another promise/deferred library for Qt. I am > looking for feedback. > > https://github.com/juangburgos/QDeferred > > Thanks. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Archiving is working
Den fre 25 jan. 2019 kl 19:23 skrev Giuseppe D'Angelo via Development
:
>
> Il 25/01/19 18:41, Edward Welbourne ha scritto:
> > The pages have all been updated and had their URLs changed.
> > Or are you trying to tell me something else ?
> > I'm not sure I fully understand.
>
> Yes. And that's the problem. It *MUST NOT* happen. Links to mails in the
> mailing list are found in commit messages, on the bugtracker, and so on.
> Breaking them is a big no-no-no.
>
>
> As I said before, the new archive is corrupted, and thus must be fixed.
> Look at the numbering of emails from the new archives and note at how it
> "jumps":
>
> > https://lists.qt-project.org/pipermail/development/2011-October/date.html
>
> Compare it to the old numbering (progressive):
>
> > https://web.archive.org/web/20180408194615/http://lists.qt-project.org/pipermail/development/
>
>
>
> Then take a look at the current archive:
>
> > https://lists.qt-project.org/pipermail/development/2011-October.txt.gz
>
> Compare it with the old archive:
>
> > https://web.archive.org/web/20180408194615/http://lists.qt-project.org/pipermail/development/2011-October.txt.gz
>
> The new archive is corrupted; there are duplicated emails in there.
> What's needed now is to make pipermail produce a result identical to the
> old archive.
+1 https://www.w3.org/Provider/Style/URI ("Cool URIs don't change")
If you're going accept this as "solved", be aware that you're breaking
links in a *lot* of places, not just on Qt infra like QUIPs and
whatnot, but lots of other public forums, mailing lists, code bases,
commit messages, issue trackers etc.
I really think you need to find a way to make existing links work again.
Elvis
>
>
> 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
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] gnuwin32 in qt5.git
Den fre 18 jan. 2019 kl 17:47 skrev Kai Koehne : > > > -Original Message- > > From: Development On Behalf Of > > [...] > > Would it make sense to use a package manager like Conan to provide third > > party dependencies as well as Qt modules in source and prebuilt binary form? > > That could solve the availability issue and would probably simplify the > > build > > flow as well. > > Conan.io and Vcpkg are hot candidates, indeed. IMO we need something that > - Works natively on all development platforms > - Has a strong ecosystem which we can benefit from > - Supports both building locally, as well as providing pre-build binaries Not that I know much about the needs here, but I would expect also - Supports pinning to a specific version ? With that I mean the ability to lock a dependency to a specific version, à la pinning in pip/PyPI in the Python world. A system that only has the latest versions of everything available (e.g. like Homebrew on the Mac side, unless you consider "taps") would not be very good I imagine, since I think you'll want to lock in known good versions? Elvis > > Regards > > Kai > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Coding style for lambdas with empty parameter list
Den fre 11 jan. 2019 kl 20:11 skrev Thiago Macieira : > > On Friday, 11 January 2019 09:16:20 PST Konstantin Ritt wrote: > > +1 for []() > > Let's use <:]() instead. :D Perfect, and looks kinda like santa. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] automated bulk change closing old issues in the "Need more info" state
Den mån 19 nov. 2018 kl 17:36 skrev Shawn Rutledge : > > > > On 19 Nov 2018, at 16:09, Uwe Rathmann wrote: > > > > Hi all, > > > > I just received 2 messages about: automated bulk change closing old > > issues in the "Need more info" state. > > > > - https://bugreports.qt.io/browse/QTBUG-68874 > > - https://bugreports.qt.io/browse/QTBUG-66264 > > > > I have no idea why they have been set to "Need more info" - actually one > > of them has been explicitly answered, but the developer does not follow > > up. > > When you answer the question, you are supposed to hit the “provide missing > info” button: that takes it out of that state. > > Also, every week we have a team of 2 people triaging bugs. Part of that job > is to check all the bugs that are in “need more info” state, and decide > whether the info is now sufficient. Then it should either be moved out of > “need more info” state, or closed. But it’s easy to ignore that… so I > suspect many triage teams aren’t trying very hard to get through those. > Often, the reporter of the bug does not provide any extra info for a long > period of time, so it is demotivating to go through the list and just confirm > yet again that nothing new was added to most of them. > > https://bugreports.qt.io/issues/?filter=16028 currently has 169 bugs in that > state. Having that many is an obstacle: I don’t suppose this week’s triage > team is going to get through all of those and make intelligent decisions > about them, either. If it was only 10, maybe they would. > > So to shorten that list, it helps a lot if you hit the “provide missing info” > button when you answer a question. If the bug does not have a priority > and/or is unassigned, then it’s going to get looked at again by that week’s > triage team. If it stays in “need more info” state, it might be ignored for > a while because it’s not in the un-triaged list. Not ideal, but that’s how > it’s actually been. > > I suspect the reason people don’t hit that button is that it’s at the top, > whereas when you add a normal comment, you press the comment button at the > bottom. And if you are actually answering the question with your comment, > you assume that’s enough, right? So maybe that button should be (repeated?) > at the bottom left. But I doubt we can customize our Jira to that extent. Maybe some standard reminder about the "Provide Missing Info" button could be added when the issue is first put into "Need More Info" state? If the info is there as part of the normal comment flow, the one making the followup comment with more info would see it I think (Not sure to what extent that could be automated though). Elvis > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Opinions on QTBUG-71545
Den tis 6 nov. 2018 kl 13:56 skrev André Somers : > > Hi, > > > On 05/11/2018 20:56, Elvis Stansvik wrote: > > Den mån 5 nov. 2018 kl 20:32 skrev Konstantin Shegunov > > : > >> Hello, > >> Since we couldn't agree, I'd love to see some more opinions about this > >> one.[1] > > I may be missing some detail, but I think what Thiago says makes > > sense. When children are destroyed, you know you're in the QObject > > destructor (from QObject::~QObject docs: "Destroys the object, > > deleting all its child objects."), so you know the object is now a > > QObject, no longer a QCoreApplication. If you require your > > QCoreApplication to be alive by the time your child object is > > destroyed, I think you have to ensure this on your own. > Problem is, I think, that this requirement is not always obvious. For > your own objects, you know you cannot rely on your parent still being a > MyClass iso of just a QObject on destruction (unless you take specific > measures to make that so), but in this case the reliance on there still > being a Q*Application around (not necessarily the parent) is usually not > as obvious as a myParent->doSomethingNotFromQObject call in your > destructor code... Yea, very good point. I'll leave it to the grow-ups to decide what to do with this :) It was just my first gut reaction. Elvis > > > > Like I said, I may be missing something, but that's what it looks like > > to me. I can't see why there would be an exception to the object model > > here. > > > > Elvis > > > >> Specifically: > >> 1) Is parenting to the application object a thing? > Yes. But you know that the same goes as for any QObject parent/child > relationship: the parent is a QObject at the time of destruction (ok, > with QWidget, you're in luck). > >> 1.a) ... and should it be allowed (i.e. accepting the proposed change)? > Yes, it should be allowed, and as you argued I think it is useful. But I > am not sure that implies the proposed change. OTOH, as so much > functionality in Qt requires the Q*Application to be alive (and that is > not always obvious) , perhaps an exception *is* in order. > >> 1.b) .. if not allowed, should we put a warning in the documentation that > >> it is wrong and shouldn't be done at all, or at least that it's > >> discouraged. > >> > >> [1] https://bugreports.qt.io/browse/QTBUG-71545 > I do think it makes sense to be able to do this, but if that is to be > discouraged, then best be explicit about that. > > André > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Opinions on QTBUG-71545
Den mån 5 nov. 2018 kl 21:35 skrev Thiago Macieira : > > On Monday, 5 November 2018 12:07:15 PST Elvis Stansvik wrote: > > If it is to be the same as all other QObjects, then it should maintain > > its current behavior I think. The destruction of children happens in > > the QObject destructor. I don't even think one have to look at the > > QObject destructor docs to understand that - where else would it be > > done, considering the parent/child mechanism is a mechanism common to > > all QObject-derived classes > > Ah, but there's an exception: QWidget's destructor destroys its children, so > that they get to see their parent before the QWidget ceases to be a QWidget. Ah yes, I was talking about QObjects in general. QWidget is an exception. Having hardly ever relied on that behavior more than indirectly, I almost forgot about it. But seems to me it would be a slippery slope to accept more exceptions. What's next, will I have to implement the destruction myself in my own widgets? :) Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Opinions on QTBUG-71545
Den mån 5 nov. 2018 kl 20:58 skrev Tomasz Siekierda : > > On Mon, 5 Nov 2018 at 20:32, Konstantin Shegunov wrote: > > > > Hello, > > Since we couldn't agree, I'd love to see some more opinions about this > > one.[1] > > > > Specifically: > > 1) Is parenting to the application object a thing? > > Never done it myself. But Q*Application is clearly marked as derived > from QObject in the docs, so users can definitely expect it to behave > the same as all other QObjects and clean up it's children properly. If it is to be the same as all other QObjects, then it should maintain its current behavior I think. The destruction of children happens in the QObject destructor. I don't even think one have to look at the QObject destructor docs to understand that - where else would it be done, considering the parent/child mechanism is a mechanism common to all QObject-derived classes Elvis > > > 1.a) ... and should it be allowed (i.e. accepting the proposed change)? > > 1.b) .. if not allowed, should we put a warning in the documentation that > > it is wrong and shouldn't be done at all, or at least that it's discouraged. > > Either is OK I think, with preference for 1.a). Note: these are not > mutually exclusive - we could have the patch integrated & a warning in > the docs that this is not encouraged. > > > Disclaimer: I'm not a reviewer, nor approver, barely a contributor > even, so feel free to ignore my opinion. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Opinions on QTBUG-71545
Den mån 5 nov. 2018 kl 20:32 skrev Konstantin Shegunov : > > Hello, > Since we couldn't agree, I'd love to see some more opinions about this one.[1] I may be missing some detail, but I think what Thiago says makes sense. When children are destroyed, you know you're in the QObject destructor (from QObject::~QObject docs: "Destroys the object, deleting all its child objects."), so you know the object is now a QObject, no longer a QCoreApplication. If you require your QCoreApplication to be alive by the time your child object is destroyed, I think you have to ensure this on your own. Like I said, I may be missing something, but that's what it looks like to me. I can't see why there would be an exception to the object model here. Elvis > > Specifically: > 1) Is parenting to the application object a thing? > 1.a) ... and should it be allowed (i.e. accepting the proposed change)? > 1.b) .. if not allowed, should we put a warning in the documentation that it > is wrong and shouldn't be done at all, or at least that it's discouraged. > > [1] https://bugreports.qt.io/browse/QTBUG-71545 > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtConcurrent replacement candidate
There were some discussions last year on https://bugreports.qt.io/browse/QTBUG-61928 about the async API future (pun intended). I'm sure there are a few old mailing list threads too. I too would be interested in where Qt is heading in this area going forward. We're using the current QtConcurrent APIs, and also sometimes using the private-ish QFutureInterface to be able to use QFuture to its full extent, which makes us feel a little dirty :) Elvis Den tors 1 nov. 2018 kl 00:57 skrev Denis Kormalev : > > Hi, > > As part of our work projects we have a framework (named Proof and partly open > sourced). Most part of it is not really interesting outside of our industry, > but one of its basic ideas is heavy usage of future/promise technology with > API similar to one used in Scala. We also have tasks scheduling helpers that > are based on these futures. > I would like to ask Qt community if Qt itself needs QFuture/QtConcurrent > redoing and replacing with something similar to what we do. > If community will find it interesting I'm more than happy to implement it and > do everything to make it as part of Qt someday. > Current API is a bit specific for our projects and of course need to be > reworked, but main idea can be seen from examples listed at > https://github.com/opensoft/proofseed#futures-examples . > Future/Promise API can be seen at > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/future.h > . Main idea is that all interaction is done via QSharedPointer wrappers. I > assume it is not the best way to do it and probably FutureSP should be named > Future (with protected inheritance from QSharedPointer and having all methods > from Future) and Future should be named something like FutureData. > Tasks scheduling is done mostly via run() function specified at > https://github.com/opensoft/proofseed/blob/develop/include/proofseed/tasks.h#L181 > . > Future also has negative class named Failure, which in case of Qt adoption > probably should be just a QVariant (current implementation is, as I mentioned > previously, a bit specific for our projects). > > Anyway, I would like to start a discussion if Qt community thinks that > something like that could be useful as part of Qt itself. In this case I can > work on basic API with having Future inherited from QSharedPointer and show > it for early API review. > I never did anything greater than bugfixes for Qt, so I would also need few > recommendations about where to start (I assume I will need a repo in qt > playground for stuff like that). > > Another question is about legal stuff. This library is BSD-3 licensed and I > assume I will need some documents from my company if this implementation will > be heavily similar to existing library. If anyone can advise (again, of > course if Qt community will find it interesting) I would really appreciate > it. 2 > > -- > Regards, > Denis Kormalev > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Den sön 28 okt. 2018 kl 14:29 skrev Alexey Andreyev : > > > [...] or the shorter list in the KDE CoC, so we instinctively > > want to trim the fat - we want to optimize. > > I've provided both (CC and from KDE) not to show some version is better, > but to show both have same problems. > > For me it's not about optimization right now. Is it possible to follow > provided versions? > And receive more positive for the commuity than negative. > > > the purpose of this enumeration is to list those very large > > groups of people in society who are currently experiencing harassment > > and mistreatment for who they are > > Is that obvious that provided document will help not made things worse for > everyone? > Are we going to treat something at the commuity just blindly without > diagnosis and research? > > > We tell a large part of the population who are currently > > being oppressed/mistreated that, at least in our community, you can > > feel safe > > How are we going to provide safety? > > > The enumeration is not supposed to cover everything, but I > > think it fulfills a purpose by covering a lot. > > As far as I can see the reasoning is based on the hypothesis that any rules > will not be able to aggravate the situation. It's not obvious. > > > I don't agree with some earlier poster who thought of the enumeration > > as setting some kind of bar, I don't think that is the purpose of it. > > > The concluding "[...] or any other characteristics that are > > not relevant to a person's ability to contribute to the Qt Project." > > is of course very important *as well*, to cover our bases. > > How the committee is going to determine that someone has violated these > "guidelines not bars"? > What is the purpose of the guidelines without additional information how to > protect them? > > > I can't really see how this list could be misused. If people have an > > issue with a particular item on the list, they should say so. > > For example, let's say some person (person or legal entity, organization or > groups of organizations) have projects, competing with Qt somehow (or linux, > or KDE). > That "person/groups" will get more profit if Qt community will became > unhealthy or will cease to exist. > That person could sponsor, support or pay money somehow to other persons to > support some vulnerable ideas. > Persons who accept that ideas and have interests, conflicting with the > community, could say something like > "hey, we are actually feeling harassment, please accept our > ideas/patches/anything too". > It is a space for accepting non-obvious security or architectural changes. > > In 50, 10 or 5 years :) if attackers will be lucky enough, Qt community could > lost their image of as awesome commuity as it is right now. I honestly think this is an extremely contrived example, and I think you're worrying way too much, but OK let's play along. You're suggesting that someone would submit bad patches, hoping to get harassed and thereby somehow get the patches in, as some sort of compensation for the harassment, and would use this in order to sabotage the Qt project? Looking past the ridiculousness of that idea for the moment, getting your patches rejected is not harassment. Not under any definition of harassment that I know of, and certainly not according to the suggested CoC. The patches can be respectfully rejected with e.g. "this is not in line with the Qt vision", or "could you please revise this part first?". The patches can also be rejected with "please don't submit crap like this, you fat dyke". See the difference? The first is not a matter for the CoC. If the party would still file a complaint, it would be dealt with and the council would find that no harassment took place. The second would most certainly be cause for some kind of action (I guess to begin with, tell the offender to not do that again and point them to the CoC). Elvis > > ..??? > > PROFIT! Young generation not interested, no support, commuity is dying, > profit for competing projects. > > > It's just one example that could sound like a joke since I'm not a > professional with this kind of tricky social questions, > but I hope I showed the danger as a caricature at least. > > I don't want my arguments be adressed to someone personally, and I'm not > saying there's some conspiracy here. > I just want to help to save and develop the community for the future. > > I agree we need rules. My problem is not any rules are healthy. > > вс, 28 окт. 2018 г. в 14:37, Elvis Stansvik : >> >> Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev >> : >> >
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 13:32 skrev Giuseppe D'Angelo via Development : > > Il 28/10/18 11:22, Elvis Stansvik ha scritto: > > Though hmm, even if we'd lose move-construction, for the copy we'd get > > instead, wouldn't copy elision kick in and elide it? So we wouldn't > > have to pay for the ref count up/down? > > GCE is one thing, and applies in a very specific case (returning a > prvalue). > > (N)RVO is another thing, and may or may not be applied depending on > whether the compiler *can* apply it and *will* apply it. > > In the general case, you won't have either, and thus having a move will > be cheaper than a copy. Returning const objects for types which benefit > from moves is a bad idea. Ah yes of course, my bad. Elvis > > 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 > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Den sön 28 okt. 2018 kl 11:34 skrev Alexey Andreyev : > > Hello, Tomasz! :) > Thank you for the question! > > Current draft based on CoC: > > > Our Pledge > > == > > In the interest of fostering an open and welcoming environment, we > > as contributors to and maintainers of the Qt Project pledge to make > > participation in our project and our community a harassment-free > > experience for everyone, regardless of age, body size, disability, > > ethnicity, sex characteristics, gender identity and expression, level > > of experience, education, socio-economic status, nationality, personal > > appearance, race, religion, or sexual identity and orientation, > > or any other characteristics that are not relevant to a person's > > ability to contribute to the Qt Project. A lot of people seem to have a problem with this long enumeration. I think this is because we're programmers, and we think of it as redundant given the concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project.", or the shorter list in the KDE CoC, so we instinctively want to trim the fat - we want to optimize. But, and this is of course just my personal opinion/interpretation, I think the purpose of this enumeration is to list those very large groups of people in society who are currently experiencing harassment and mistreatment for who they are. The pledge is supposed to be a set of guidelines for how the community operates, but *also* a message to potential contributors. Thought of that way, I think the enumeration makes sense: We tell a large part of the population who are currently being oppressed/mistreated that, at least in our community, you can feel safe. The enumeration is not supposed to cover everything, but I think it fulfills a purpose by covering a lot. I don't agree with some earlier poster who thought of the enumeration as setting some kind of bar, I don't think that is the purpose of it. It is meant as a message, and to drive that message home with the groups of people we want to reach, I think it makes sense to be explicit. The concluding "[...] or any other characteristics that are not relevant to a person's ability to contribute to the Qt Project." is of course very important *as well*, to cover our bases. If in 5, 10 or 50 years (I know, I'm a pessimist), there is no longer widespread discrimination and mistreatment of people for their race, religion or sexual identity/orientation, but some other groups are being mistreated (again, sorry for the pessimism), then I think it's perfectly fine to revise this list. I can't really see how this list could be misused. If people have an issue with a particular item on the list, they should say so. That's just my 2 cents on the enumeration, which seems to bug people, and I completely understand if others see it differently. Elvis > > and KDE version: > > > We do not tolerate personal attacks, racism, sexism or any other form of > > discrimination. > > Do we have any research about effects it leading? > > How many discrimination suspicions do we have right now? > > How could it be resolved successfully at digital community? > > How many misuse examples do we have at open projects since accepting similar > rules? > > How CoC board are going to protect community from discrimination and > harassment? > > Are CoC committee ready for "affirmative action"? > > I'm not against the rules as a concept, I agree we need it, > but I totally against perverted or undefined rules that could help to destroy > the community. > > I could not accept argument like "let's accept just anything and see how it > goes and fix something later". > "Don't code today what you can't debug tomorrow" :) > > I'm just saying we should think twice befoce accepting something. > > P.S.: I'm ready to change my mind if I've made a mistake, feel free to > criticize, correct and ignore me :) > > вс, 28 окт. 2018 г. в 10:47, Tomasz Siekierda : >> >> > The controversial discrimination protection sentences at least should be >> > carefully discussed. It's not some thing that we could accept as easy as >> > rewrite. >> >> Hi Alexey, I've just read the QUIP proposal and couldn't find any >> controversial sentences. Could you elaborate? Which points shall be >> discussed? >> On Sat, 27 Oct 2018 at 22:41, Konstantin Shegunov >> wrote: >> > >> > On Sat, Oct 27, 2018 at 11:20 PM Thiago Macieira >> > wrote: >> >> >> >> The answer to all of those questions needs to be "yes". Anything short of >> >> that >> >> means the CoC is powerless and just for show. >> > >> > >> > Which was my point exactly. >> > >> >> >> >> Whether there's a termination of employment or not is out of scope, since >> >> the >> >> CoC does not rule TQtC employment and what other work there is inside that >> >> company. >> >> >> >> >> >> Note also it applies to any company. If you're not welcome anymore in the >> >> community where your employer is asking you to do work,
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik :
>
> Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira
> :
> >
> > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> > > Should we instead just encourage people to make returnsQtContainer()
> > > return a const container ?
> >
> > We should not, since the prevents move-construction from happening. You'll
> > pay
> > the cost of two reference counts (one up and one down).
>
> Though hmm, even if we'd lose move-construction, for the copy we'd get
> instead, wouldn't copy elision kick in and elide it? So we wouldn't
> have to pay for the ref count up/down?
>
> I simplified my example a little, so to recap:
>
> $ cat copytest.cpp
> #include
> #include
>
> struct Foo {
> Foo() {
> std::cout << this << " constructed" << std::endl;
> }
> Foo(const Foo &) {
> std::cout << this << " copy constructed" << std::endl;
> }
> Foo(Foo &&) {
> std::cout << this << " move constructed" << std::endl;
> }
> ~Foo() {
> std::cout << this << " destructed" << std::endl;
> }
> std::vector::iterator begin() {
> std::cout << this << " begin" << std::endl; return v.begin();
> };
> std::vector::const_iterator begin() const {
> std::cout << this << " begin const" << std::endl; return v.begin();
> };
> std::vector::iterator end() {
> std::cout << this << " end" << std::endl; return v.end();
> };
> std::vector::const_iterator end() const {
> std::cout << this << " end const" << std::endl; return v.end();
> };
> std::vector v{1, 2, 3};
> };
>
> Foo f() {
> Foo foo;
> return foo;
> }
>
> const Foo constF() {
> Foo foo;
> return foo;
> }
>
> template
> const T moveToConst(T &)
> {
> return std::move(t);
> }
>
> int main(void) {
> std::cout << "without moveToConst:" << std::endl;
> for (auto v : f()) { }
>
> std::cout << std::endl;
>
> std::cout << "with moveToConst:" << std::endl;
> for (auto v : moveToConst(f())) { }
>
> std::cout << std::endl;
>
> std::cout << "with returning const:" << std::endl;
> for (auto v : constF()) { }
>
> std::cout << std::endl;
>
> std::cout << "with recommended way:" << std::endl;
> const auto stuff = f();
> for (auto v : stuff) { }
>
> return 0;
> }
>
> Result:
>
> $ g++ -std=c++17 -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffcc6ac76b0 constructed
> 0x7ffcc6ac76b0 begin
> 0x7ffcc6ac76b0 end
> 0x7ffcc6ac76b0 destructed
>
> with moveToConst:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac76d0 move constructed
> 0x7ffcc6ac7710 destructed
> 0x7ffcc6ac76d0 begin const
> 0x7ffcc6ac76d0 end const
> 0x7ffcc6ac76d0 destructed
>
> with returning const:
> 0x7ffcc6ac76f0 constructed
> 0x7ffcc6ac76f0 begin const
> 0x7ffcc6ac76f0 end const
> 0x7ffcc6ac76f0 destructed
>
> with recommended way:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac7710 begin const
> 0x7ffcc6ac7710 end const
> 0x7ffcc6ac7710 destructed
>
> So it looks like the copy has been elided also in the "with returning
> const" case. Anyone know if this is guaranteed in C++17, or just
> permitted?
>
> If I compile with -fno-elide-constructors to disable elision:
>
> $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c1070f0 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c1070f0 begin
> 0x7ffe7c1070f0 end
> 0x7ffe7c1070f0 destructed
>
> with moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107110 move constructed
> 0x7ffe7c107150 destructed
> 0x7ffe7c107110 begin const
> 0x7ffe7c107110 end const
> 0x7ffe7c107110 destructed
>
> with returning const:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107130 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107130 begin const
> 0x7ffe7c107130 end const
> 0x7ffe7c107130 destructed
>
> with recommended way:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107150 begin con
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 28 okt. 2018 kl 11:22 skrev Elvis Stansvik :
>
> Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira
> :
> >
> > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> > > Should we instead just encourage people to make returnsQtContainer()
> > > return a const container ?
> >
> > We should not, since the prevents move-construction from happening. You'll
> > pay
> > the cost of two reference counts (one up and one down).
>
> Though hmm, even if we'd lose move-construction, for the copy we'd get
> instead, wouldn't copy elision kick in and elide it? So we wouldn't
> have to pay for the ref count up/down?
>
> I simplified my example a little, so to recap:
>
> $ cat copytest.cpp
> #include
> #include
>
> struct Foo {
> Foo() {
> std::cout << this << " constructed" << std::endl;
> }
> Foo(const Foo &) {
> std::cout << this << " copy constructed" << std::endl;
> }
> Foo(Foo &&) {
> std::cout << this << " move constructed" << std::endl;
> }
> ~Foo() {
> std::cout << this << " destructed" << std::endl;
> }
> std::vector::iterator begin() {
> std::cout << this << " begin" << std::endl; return v.begin();
> };
> std::vector::const_iterator begin() const {
> std::cout << this << " begin const" << std::endl; return v.begin();
> };
> std::vector::iterator end() {
> std::cout << this << " end" << std::endl; return v.end();
> };
> std::vector::const_iterator end() const {
> std::cout << this << " end const" << std::endl; return v.end();
> };
> std::vector v{1, 2, 3};
> };
>
> Foo f() {
> Foo foo;
> return foo;
> }
>
> const Foo constF() {
> Foo foo;
> return foo;
> }
>
> template
> const T moveToConst(T &)
> {
> return std::move(t);
> }
>
> int main(void) {
> std::cout << "without moveToConst:" << std::endl;
> for (auto v : f()) { }
>
> std::cout << std::endl;
>
> std::cout << "with moveToConst:" << std::endl;
> for (auto v : moveToConst(f())) { }
>
> std::cout << std::endl;
>
> std::cout << "with returning const:" << std::endl;
> for (auto v : constF()) { }
>
> std::cout << std::endl;
>
> std::cout << "with recommended way:" << std::endl;
> const auto stuff = f();
> for (auto v : stuff) { }
>
> return 0;
> }
I put it up on godbolt for this who want to play: https://godbolt.org/z/x6FPq_
Elvis
>
> Result:
>
> $ g++ -std=c++17 -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffcc6ac76b0 constructed
> 0x7ffcc6ac76b0 begin
> 0x7ffcc6ac76b0 end
> 0x7ffcc6ac76b0 destructed
>
> with moveToConst:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac76d0 move constructed
> 0x7ffcc6ac7710 destructed
> 0x7ffcc6ac76d0 begin const
> 0x7ffcc6ac76d0 end const
> 0x7ffcc6ac76d0 destructed
>
> with returning const:
> 0x7ffcc6ac76f0 constructed
> 0x7ffcc6ac76f0 begin const
> 0x7ffcc6ac76f0 end const
> 0x7ffcc6ac76f0 destructed
>
> with recommended way:
> 0x7ffcc6ac7710 constructed
> 0x7ffcc6ac7710 begin const
> 0x7ffcc6ac7710 end const
> 0x7ffcc6ac7710 destructed
>
> So it looks like the copy has been elided also in the "with returning
> const" case. Anyone know if this is guaranteed in C++17, or just
> permitted?
>
> If I compile with -fno-elide-constructors to disable elision:
>
> $ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
> $ ./copytest
> without moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c1070f0 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c1070f0 begin
> 0x7ffe7c1070f0 end
> 0x7ffe7c1070f0 destructed
>
> with moveToConst:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107150 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107110 move constructed
> 0x7ffe7c107150 destructed
> 0x7ffe7c107110 begin const
> 0x7ffe7c107110 end const
> 0x7ffe7c107110 destructed
>
> with returning const:
> 0x7ffe7c107070 constructed
> 0x7ffe7c107130 move constructed
> 0x7ffe7c107070 destructed
> 0x7ffe7c107130 begin const
> 0x7ffe7c107130 end const
> 0x7ffe7c107130 destructed
>
> with recommended way:
> 0x7ffe7c107070 constructed
> 0x7f
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira :
>
> On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote:
> > Should we instead just encourage people to make returnsQtContainer()
> > return a const container ?
>
> We should not, since the prevents move-construction from happening. You'll pay
> the cost of two reference counts (one up and one down).
Though hmm, even if we'd lose move-construction, for the copy we'd get
instead, wouldn't copy elision kick in and elide it? So we wouldn't
have to pay for the ref count up/down?
I simplified my example a little, so to recap:
$ cat copytest.cpp
#include
#include
struct Foo {
Foo() {
std::cout << this << " constructed" << std::endl;
}
Foo(const Foo &) {
std::cout << this << " copy constructed" << std::endl;
}
Foo(Foo &&) {
std::cout << this << " move constructed" << std::endl;
}
~Foo() {
std::cout << this << " destructed" << std::endl;
}
std::vector::iterator begin() {
std::cout << this << " begin" << std::endl; return v.begin();
};
std::vector::const_iterator begin() const {
std::cout << this << " begin const" << std::endl; return v.begin();
};
std::vector::iterator end() {
std::cout << this << " end" << std::endl; return v.end();
};
std::vector::const_iterator end() const {
std::cout << this << " end const" << std::endl; return v.end();
};
std::vector v{1, 2, 3};
};
Foo f() {
Foo foo;
return foo;
}
const Foo constF() {
Foo foo;
return foo;
}
template
const T moveToConst(T &)
{
return std::move(t);
}
int main(void) {
std::cout << "without moveToConst:" << std::endl;
for (auto v : f()) { }
std::cout << std::endl;
std::cout << "with moveToConst:" << std::endl;
for (auto v : moveToConst(f())) { }
std::cout << std::endl;
std::cout << "with returning const:" << std::endl;
for (auto v : constF()) { }
std::cout << std::endl;
std::cout << "with recommended way:" << std::endl;
const auto stuff = f();
for (auto v : stuff) { }
return 0;
}
Result:
$ g++ -std=c++17 -O0 -o copytest copytest.cpp
$ ./copytest
without moveToConst:
0x7ffcc6ac76b0 constructed
0x7ffcc6ac76b0 begin
0x7ffcc6ac76b0 end
0x7ffcc6ac76b0 destructed
with moveToConst:
0x7ffcc6ac7710 constructed
0x7ffcc6ac76d0 move constructed
0x7ffcc6ac7710 destructed
0x7ffcc6ac76d0 begin const
0x7ffcc6ac76d0 end const
0x7ffcc6ac76d0 destructed
with returning const:
0x7ffcc6ac76f0 constructed
0x7ffcc6ac76f0 begin const
0x7ffcc6ac76f0 end const
0x7ffcc6ac76f0 destructed
with recommended way:
0x7ffcc6ac7710 constructed
0x7ffcc6ac7710 begin const
0x7ffcc6ac7710 end const
0x7ffcc6ac7710 destructed
So it looks like the copy has been elided also in the "with returning
const" case. Anyone know if this is guaranteed in C++17, or just
permitted?
If I compile with -fno-elide-constructors to disable elision:
$ g++ -std=c++17 -fno-elide-constructors -O0 -o copytest copytest.cpp
$ ./copytest
without moveToConst:
0x7ffe7c107070 constructed
0x7ffe7c1070f0 move constructed
0x7ffe7c107070 destructed
0x7ffe7c1070f0 begin
0x7ffe7c1070f0 end
0x7ffe7c1070f0 destructed
with moveToConst:
0x7ffe7c107070 constructed
0x7ffe7c107150 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107110 move constructed
0x7ffe7c107150 destructed
0x7ffe7c107110 begin const
0x7ffe7c107110 end const
0x7ffe7c107110 destructed
with returning const:
0x7ffe7c107070 constructed
0x7ffe7c107130 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107130 begin const
0x7ffe7c107130 end const
0x7ffe7c107130 destructed
with recommended way:
0x7ffe7c107070 constructed
0x7ffe7c107150 move constructed
0x7ffe7c107070 destructed
0x7ffe7c107150 begin const
0x7ffe7c107150 end const
0x7ffe7c107150 destructed
$
What I find surprising here is that with the -fno-elide-constructors
flag, in the "with returning const", the move constructor *is* called.
Didn't we just say it wouldn't, because the const rvalue wouldn't bind
to the non-const rvalue reference?
I'm a little confused :p
Elvis
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 22:23 skrev Thiago Macieira : > > On Saturday, 27 October 2018 08:33:30 PDT Sérgio Martins wrote: > > Should we instead just encourage people to make returnsQtContainer() > > return a const container ? > > We should not, since the prevents move-construction from happening. You'll pay > the cost of two reference counts (one up and one down). Alright, rules that out I guess. From the looks of it, it could be ~100 ns. Elvis > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 21:07 skrev Elvis Stansvik :
>
> Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
> >
> >
> >
> > On 27 Oct 2018, at 19:29, André Pönitz wrote:
> >
> > On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
> >
> > On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
> >
> >
> > Hi all (first post),
> >
> >
> > Welcome :)
> >
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating over Qt
> > containers using range-based for loops without causing a detach.
> >
> > For good reasons there's no version of qAsConst that takes an rvalue
> > reference, so you can't do e.g. for (auto foo :
> > qAsConst(returnsQtContainer()) { ... }. Instead you must do const
> > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
> >
> >
> > Should we instead just encourage people to make returnsQtContainer()
> > return a const container ?
> >
> >
> > This is actually a route we recently took in some cases in Qt Creator's
> > code base.
> >
> >
> > That might actually make sense. Calling a non const method on the returned
> > temporary object is usually a mistake anyway. And the copy/move assignment
> > to a variable will work with the const object.
>
> Hm, but was Marc not right when he said
>
> "Making returned containers const inhibits move semantics, because
> const rvalues do not bind to the mutable rvalue references that move
> constructors and move assignment operators use."
>
> on his blog?
>
> Guess he should jump in here to defend himself :)
Another problem I found when trying to apply this to our code base is
that it seems you can't QtConcurrent::run a function returning const
T, because internally, ResultStoreBase::addResult looks like
template
int addResult(int index, const T *result)
{
if (result == 0)
return addResult(index, static_cast(nullptr));
else
return addResult(index, static_cast(new T(*result)));
}
so you'll get an error like
/usr/include/x86_64-linux-gnu/qt5/QtCore/qresultstore.h:151: error:
static_cast from 'const QVector *' to 'void *' is not allowed
return addResult(index, static_cast(new T(*result)));
^~~
Just a small downside in our case, but still.
Elvis
>
> Elvis
>
> >
> > Cheers,
> > Lars
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 19:48 skrev Lars Knoll :
>
>
>
> On 27 Oct 2018, at 19:29, André Pönitz wrote:
>
> On Sat, Oct 27, 2018 at 04:33:30PM +0100, Sérgio Martins wrote:
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
>
>
> Hi all (first post),
>
>
> Welcome :)
>
> In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> who are not on C++17 yet, which is convenient for iterating over Qt
> containers using range-based for loops without causing a detach.
>
> For good reasons there's no version of qAsConst that takes an rvalue
> reference, so you can't do e.g. for (auto foo :
> qAsConst(returnsQtContainer()) { ... }. Instead you must do const
> auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
>
>
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?
>
>
> This is actually a route we recently took in some cases in Qt Creator's
> code base.
>
>
> That might actually make sense. Calling a non const method on the returned
> temporary object is usually a mistake anyway. And the copy/move assignment to
> a variable will work with the const object.
Hm, but was Marc not right when he said
"Making returned containers const inhibits move semantics, because
const rvalues do not bind to the mutable rvalue references that move
constructors and move assignment operators use."
on his blog?
Guess he should jump in here to defend himself :)
Elvis
>
> Cheers,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 17:33 skrev Sérgio Martins :
>
> On Sat, Oct 20, 2018 at 1:44 PM Elvis Stansvik wrote:
> >
> > Hi all (first post),
>
> Welcome :)
>
> > In Qt 5.7+ there's qAsConst, an std::as_const implementation for those
> > who are not on C++17 yet, which is convenient for iterating over Qt
> > containers using range-based for loops without causing a detach.
> >
> > For good reasons there's no version of qAsConst that takes an rvalue
> > reference, so you can't do e.g. for (auto foo :
> > qAsConst(returnsQtContainer()) { ... }. Instead you must do const
> > auto stuff = returnsQtContainer(); for (auto foo : stuff) { ... }.
>
> Should we instead just encourage people to make returnsQtContainer()
> return a const container ?
> Not sure what's the reason we don't do it in Qt. It's frowned upon for
> regular value types, but our containers are special.
It was the very last comment on that blog post, to which Marc
answered: "Making returned containers const inhibits move semantics,
because const rvalues do not bind to the mutable rvalue references
that move constructors and move assignment operators use."
Elvis
>
> Regards,
> Sergio
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 15:06 skrev Kevin Kofler : > > Elvis Stansvik wrote: > > Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart : > >> Jokes aside, I think we still should let users use Q_FOREACH for > >> implicitly shared containers. > > > > Yes, I thought that Q_FOREACH was slated for deprecation though. But > > maybe that's not set in stone yet? > > That's his point, it should be undeprecated. Ah, now I see. I finally managed to read all the comments on that post, and I definitely don't want to open that can of worms here again. I'm fine with Guiseppes answers to my initial question, a qMoveToConst probably wasn't a good idea in the first place. Elvis > > Kevin Kofler > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 27 okt. 2018 kl 13:37 skrev Olivier Goffart :
>
> On 10/26/18 10:26 PM, Elvis Stansvik wrote:
> > For completely other reasons, I came across "Range-based for
> > statements with initializer" today:
> >
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
> >
> > With that, the Qt best practice could become
> >
> > for (const auto list = getQList(); const auto : list) {
> > ...
> > }
> >
> > Which may or may not be pretty, but avoids the extra line of code and
> > keeps the scope clean.
> >
>
> We could even wrap this in a macro for convenience. We would call that macro
> 'foreach' for example.
> Ah no, wait, this name is already taken by a macro that does exactly that :-)
:)
>
> Jokes aside, I think we still should let users use Q_FOREACH for implicitly
> shared containers.
Yes, I thought that Q_FOREACH was slated for deprecation though. But
maybe that's not set in stone yet?
I just found this post by Marc: https://www.kdab.com/goodbye-q_foreach/
Lots of comments there I haven't had time to go through yet, so I bet
it's a contentious issue :)
Elvis
>
> --
> Olivier
>
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.
For completely other reasons, I came across "Range-based for
statements with initializer" today:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
With that, the Qt best practice could become
for (const auto list = getQList(); const auto : list) {
...
}
Which may or may not be pretty, but avoids the extra line of code and
keeps the scope clean.
Elvis
>
> And note the extra move/destruciton in the second example.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto : moveToConst(getVector()) ~~~
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
>
>
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUIP 12: Code of Conduct
Even if I'm just living in the outskirts of the Qt Project (have for a long time) I just have to say I wholeheartedly agree with Thiago in his thoughts below. One comment inline below. Den fre 26 okt. 2018 07:14Thiago Macieira skrev: > On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote: > > Hi, > > > > regarding our earlier discussions on a possible Code of Conduct, here as > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the > > necessary rules and definitions: > > > > https://codereview.qt-project.org/243623 > > Hello Ulf and everyone else on this thread > > I've posted a few comments here and there relating to the process of > adopting > anything in our community, but I haven't yet voiced my opinion on this > subject. This email is it. > > Note that even though I am speaking for myself, I understand my opinion > reflects on my employer. So I want to say this first: Intel does support > Open > Source Projects adopting Code of Conduct as well as actions leading to > increasing access and diversity of ideas, hopefully leading to improved > code. > We also particularly like the Contributor Covenant text. > > I am also personally in favour of adopting a CoC and I support adopting > either > the Covenant text or KDE's. Both are fine to me. Another good one is > Mozilla's[1], which the SQLite developers have just adopted too. > > In fact, I was there 10 years ago when KDE decided to adopt something. > Back > then, I was also of the opinion that we shouldn't need anything. The KDE > community had always been a welcoming one: in my first Akademy, I was > greeted > by people I had only met online as an old friend. Moreover, the KDE > community > had always resisted any kind of formal structuring of anything, which led > to > the Technical Working Group being created and disbanding in 2006. Even > today, > the KDE e.V. takes great steps to make sure it is never seen as a ruling > body. > > But the CoC was adopted, with no ill effects. I do not have direct > knowledge > of where they had to intervene, if at all, but I'm told it has happened. > More > importantly, I have also grown as a person since then. In a particularly > telling moment, when a female colleague here in the office (located in a > very > affluent, liberal and progressive part of the US) once asked my opinion on > the > Python Donglegate incident and explained to me the reason why she > interpreted > it the way she did, I realised how my worldview was so very different from > hers. I've come to understand how little things that did not bother me > were > highly offensive to her. > > I've seen basically three questions asked by the skepticals to this > proposal: > > 1) if it ain't broke, why fix it? > > To put it simply: the CoC has as an objective make sure the community is > always welcoming and inclusive. People have a limit on how much hostility > (intended or not) they're going to put up with. If they reach that limit, > they're going to simply avoid it and that can be anywhere from avoiding > contributions to certain parts of the code to stopping contributing > altogether > (or worse). We don't want to lose them or their contributions. > > Think of the CoC as preventive maintenance: you don't do it because it's > broken. You do it so it *won't* break in the first place. > > 2) why not let the code rule? > > Code does not exist in isolation and the Qt Project is not a set of files > in > Git. The Qt Project is a community that maintains that code, so we need > rules > beyond code. We have contributors who don't contribute a lot of code, but > that > does not make them any less important members of the community. > > Besides, any commit comes with a commit message. Any review comes with > feedback and there are few that are simply "+2" with no text. We want good > code, improving Qt and for that we need to interact with one another. > Absolutely. And one thing I've when doing code reviews at work is that it's _very_ effective to not only point out problem areas of where things should be done differently, but also point out parts that are particularly good, as encouragement. The reviewee will feel better, and be more productive, producing even better code. Humans are quite simple in that sense :) So it's absolutely not only about code. Elvis Moreover, the major architectural issues are not discussed in code, but in > prose via email. > > Finally, being good at C++ is not an excuse for being a jackass. No one > should > get a pass because they're experts at something. We can't make the cold > calculus that "person X's productivity is worth 10 new contributors so we > will > allow X's behaviour to turn away 10 contributors". What happens on the > 11th? > And what if one of those turned out to be amazing after a few months? > > So clearly code is not enough. > > 3) how do we prevent ill side-effects and abuse? > > One ill side-effect would be the turning away of important contributors > who > feel that the
Re: [Development] Deprecated functions / procedure of removal in Qt6?
Den mån 22 okt. 2018 kl 00:14 skrev Giuseppe D'Angelo via Development
:
>
> Hi,
>
> Il 21/10/18 19:59, Christian Ehrlicher ha scritto:
> > there are a lot of deprecated functions in qtbase which are only marked
> > as deprecated/obsolete in the documentation but don't have a
> > Q_DECL_DEPRECATED. Most of them were deprecated in the pre Qt5-era.
> > What's the 'correct' way to make sure they can be removed with Qt6? Must
> > they marked as QT_DEPRECATED_SINCE(5,x) or is the comment in the
> > documentation enough?
>
> The documentation comment is enough for us to justify the removal -- in
> other words, "formally", we have informed the user to move away, and the
> rule is that we can drop deprecated functions any time we want to break
> source compatibility.
>
>
> However, it's nowhere enough to
>
> 1) make users _aware_ of the fact that they're using deprecated APIs;
> 2) make us _remember_ to remove those functions when we have the chance
> (like in Qt 6).
>
> Thus, adding deprecation warnings is definitely the right thing to do:
> users get the deprecation warnings (*), and we have an easy way to find
> and drop all those functions.
>
> The other ways to achieve 2) at the moment are:
>
> * If possible, all the code to be killed in Qt 6 should already be
> protected via
>
> > #if QT_VERSION < QT_VERSION_CHECK(6, 0, 0)
>
>
> * Add some comment in the source code like
>
> // ### Qt 6: remove this
>
>
> Both ways are more general and apply to functions we can't just
> deprecate or remove (f.i., marking an overload to be merged with another
> one via a default argument, getting rid of useless special member
> function declarations, and the like).
>
> Of course, simply leaving a comment requires us to remember find those
> usages and act on those, and the code is still full of such TODOs for Qt
> 5...
>
>
> (*) I don't like that the deprecation warnings are opt-in and not
> opt-out. People deserve to know as soon as possible that they're using
> deprecated functionality, rather than have a gigantic unpleasant
> surprise ("you're using lots of deprecated stuff that got removed!")
> when Qt 6 comes.
+1 for opt-out from a user.
I had forgotten to add this to the build of our application. Will be
interesting to see what it'll turn up :p
Elvis
>
>
> 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
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.
For completeness sake, indeed
qDebug() << "with recommended way:";
const auto stuff = f();
for (auto v : stuff) { Q_UNUSED(v); }
gives
with recommended way:
FooPrivate constr from vector
Foo constr with arg 0x7ffdc9d50040
Foo begin const 0x7ffdc9d50040
Foo end const 0x7ffdc9d50040
Foo destr 0x7ffdc9d50040
FooPrivate destr
as expected.
Elvis
>
> And note the extra move/destruciton in the second example.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto : moveToConst(getVector()) ~~~
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
>
>
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.
>
> And note the extra move/destruciton in the second example.
Yep, well aware of the extra move/destruction. It's the price we pay
for saving that extra line of code to define a const variable.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto : moveToConst(getVector()) ~~~
Yes, that would be useless, but at least not UB :)
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
Yea, I can understand that. And since all it saves is a line of code,
I guess not worth the trouble.
Elvis
>
>
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den sön 21 okt. 2018 kl 16:15 skrev Elvis Stansvik :
>
> Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development
> :
> >
> > Il 20/10/18 14:43, Elvis Stansvik ha scritto:
> > > In our application we added a helper like
> > >
> > > template
> > > const T moveToConst(T &)
> > > {
> > > return std::move(t);
> > > }
> > >
> > > that we use for these cases. It just moves the argument to a const
> > > value and returns it. With that we can do for (auto foo :
> > > moveToConst(returnsQtContainer()) { ... }.
> > >
> > > Since it's such a common pattern to want to iterate a returned Qt
> > > container, what would you think of having such a helper
> > > (qMoveToConst?) in Qt?
> >
> > Possibly... Note however that such a thing was already proposed for
> > qAsConst itself, and shut down to avoid having qAsConst diverge from
> > std::as_const (and I approve of not having Qt-specific behaviours). I
> > can't find the relevant discussion on the mailing list right now.
> >
> >
> > For reference, std::as_const's original authors had doubts about the
> > lifetime issues around this, saying that more investigations were needed:
> >
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
> >
> >
> > After a LEWG meeting it was reworded like this:
> >
> > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
> >
> >
> > I'm not entirely sure of what prompted the change for as_const -- if
> > just a safety net while waiting for more investigation, or if something
> > more profound was raised.
> >
> >
> > I can easily imagine however a scenario where moveToConst() can lead to
> > worse code than the current solution.
> >
> > Current solution:
> >
> > // GCE may get applied, 0 moves
> > const QVector v = getVector();
> > for (auto : v) ~~~
> >
> > vs.
> >
> > // Always 2 moves
> > for (auto : qMoveToConst(getVector()) ~~~
> >
> >
> > And if the type is not even cheap to move (e.g. QVLA, std::array),
> > qMoveToConst becomes a really unpleasant surprise.
These two points of yours of course still stands, and I can understand
why you wouldn't want this as a helper in Qt because of it.
Elvis
> >
> > How about asking LEWG about their reasoning too?
>
> I couldn't find a way to contact them.
>
> In order to try out the unsafe usage you suggested in your other mail,
> and also another unsafe usage pointed out in an SO question
> (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> I made the following test program.
>
> The output when running is:
>
> [estan@newton move-to-const-test]$ ./move-to-const-test
> without moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627200
> Foo begin 0x7fffdb627200
> Foo end 0x7fffdb627200
> Foo destr 0x7fffdb627200
> FooPrivate destr
>
> with moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627208
> Foo move constr 0x7fffdb627210
> Foo destr 0x7fffdb627208
> Foo begin const 0x7fffdb627210
> Foo end const 0x7fffdb627210
> Foo destr 0x7fffdb627210
> FooPrivate destr
> [estan@newton move-to-const-test]$
>
> Which just shows it's working as intended.
>
> The two unsafe usages are commented out, because they wouldn't compile
> (good!).
>
> Note that the version suggested under Further Discussion in rev 0 is
> different from our helper, we return std::move(t) while they return t.
>
> With the version from rev 0, your example unsafe usage will compile
> (the one from SO still won't).
>
> Elvis
>
> #include
> #include
> #include
> #include
>
> class FooPrivate : public QSharedData {
> public:
> FooPrivate() {
> qDebug() << "FooPrivate default constr";
> };
>
> FooPrivate(const FooPrivate ) : QSharedData(other) {
> qDebug() << "FooPrivate copy constr";
> };
>
> explicit FooPrivate(const QVector ) : v(v) {
> qDebug() << "FooPrivate constr from vector";
> };
>
> ~FooPrivate() {
> qDebug() << "FooPrivate destr";
> };
>
> QVector v;
> };
>
> class Foo {
> public:
> Foo() : d(new FooPrivate) {
> qDebug() << "Foo default constr" << this;
> };
>
> Foo(const Foo ) : d(other.d) {
> qDebug() << "Foo cop
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
Den lör 20 okt. 2018 kl 18:53 skrev Giuseppe D'Angelo via Development
:
>
> Il 20/10/18 14:43, Elvis Stansvik ha scritto:
> > In our application we added a helper like
> >
> > template
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
> >
> > that we use for these cases. It just moves the argument to a const
> > value and returns it. With that we can do for (auto foo :
> > moveToConst(returnsQtContainer()) { ... }.
> >
> > Since it's such a common pattern to want to iterate a returned Qt
> > container, what would you think of having such a helper
> > (qMoveToConst?) in Qt?
>
> Possibly... Note however that such a thing was already proposed for
> qAsConst itself, and shut down to avoid having qAsConst diverge from
> std::as_const (and I approve of not having Qt-specific behaviours). I
> can't find the relevant discussion on the mailing list right now.
>
>
> For reference, std::as_const's original authors had doubts about the
> lifetime issues around this, saying that more investigations were needed:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r0.html#9.0
>
>
> After a LEWG meeting it was reworded like this:
>
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0007r1.html#8.0
>
>
> I'm not entirely sure of what prompted the change for as_const -- if
> just a safety net while waiting for more investigation, or if something
> more profound was raised.
>
>
> I can easily imagine however a scenario where moveToConst() can lead to
> worse code than the current solution.
>
> Current solution:
>
> // GCE may get applied, 0 moves
> const QVector v = getVector();
> for (auto : v) ~~~
>
> vs.
>
> // Always 2 moves
> for (auto : qMoveToConst(getVector()) ~~~
>
>
> And if the type is not even cheap to move (e.g. QVLA, std::array),
> qMoveToConst becomes a really unpleasant surprise.
>
> How about asking LEWG about their reasoning too?
I couldn't find a way to contact them.
In order to try out the unsafe usage you suggested in your other mail,
and also another unsafe usage pointed out in an SO question
(https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
I made the following test program.
The output when running is:
[estan@newton move-to-const-test]$ ./move-to-const-test
without moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627200
Foo begin 0x7fffdb627200
Foo end 0x7fffdb627200
Foo destr 0x7fffdb627200
FooPrivate destr
with moveToConst:
FooPrivate constr from vector
Foo constr with arg 0x7fffdb627208
Foo move constr 0x7fffdb627210
Foo destr 0x7fffdb627208
Foo begin const 0x7fffdb627210
Foo end const 0x7fffdb627210
Foo destr 0x7fffdb627210
FooPrivate destr
[estan@newton move-to-const-test]$
Which just shows it's working as intended.
The two unsafe usages are commented out, because they wouldn't compile (good!).
Note that the version suggested under Further Discussion in rev 0 is
different from our helper, we return std::move(t) while they return t.
With the version from rev 0, your example unsafe usage will compile
(the one from SO still won't).
Elvis
#include
#include
#include
#include
class FooPrivate : public QSharedData {
public:
FooPrivate() {
qDebug() << "FooPrivate default constr";
};
FooPrivate(const FooPrivate ) : QSharedData(other) {
qDebug() << "FooPrivate copy constr";
};
explicit FooPrivate(const QVector ) : v(v) {
qDebug() << "FooPrivate constr from vector";
};
~FooPrivate() {
qDebug() << "FooPrivate destr";
};
QVector v;
};
class Foo {
public:
Foo() : d(new FooPrivate) {
qDebug() << "Foo default constr" << this;
};
Foo(const Foo ) : d(other.d) {
qDebug() << "Foo copy constr" << this;
};
Foo(Foo &) : d(other.d) {
other.d = nullptr;
qDebug() << "Foo move constr" << this;
};
explicit Foo(const QVector ) : d(new FooPrivate(v)) {
qDebug() << "Foo constr with arg" << this;
};
~Foo() {
qDebug() << "Foo destr" << this;
};
Foo =(const Foo ) {
qDebug() << "Foo copy ass op" << this;
d = other.d;
return *this;
};
QVector::iterator begin() {
qDebug() << "Foo begin" << this;
return d->v.begin();
};
QVector::const_iterator begin() const {
qDebug() << "Foo begin const" << this;
return d->v.begin();
};
QVector::const_iterator cbegin() const {
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
(Adding back the mailing list)
Den lör 20 okt. 2018 kl 23:54 skrev Elvis Stansvik :
>
> Den lör 20 okt. 2018 kl 23:50 skrev Giuseppe D'Angelo
> :
> >
> > Il 20/10/18 19:37, Elvis Stansvik ha scritto:
> > > If the C++ wizards considered this but were hesitant, then I think
> > > it's right that Qt is hesitant as well. I hadn't really considered
> > > potential life-time issues, so I guess what we're doing might possibly
> > > be unsafe (?).
> >
> > Probably in the sense that the function you pasted can be applied like this:
> >
> > QVector v;
> > for (auto : qMoveAsConst(v)) ~~~; // compiles with an lvalue!
> > use(v); // unspecified behavior
>
> Ah yes, it may be that the standards folks simply didn't want this
> because of foot-shooting potential like this.
Another potential foot-shooter I found on an SO question
(https://stackoverflow.com/a/39051612/252857):
for (auto const & : as_const(getQString())) // whoops!
{
}
Elvis
>
> >
> >
> > > What's GCE? Some optimization? (Google "c++ gce" didn't give me anything).
> >
> > Guaranteed Copy Elision:
> >
> > > https://en.cppreference.com/w/cpp/language/copy_elision
>
> Thanks!
>
> Elvis
>
> >
> > 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
> >
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
