Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW
> * Support for generating debug info in PDB format How useful is this? Does gdb support this format? If not, then you wouldn't be able to debug stuff, meaning this is not a benefit at all. === I haven't tried this, however, according to what I have read this enables you to build with llvm and debug in visual studio, with all all the benefits of the IDE. I believe there is also an option to include "edit and continue" functionality Don't undervalue this functionality. Scott -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Using '#pragma once' instead of include guards?
My two bits as a user of Qt. Please make sure any exposed headers use the old-school guards and NOT the #pragma once. I don’t care how the internal Qt headers work. However, Ive been burned too many times by the "known issues" of the #pragma once to want to use them. The problem isn’t if the two headers are the same, the problem is it not compiling because of multiple definitions of classes. The main issue I have, is we build a tool with tons of sub libraries and modules, with a pretty poor build environment. We have 800+ developers using it, so any change is done by a committee and takes years ☹ Our Qt gets places in a area everyone gets access to. Ie /usr/local/shared_data/Qt on linux and a mount Q:/Qt/ on windows, but Q: can all be accessed via //SHAREPOINT/shared_data/Qt Under Qt might be Qt5.12.9 and Qt5.15.10, but for this example lets assume its not versioned. Under each version, we then have the compiler sub directories. Meaning win64VC15, linux_x86_64/debug and linux_x86_64/release. The windows disty contains debug and release. What happens, is the compiler does not see Q:/Qt/win64VC15/include as the same path as //SHAREPOINT/shared_data/Qt/ win64VC15/include. This is a known issue. I 100% understand that we should fix out build system so they only access any data in the shared_data mount the same way. However that is simply easier said than done relying on #pragma once just fails for us. Ive seen this issue at a number of companies that do multi-platform development but store their Qt versions on a server. Scott -Original Message- From: Development On Behalf Of Volker Hilsheimer via Development Sent: Monday, October 10, 2022 2:55 AM To: development@qt-project.org Subject: [Development] Using '#pragma once' instead of include guards? Hi, We are using `#pragma once` in a number of examples and tests in the Qt source tree, but I don’t think we have officially endorsed it in favour of explicit include guards. #pragma once is “non-standard but widely supported” [1], with some caveats, e.g. when there are multiple header files with the same name (which each compiler then handles differently, as there is no standard). From what I see, it should in practice be ok to use. But perhaps I’m missing something. Does anything speak against using ‘#pragma once’ in new files? Volker [1] https://en.wikipedia.org/wiki/Pragma_once ___ 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] QNetworkAccessManager
I was able to work out the issues, but I have two recommendations for QNAM 1. If you don't have openssl properly installed, and you attempt to make a https connection, it should give an ssl error * While Ive dealt with this issue a number of times, it continually bites me in the butt 2. If there is a redirect, and your redirection rules are not setup to follow them, an error should be reported in the QNetworkReply * Otherwise, there is zero way to tell that something is wrong if the URL entered by the user gets redirected. Especially when its downloading a file. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Announce] Security advisory: Freetype in Qt
Fully agreed with all your points, but knowing a release is LTS has value even for those without support. I don't see a problem if someone is choosing a the latest LTS version, getting that version since the current version is not a LTS. Scott -Original Message- From: Development On Behalf Of Thiago Macieira Sent: Wednesday, July 27, 2022 2:50 PM To: development@qt-project.org Subject: Re: [Development] [Announce] Security advisory: Freetype in Qt On Wednesday, 27 July 2022 14:28:05 PDT Scott Bloom wrote: > Outside opinion. I know many non-commercial who tend to stick with the > LTS for their projects. The problem is that you're not getting Support, whether Long Term or Short Term or Any Term. Those are stale, a year or more out of date. I agree there's some value in sticking to the 5.15 or 6.2 line because there will eventually be updates, even if late. But we must balance that with the possibility that the choice was misleading. We don't want someone to choose 6.2.4 now only because it's under the "LTS" heading, but not get a single update for the next 10 months. -- 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] [Announce] Security advisory: Freetype in Qt
Outside opinion. I know many non-commercial who tend to stick with the LTS for their projects. Scott -Original Message- From: Development On Behalf Of Thiago Macieira Sent: Wednesday, July 27, 2022 1:23 PM To: development@qt-project.org Subject: Re: [Development] [Announce] Security advisory: Freetype in Qt On Wednesday, 27 July 2022 11:47:20 PDT Giuseppe D'Angelo via Development wrote: > Right now, if one selects "LTS" and "Latest releases" (and *not* > "Archive"), one gets > > * 6.3.1 > * 6.2.4 > * 5.15.2 > > all of which are bugged AFAICT? Non-commercial customers shouldn't even see the option for LTS, since it's not LTS for them. There should only be "Latest releases". Yes, it means that to find Qt 5, you'll need to go look in the Archive. -- 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] QTreeView: vertical bar between columns
Adding a +1 here. Where I have created a “similar” treeview with tableview similarities is when viewing SQL data results. The tree aspect, represents the sorted on column with duplicate data. For instance, say you had a model that was Firstaname, lastname, address, city, state, zipcode and country. A standard address book from CS 101 If you didn’t group, it would look like a table view. If you grouped by city you would get: City1 |- fn1 | ln1| add1 | s1 | z1 | country1 |- fn2 | ln2| add2 | s2 | z2 | country2 |- fn3 | ln3| add3 | s3 | z3 | country3 City2 |- fn1 | ln1| add1 | s1 | z1 | country1 |- fn2 | ln2| add2 | s2 | z2 | country2 |- fn3 | ln3| add3 | s3 | z3 | country3 Etc etc etc My ideal view, basically looked like a tree but when expanded the rows under the parent node simply looked like a tree view. I got it mostly working, however I was never really happy with the look of it, it just looked like a treeview with an attempt to get the rows to look like a table. Just my 2 bits. Scott From: Development On Behalf Of Laszlo Papp Sent: Tuesday, May 17, 2022 9:07 AM To: Konrad Rosenbaum Cc: development@qt-project.org Subject: Re: [Development] QTreeView: vertical bar between columns On Tue, May 17, 2022 at 4:51 PM Laszlo Papp mailto:lp...@kde.org>> wrote: What is required is a widget or mode of a widget that combines both abilities. QTreeView already sort of does that, although badly. Basically, a header makes it look like a table, but it is also a tree. That is why I think the feature request is valid. It should either not have a header or header formatting for this, and then you can argue body formatting is moot, or if it has header and header formatting, then the body formatting ought to be consistent. Just googled an image: https://docs.unity3d.com/uploads/Main/TreeViewAPI-0.png (Unity, fairly common software) They say "multiple columns". As far as I am concerned, a QTreeView is a special QTableView. You can see on the above image that it is column and row based and as a direct consequence, you have "cells" of data. It is just that the tree visual expand into the first column a bit more due to its graphical nature, but it eventually is column-based. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QStandardPaths on windows
On linux, you can overwrite most of the QStandardPaths using the XDG_ environment variables. However, I don't see anyway to do the same for Windows. Windows appears always goes to the systems SHGetKnownFolderPath. In a similar manner to QSettings being able to set a specific directory, I would like to see the same in a OS independent manner. QStandardPaths already has a "setTestMode" which helps, however, if you are running tests on a grid engine, each test having its own specific set of directories for the configuration files can be critical to prevent multiple runs writing to the same directory. My thoughts would be to add to QStandardPahths::setTestModeDirectory( ), so rather than simply adding "qttest" to the system Is there anyway to do what I need today? Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] moc output from non-local tool build
Why wouldn’t they simply have two versions of Qt ( or more) the one they are targeting for desktop, and the previous one they are targeting for android/"remote" -Original Message- From: Development On Behalf Of Joerg Bornemann Sent: Friday, November 5, 2021 2:28 AM To: Volker Hilsheimer Cc: Macieira, Thiago ; development@qt-project.org Subject: Re: [Development] moc output from non-local tool build On 11/5/21 12:06 AM, Volker Hilsheimer wrote: > Does anyone other than developers of Qt (and for us this could be a real time > saver!) really need and benefit from this? I’d rather not want to ask our > support team to support customers and users with a colorful blend of moc and > library versions. This here describes a use case from a packager perspective: https://lists.qt-project.org/pipermail/development/2021-September/041746.html 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] Renamed (again): Qt licensing shenanigans (again)
The sad part in all this.. the amount of negative discussion about Qt, when TQtC could fix this easily, simply maintain LTS at the opensource license. If they want patch releases in general not to be open source fixes, fine. Ie 6.1 is opensource, 6.1.1 is not.. But when a LTS is released, that is major build and all its patches are open source . It solves their problem of spending too many resources on unpaid for code, and the community that supports them, doesn’t get left out in the cold on a major version their projects are sticking to. Maybe they follow the PT barnum any press is good press a little to far? -Original Message- From: Development On Behalf Of Jason H Sent: Friday, May 21, 2021 11:20 To: Rui Oliveira Cc: development@qt-project.org Subject: Re: [Development] Renamed (again): Qt licensing shenanigans (again) > > I agree with Jason: Doing the "no LTS for FOSS" at the moment of the > 5.15->6.0 change was really a foul play, imho. I'm currently attributing it to a license decision that for any other release (say if there was a 5.16) would be fine, but in reality was temporally coupled to the release of 6.0, and what 6.0 composed, which was an unusual and separate decision. And these decisions could have been made separately by different people and not realize the implications of the two combined until it was pointed out. It's a mistake that can be easily rectified. But what happens next is going to show the true character of the Qt Corporation. If the decision was made intentionally, or even so but isn't rectified, then that's going to affect those open source users who don't legally need a license, don't want or need Qt 6, but just need access to patches to keep users happy. I can't really see that as s motivation for a commercial license money grab, because in theory, by 6.2 things will be back to normal. Starving open source license users of patch level changes to get them to convert to commercial for what, a year? Doesn't make sense so me, so I'm not attributing it to malice. What I'd like to see is: - Open Source LTS patches restored until 6.x is at parity. - An agreement that never again will Qt have a Major version release that isn't in parity with the previous feature release (meaning dropped feature have to be dropped Before the major release for at least one version) Ultimately I think this was a learning experience. ___ 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] Raising minimum CMake version to 3.16 for Qt6
One thing to consider here. Visual Studio is now shipping CMake, its also getting updated for patches of a given version of VS, and is not the same from VS 2019 or VS 2017 I know of a couple of teams that are using the VS version of CMake on windows to alleviate the need for another install/setup app Scott -Original Message- From: Development On Behalf Of Thiago Macieira Sent: Wednesday, May 5, 2021 14:28 To: development@qt-project.org Subject: Re: [Development] Raising minimum CMake version to 3.16 for Qt6 On Wednesday, 5 May 2021 13:52:52 PDT Kyle Edwards via Development wrote: > CMake upstream here. We recommend always using the very latest patch > version of CMake, since it is backwards compatible and can > (theoretically, bugs notwithstanding) build CMake projects written for > any earlier version of CMake. You are correct that upgrading CMake is > generally easy, though it admittedly may not be feasible if you insist > on sticking with the version provided by the distro (though we do > provide Ubuntu .deb builds of the latest version.) Hello Kyle Always using the latest is a good recommendation. The question is the minimum we can reasonably require the users to have installed. Upgrading is easy, but it's not as way as "$PKGCOMMAND install cmake" (where PKGCOMMAND is apt-get, zypper, dnf, yum, opkg, whatever), so requiring a version higher than the one users are likely to have creates a barrier for entry. -- 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] Spam: Re: Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Monday, 4 January 2021 20:32:27 -03 Scott Bloom wrote: > The funny thing, I remember at a Qt Dev Days when Qt 5 was about a > year away. The "we will never do a Qt 3-4 type major version change > again" was said time and time again. > > Where functionality was missing, and no one was happy with Qt 4.0 > except the people who got to say "4.0" released Both statements are true but their combination is misleading. Yes, Qt developers promised never to do a Qt 3 to 4 transition again. Yes, Qt 4.0 was missing some functionality from Qt 3, which made 4.0 an impossible target, as well as having brand new functionality that was hadn't yet matured (itemviews). But the first statement is taken out of context and thus makes it sound that the second statement is the reason for the first. It is not. The reason why we didn't want a 4.0 transition is because of the massive amount of code changes that were required for code bases to transition to 4.0. That is not the case here, as most codebases can compile with 6.x with limited porting effort. It's also true that some of them can't be ported to 6.0, but once 6.1 and 6.2 come along, they will be. The concern raised by people who can't move forward and aren't getting bug fixes either is a valid one, though. -- I remember the discussion in terms of "never again having a 3-4" type transition, to be two fold. First it was definitely the level of changes to the API, no doubt. But it was also, releasing a x.0 with missing functionality that would prevent migration. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Spam: Re: Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
-Original Message- From: Development On Behalf Of Kevin Kofler via Development Sent: Monday, January 4, 2021 3:16 PM To: development@qt-project.org Subject: Re: [Development] Spam: Re: Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January Oswald Buddenhagen wrote: > one can always say that, but there is a balance to be struck, and it > is > *very* obvious that 6.1 will be what and when 6.0 should have been. > whether BC is broken doesn't even matter at that point, because no-one > sane who depends on binary compat will touch 6.0 with a ten-foot pole > now. also, i've been watching qtcore dev closely, and _no-one_ behaved > as if a release was imminent, for good reason - it simply wasn't ready > yet, everything still being in flux. Basically, Qt is making the same mistake with 6.0 that KDE made with 4.0: releasing a .0 that even the developers do not recommend actually depending on, just for the sake of releasing something. Kevin Kofler The funny thing, I remember at a Qt Dev Days when Qt 5 was about a year away. The "we will never do a Qt 3-4 type major version change again" was said time and time again. Where functionality was missing, and no one was happy with Qt 4.0 except the people who got to say "4.0" released Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Problems using Qt 5.12/5.15
So I wanted bring up some issues the company I work for is having using 5.12 and 5.15. Our customers (IC development companies large and small) are extremely slow to move their OS. We had customers who are still using CentOS 6.X . These customers, often will NOT move OS’s once a project has started. If a chip is an 6-8 year project, they will often start with a 1-2 year old version of the OS (OS version migration can take 6 months or more, so they don’t change quickly even outside project constraints), and stick with it for that 6-8 years. Unfortunately, Qt has required newer and newer versions of the OSes, where we have 2 choices. We start with an OS version our customers are willing to move to (CentOS 7.0) + we build all linux library dependencies ourselves, or we stick with Qt 5.11.x. They got things working for 5.12 and 5.15, with a bunch of src (more in 5.15 obviously) based library builds. But had numerous Squish regression failures, which they are still investigating. We are hoping to get these resolved, however the team, is close to simply saying “5.11 for life”. That the lack of bug fixes/security updates will have to do, but we simply don’t have enough customers willing to move to newer versions of CentOS, but more importantly other big customers will not move, and we have to support them. I have been a Qt commercial licensee on and off (depending on the company I work for) for almost 20 years now. And I can not remember the lack of consistency between minor builds of Qt and the supported OSes. I understand the want to move to newer compilers, and somethings simply require newer features of X (high DPI support) libraries to properly support. But these decisions are really hurting Qt’s reputation in the commercial world. I’m hearing this from friends at other companies in the same industry (and similar industries). While Qt 5 is 8 years old, and the changes in C++ in that 8 years have been pretty dramatic, especially when compared to the C++ changes over Qt 4’s lifetime. Im concerned about Qt 6 taking this same view of forcing a new OS to move to later versions. I would love to see, that we treat the OS build requirements in a similar fashion to the ABI requirements are put forth. That “Minor releases are backwards binary and source compatible”. Or possibly, a push for LTS releases that are based on an OS to be supported “For the life of the major version”, meaning if you are using 5.9LTS, it will be supported as a LTS throughout 5.X since 5.12 had a significant number of OS dependency changes. And since 5.15 had a new set of OS requirements, 5.12 would also be LTS for as long as any Qt 5 is supported. A third option, is to make sure even if it prevents functionality from being supported, is to “ifdef” new compiler/OS changes out if necessary. Yes, this will be a test nightmare, but isn’t that what the commercial licenses are paying for 😊 ? I remember a number of don’t use this if not configured issues, where it wasn’t fully “not used” and still had a statically bound dependency on a shared library, but it’s a been a number of years and I cant remember the exact issue. I’m not sure what’s the best audience to bring this up, but just had a conversation with the bosses at work, and no one is happy with Qt right now because of this issue. And the “stay on 5.11” is just a horrible option but it wouldn’t surprise me if that is the choice made. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
> On 27 Aug 2020, at 08:04, Giuseppe D'Angelo via Development > wrote: > > Hi, > > Il 27/08/20 02:46, Thiago Macieira ha scritto: >> A QListView of 2 billion lines with where each line is a QString one >> to 7 characters in length would be 2G * (24 + 32) = 96 GB of memory use. >> QListWidget's overhead is much worse. > > This isn't accurate; QListView (with the default delegate) doesn't cache > data, and only fetches and shows what's visible in its viewport. So the > actual consumption is pretty much constant no matter how big is the > underlying model. Correct. But the argument for QTextDocument still holds. If you have such huge files, I believe you want to load them using some custom editing component that mmaps the file and only loads the relevant parts on the fly. QTextDocument allows for rich text editing and requires to hold the content in memory in a QString because of that. QTextDocument should be able to handle very large regular documents this without larger issues. Just as a comparison: All Harry Potter books together are around 1.1M words, ie. around 10M characters. Loading that (or even a 10 times larger document) into a QTextDocument should work without issues. But a 5G set of machine generated data? I would believe you want a special class handling that and loading data on the fly, so you have some memory left for the rest of your system. Having said that, I don’t mind changing our API to use qsizetype for QTextDocument, I just don’t believe you will find the class to be very snappy and usable with such large documents. The piece table itself should be able to handle it if you have enough RAM, but the default layout engine probably can’t (you could try using your own custom layout though). Cheers, Lars ___ To be clear, I am not expecting a QTextDocument as is to perform well under these loads (especially the 5gb files) in its normal usage form. However, i can see someone extending qtextdocument to handle large files using one of many strategies. Thanks Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
From: Development On Behalf Of Ville
Voutilainen
Sent: Wednesday, August 26, 2020 12:08 AM
To: Lars Knoll
Cc: Qt development mailing list
Subject: Re: [Development] qsizetype and classes working with QStrings or QList
On Wed, 26 Aug 2020 at 09:39, Lars Knoll wrote:
> > QtGui:
> > * QTextCursor
> > * QTextDocument (find offset, character{At,Count})
> > * QTextLayout
> > * QValidator and subclasses (validate offset)
>
> These here are questionable. Editing a text file with more than 2G
> characters? Sounds unlikely.
Disagree here. There is good reason many in my industry (Electronic design
automation) use the Scintilla editor widget inside Qt apps. Specifically to
handle extremely large, in both line count and column count, files.
Many of the text files we work with, are generated library definitions for
silicon definitions. A 5+ gb file is not uncommon. Or files with a truth
table definition with 5000-1000 columns. I kid you not.
Its one thing to not handle it, and say "too big to open" its another to
attempt to and crash because the internal integers cant handle it.
Scintilla handles these massive files relatively easily.
Scott
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype and classes working with QStrings or QList
Or
for( auto ii = 0; ii < std::vector.size(); ++ii )
{
}
since there is no suffix for "size_t" and the size of size_t will depend on 64
vs 32 bits whats the best way to AAA the index iterator?
Scott
-Original Message-
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
André Pönitz
Sent: Tuesday, August 25, 2020 12:15
To: Mathias Hasselmann
Cc: development@qt-project.org
Subject: Re: [Development] qsizetype and classes working with QStrings or QList
On Mon, Aug 24, 2020 at 09:46:43AM +0200, Mathias Hasselmann wrote:
>C++ also has a solution for that problem: [1]
>
> https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-al
> ways-auto/
AAA is a non-solution from the ivory tower.
It's a pain for human reviewers and tools operating on less then a full
translation unit.
(Almost) real-world example:
for (auto i = foo.guess_stuff(); --i >= 0; )
do_something(i);
Good? Bad?
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] What project are Qt+CMake bugs part of
Thanks! -Original Message- From: Kevin Funk Sent: Monday, March 9, 2020 2:56 PM To: development@qt-project.org Cc: Scott Bloom ; Development@qt-project.org Subject: Re: [Development] What project are Qt+CMake bugs part of On Monday, 9 March 2020 22:15:02 CET Scott Bloom wrote: > I found a bug in Qt5CoreMacros.cmake where on windows in a path with the > QT5_MAKE_OUTPUT_FILE macro constructs invalid file names. > > What project should this be filed against in JIRA? Heya, That should be targeted at the Qt product, "Build System" component. And add the "cmake" label. That works best. Regards, Kevin > Scott -- Kevin Funk | kevin.f...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] What project are Qt+CMake bugs part of
I found a bug in Qt5CoreMacros.cmake where on windows in a path with the QT5_MAKE_OUTPUT_FILE macro constructs invalid file names. What project should this be filed against in JIRA? Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] The future of smart pointers in Qt API
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of André Pönitz Sent: Monday, February 3, 2020 3:50 PM To: Giuseppe D'Angelo Cc: development@qt-project.org Subject: Re: [Development] The future of smart pointers in Qt API On Mon, Feb 03, 2020 at 10:25:40PM +0100, Giuseppe D'Angelo via Development wrote: > I've asked "what's wrong with the C++ smart pointers" a dozen times > and never received a satisfactory answer. Did you? I am - to some degree truly - afraid I didn't notice. Answer would have been easy: They solve problems that should not occur on a large scale in a sensible setup. To start with: I was not much in favour of std::auto_ptr when it was standardized. People started hyping it, best thing since sliced bread. Sprinkle your code base with it or you are doomed. Well. Fast forward twenty years. Case settled. boost::shared_ptr, ..., std::unique_ptr: Same story, just not finished: An actual "need" for a shared pointer is typically a sign that ownership is not clear at all: "Here's a thing, it doesn't really belong anywhere, so let's copy it around, last one switches off the light". Fixed by making ownership clear. Also solves the problem of needing to copy some stuff because it's not copied, just referenced. And sure, there *are* situation where shared pointers are useful, and it's of course fine to use them if there's such reason. An actual "need" for a unique pointer is typically a sign that things are created, passed around until they end up somwhere, for a long time so that people get unsure about ownership or have developed an irrational fear of naked pointers. Fixed by not having the 'factory' create the object and pass the object around, but by passing the factory around (by 'reference') and letting the receiver create the object. Additional advantage: creation can take input both from the factory setup (say, lambda capture) and the receiver side, saving potentially a lot of state. And it's of course fine to use unique pointers if that's not the reason. E.g. to delete dynamic stuff in case of early returns. I.e. a kind of, surprise, "scoped" pointer. That people coming from Java exhibit a high affinity to shared pointers is not exactly news in this millenium. A bit more amusing is that some proponents of "modern" C++ demand using unique pointers, when actually more direct, less boiler-plate requiring tools (lambdas...) were standardized at the same time. Andre' --- To be fair, while I 100% agree with the reasons given, you are not listing one of the (only???) reasons, that a smart pointer shared or unique, are truly necessary. When you are working with the possibility that the lifetime of the pointer, might not be exception safe. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Re-reading Mark's initial post. One thing, that I had requested from the trolls almost 20 years ago.. which Ill put out there again, is a "non-developer" license that allows people who don’t develop using Qt, but the product they work on uses it somewhere, and thus its required to build. For a large company, (or even a small company) a license that was cheaper than full license (10% or so) would make deploying Qt on large projects a much easier pill to swallow. I had worked with (in my consultant days) many a company, that loved the Qt containers over STL, but refused to allow them into the core code. They split the tool between core and UI, and Qt was only allowed in the UI, no public APIs at all. Simply because they didn’t want to have to pay for a license for someone to iterate over a container, or to work with a QString Scott -Original Message- From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Mark De Wit Sent: Friday, January 31, 2020 1:06 AM To: Qt development mailing list Subject: Re: [Development] Changes to Qt offering I'm guessing the Qt installer has now been updated in line with the licensing changes? I've just had the first developer in our team come up to me to complain that they can't install Qt My usual response of click the skip button appears to no longer work. And no, I'm not going to ask 45 developers in this company to create Qt accounts, that's a non-starter... Mark > -Original Message- > From: Development On Behalf Of > Mark De Wit > Sent: 28 January 2020 11:38 > To: Lars Knoll ; Qt development mailing list > > Subject: Re: [Development] Changes to Qt offering > > I've been working really hard over the past few years to get Qt used > more within my organisation. However, mandating that our 45 > developers all register Qt accounts is a complete non-starter, especially if > only 2 or 3 of them actually > work with UI on a day-to-day basis. For the rest of them, Qt is a tool > that's > required to build the software, the same as every other 3rd party > module that they're forced to install & endure. > > This may well be a show-stopper for future adoption of Qt for me. (on > top of Qt Widget issues/limitations that turn into blocking issues > which isn't helping my cause either...) > > Mark > > -Original Message- > From: Development On Behalf Of > Lars Knoll > Sent: 27 January 2020 14:35 > To: Qt development mailing list > Subject: [Development] Changes to Qt offering > > Hi all, > > The Qt Company has done some adjustments to the Qt will be offered in > the future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 . > > The change consists of three parts. > > One is a change in policy regarding the LTS releases, where the LTS > part of a release is in the future going to be restricted to > commercial customers. All bug fixes will (as agreed on the Qt > Contributor Summit) go into dev first. Backporting bug fixes is > something that the Qt Company will take care of for these LTS > branches. We’ve seen over the past that LTS support is something > mainly required by large companies, and should hopefully help us get some > more commercial support for developing Qt further. > > The second change is that a Qt Account will be in the future required > for binary packages. Source code will continue to be available as > currently. This will simplify distribution and integration with the > Marketplace. In addition, we want open source users to contribute to > Qt or the Qt ecosystem. Doing so is only possible with a valid Qt > Account (Jira, code review and the forums all require a Qt Account). > > The third change is that The Qt Company will in the future also offer > a lower priced product for small businesses. That small business > product is btw not limited to mobile like the one Digia had some years > ago, but covers all of Qt for Device Creation. > > None of these changes should affect how Qt is being developed. There > won’t be any changes to Open Governance or the open development model. > > Best regards, > 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 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Rationalizing qApp and qGuiApp
From: Development [mailto:development-boun...@qt-project.org] On Behalf Of Elvis Stansvik Sent: Saturday, January 18, 2020 4:33 AM To: Sze Howe Koh Cc: Qt development mailing list Subject: 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 = From a user's perspective (much more than "what is the best development course of action"), I would prefer the following D) Get rid of qApp altogether, use static QCoreApplication::app() methods (or QGuiAPplication etc etc), where if you are NOT running it as the called for ::app from the correct class, it returns nullptr. Otherwise it returns the correct type. Unless in compatibility mode, qApp is gone, but if in compatibility mode, the documentation is updated to show the possibility of different types Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
On Saturday, 15 June 2019 12:22:34 PDT Bogdan Vatra via Development wrote: > > Why must they be built in one go? Why can't they be separate builds > > stitched together? Or even completely separate builds as on Linux > > and all the other Unix? > > Because qmake can build them in one go and last but not least is > very convenient. Because a "new" buildsystem should do more than the > existing one, not less :). That only means a "nice to have", not "must have", feature. Sure it's convenient, but how often do you really need both and can't simply build twice? My Windows build is slow enough as is[*], I'd probably welcome the separation. Note: with qmake's NMake generator, you *can* type "make debug" and it'll only compile the debug sub-targets. That doesn't work with the Unix Makefile one, so it won't work for macOS. [* because I build on my IT-provided dual-core laptop, which comes loaded with IT-provided virus scanners, data-loss prevention tools, etc.] As a big CMake fan, I would love to see the whole QMake -> CMake conversion go forward. To this point, and this point only, the following is what my company uses to build debug and release on windows cmake --build . --config Debug --config RelWithDebInfo --target ALL_BUILD For linux, we don’t have a method... Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QList for Qt 6
I'm a bit late to this game, but ... > I don’t see why you’d want to remove the switch for Qt 6. > It would be a porting help for application developers. Application developers will not build their own Qt, but rely on the QList with the switch their Qt and Qt-using 3rd party libraries are built with. And how does it work if different 3rdparty qt libraries requires the switch differently? /Sune - Qt, KDE and Debian guy at night. Qt & c++ freelancer by day. ___ I can tell you from m Qt3 -> Qt4 transition, with a similar switch (to enable Qt3 functions that were killed off) We did the following.. Our release, was built with the Qt3to4 library and switches enabled. However, our developer builds had the switch turned off, so we didn’t introduce new code using the old API. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
Fair enough.. But I will say.. all too often.. theory becomes practice -- Please note that nobody said «we are removing Qt containers in Qt6». At least, I don’t have that information. The discussion is mostly about a *theoretical* case when the implementation of a *theoretical* method in a *theoretical* class may *theoretically* change and how far we should go to support that *theoretical* change. Or should not =) It’s been said that Qt6 will be mostly source-compatible with Qt5. PS: there’s been a discussion about killing QList but it is not clear how to do so without breaking half of the world (i.e. no final decision so far) and this discussion started long time ago, so you've had (and still have plenty of) time to revisit usages of QList in your codebase and replace it with more appropriate container. > 17 мая 2019 г., в 19:47, Scott Bloom написал(а): > > Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt > Containers", as well as code that does the autoconversion from Qt to STL, so > developer code builds when the flag is on. > > Scott > ___ > 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
On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote: > Thiago, you partially implying that BC is still needed but with > technologies like flatpak or snappy this will maybe not common use > case anymore. They provide even behaviour compatibility if you stay with the > same runtime. > Something which is not provided by binary compability. I personally > think if the behaviour is changed it should not even compile anymore > so you can fix it easily. Some level of compatibility is of course required, unless you're proposing we provide a certain level of bugfixing for ALL releases for a number of years. That is, if 6.2 isn't source-compatible with 6.1, then 6.1 needs to be supported for 3+ years with bugfixes for code that was ported to 6.1 but hasn't been ported further to 6.2. If we're still keeping source compatibility but not binary, the problem is not as big as above. But it still exists if you're not in a position to recompile all modules (think third party's component). -- Im just going to throw out my 2 bits on this Please don’t underestimate (and Im not hearing Thiago say this) the pain, of breaking source compatibility. Even on Major (5->6) version changes. Qt lost a lot of momentum, but eventually gained it back, in the 3-4 transition. And it was more than just "the code didn’t compile" it was also, lost functionality that was take from 3, a hack added in 4.1 (missing in 4.0 IIRC) and then fully replaced in 4.4.. And Im talking about the Graphics Scene/View... We have a similar issue, even if it has been 2-3 years already, with the change in web viewer... I know of more than one project, including my product, that is stuck on an old version of Qt, simply because the new web view, is missing some functionality. And building the old browser classes is a less than "wonderful" solution. When the Qt team, decides to make these changes, it hurts a lot of developers, who have to justify to their company, I need to spend X number of months figuring out a solution, to replicate code that was already working fine... From a utopic point of view, Id be fine with, if every Qt container, and class that has been "mostly" implemented in STL, or the native language was thrown out.. But as I tell my employees, just because its in the language now, doesn’t mean we should go through our 2.5 million lines of code, and re-write every one to use modern C++... To replace out every container, that works today? And in the process, break probably billions of lines of existing Qt code, which would have to be re-written using the new containers??? Please don’t Even for 6.0... Some form of transition would be great. Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt Containers", as well as code that does the autoconversion from Qt to STL, so developer code builds when the flag is on. Scott ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] unique_ptr and Qt, Take 2
On Friday, 3 May 2019 10:22:20 PDT Daniel Teske wrote:
> std::unique_ptr rightButton =
> std::make_unique("RIGHT");
> layout->addWidget(std::move(rightButton));
The problem in this particular example is that once you've added the widget,
the rightButton smart pointer no longer has a pointer. You can't continue to
set up your push button. In most cases, this is just a matter of moving the set
up before the addition / reparenting, or using the other idiom where the object
is never in a smart pointer in the first place.
So this begs the question of whether std::unique_ptr is the best smart pointer
for this scenario. Would it make sense to create one that understands parent-
child relationship?
--
I just survived a painful problem dealing with this exact issue.
Long story short, a child widget, had to survive the parent, it was created
correctly with parent being null, but in adding it to a layout, changed that of
course.
The solution was to set the parent back to null, when the "non-layout" parent's
destructor was called.
A Qt Smart Pointer, that allowed "unique" but another that also allowed for
"Shared" depending on the case, that took into account the Qt parent child
relationship, would be a great addition
Scott
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 buildsystem support requirements
-Original Message- From: Development On Behalf Of Thiago Macieira Sent: Tuesday, July 31, 2018 11:41 To: development@qt-project.org Subject: Re: [Development] Qt 6 buildsystem support requirements On Tuesday, 31 July 2018 11:15:50 PDT Ville Voutilainen wrote: > This provoked a thought in me, a way to make qbs worth all its effort: > make debugging > a build so staggeringly ridiculously good that it becomes attractive > to use it. I don't know what debugging builds done with python-based > build systems is like, but debugging make-based builds is rather > horrible. Aye. Debugging qmake builds are actually pretty easy, if you know -d and -d -d exist. You can easily follow the decisions it made. You'll get to a few corner cases where things that should be lists aren't or vice-versa, or quirks of the language where $$ is suppressed, etc. But most of the time you don't need that. (I'm not talking about debugging the tool itself) Debugging cmake builds aren't that easy. It writes a lot of logs, but sometimes magic happens. If the magic doesn't go your way, you're lost. Compared to qmake, the barrier of where the magic happens is lower, meaning that it happens more often than it should. Debugging Makefiles are a PITA. THAT was libvpx's buildsystem and that is what prompted me to post this thread. Debugging make using the -d option is a last resort and is still not completely sufficient, since it shows process starts but not the variable evaluations. Finally, debugging autoconf is actually not that difficult either. Because it's a shell script, there are tons of techniques you can use. And it creates a fairly comprehensive log file, similar to qmake's -d output. Debugging automake is a different story, but it's a very limited tool. And don't try to debug libtool (you can live an entire lifetime using it and never debug it). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center === Just a note.. for CMake, I find the -debug-output -trace and -trace-expand as useful as the -d and -d -d . One other thing I use all the time for dependency analysis, is the -graphviz switch. Scott ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
> I cant even get my developers to agree the emacs takes to many fingers, and > VI(m) is the only editor they need > > Let alone, where the brackets and spaces belong > > Let alone, if statements on the same line as the conditional > > The problem ive seen, is while you may LOVE the curly brackts on the > same line, you will never convince me... 😊 The problem I have with this oft-recurring formatting discussion is that it's advertised as a big benefit, sometimes downplaying its cost. It doesn't help me all that much to have familiar formatting and naming in a translation unit; that consistency is dwarfed by the effort needed to understand the logical design of the code to reasonable modify/refactor/maintain it. I think it's reasonable and harmless to clang-format new changes; I continue to be unconvinced of the cost/benefit ratio of reformatting all of our existing code. Agreed. I have moved to the "over all policy" of don’t check in crap code... 😊 And run your styler as you need to, on code you are working on, if it helps you understand it. And "try" to avoid checking in "format only changes" Scott ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need Let alone, where the brackets and spaces belong Let alone, if statements on the same line as the conditional The problem ive seen, is while you may LOVE the curly brackts on the same line, you will never convince me... 😊 -Original Message- From: Development On Behalf Of Philippe Sent: Friday, June 22, 2018 09:12 To: development@qt-project.org Subject: Re: [Development] clang-format > I usually come to the conclusion, code in the style you want, unless > it's a bad format. "bad format" is subjective and the use of clang-format precisely bypasses subjectivity. > But IMO, wholesale "format changes" have zero value to the customer, > so any pain associated with them, should be weighed against the time > and effort necessary to implement a format change that is being taken > away from customer oriented development. I have a different POV: everything that eases the developer's work, means spared development time, hence more productivity, hence benefits to customers at the end. Not having to take care of code-formatting, thanks to clang-format, eases programming. And looking at someone else code with a familiar format, gives the feeling "I am home" (provided some naming guideline is respected). Philippe On Fri, 22 Jun 2018 15:34:09 + Scott Bloom wrote: > Fair enough.. It just seems that this thread has fundamentally become a > religious issue over format, and when it should be forced on people... > > I fight this all the time in my organization... I usually come to the > conclusion, code in the style you want, unless it's a bad format. And like > pornography, I cant define it but I know it when I see it... > > But IMO, wholesale "format changes" have zero value to the customer, so any > pain associated with them, should be weighed against the time and effort > necessary to implement a format change that is being taken away from customer > oriented development. > > Scott > > -Original Message- > From: Development > On Behalf Of > Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: development@qt-project.org > Subject: Re: [Development] clang-format > > On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > > In a series of wrapper scripts, essentially, everything checked in > > was converted to the check in format. However each developer had > > their own format . And on checkout, the code would be compare to it. > > > > On "Diff" analysis of two reversions, you had to see the diff based > > on the checked in format. > > > > It really made things, that much simpler... and we never heard > > people bitch and moan about where the curley brackets belong > > Git has such a functionality, it's called the clean/smudge filters. See man > gitattributes for more information. > > But that still means the code you see is subject to the smudge filter's > whims. > We've concluded that it doesn't always do the right thing. > > And besides, there's something new that didn't exist in the old days: code > reviews. Gerrit has no such functionality and in any case, reviewers need to > agree between themselves on what they ar reviewing. > > -- > 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 ___ 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] clang-format
Fair enough.. It just seems that this thread has fundamentally become a religious issue over format, and when it should be forced on people... I fight this all the time in my organization... I usually come to the conclusion, code in the style you want, unless it's a bad format. And like pornography, I cant define it but I know it when I see it... But IMO, wholesale "format changes" have zero value to the customer, so any pain associated with them, should be weighed against the time and effort necessary to implement a format change that is being taken away from customer oriented development. Scott -Original Message- From: Development On Behalf Of Thiago Macieira Sent: Friday, June 22, 2018 08:26 To: development@qt-project.org Subject: Re: [Development] clang-format On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > In a series of wrapper scripts, essentially, everything checked in was > converted to the check in format. However each developer had their > own format . And on checkout, the code would be compare to it. > > On "Diff" analysis of two reversions, you had to see the diff based on > the checked in format. > > It really made things, that much simpler... and we never heard people > bitch and moan about where the curley brackets belong Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information. But that still means the code you see is subject to the smudge filter's whims. We've concluded that it doesn't always do the right thing. And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing. -- 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] clang-format
Im going to throw out my 2 bits .. Im not an active Qt developer, so take it
for what its worth..
Back in the old days (read CVS, pre git, pre svn, pre perforce) we had created
the ability to have the "Checked in format" vs the "Developer format"
In a series of wrapper scripts, essentially, everything checked in was
converted to the check in format. However each developer had their own format
. And on checkout, the code would be compare to it.
On "Diff" analysis of two reversions, you had to see the diff based on the
checked in format.
It really made things, that much simpler... and we never heard people bitch and
moan about where the curley brackets belong
-Original Message-
From: Development On
Behalf Of Frederik Gladhorn
Sent: Friday, June 22, 2018 00:47
To: development@qt-project.org
Subject: Re: [Development] clang-format
OK, so for now, my take-away from this thread is that we should simply create
nice commit-hooks that help everyone along. As a next step we can also enhance
the sanity bot with friendly messages.
I ran clang-format a few times over different parts of the code-base and I
agree that it sometimes ends up with stuff looking worse. Either use the opt
out for those parts or live with it.
Not having to debate the format again and again is a big win in my opinion.
Let's move the _clang-format file from qtrepotools to qt5.git:
https://codereview.qt-project.org/#/c/233051/
https://codereview.qt-project.org/#/c/233050/
Cheers,
Frederik
On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote:
> Hi all,
>
> as part of the closing ceremony of this year's Qt Contributors' Summit
> we agreed to start using clang-format, to have fewer discussions
> around coding style and rather focus on the actual code.
>
> I have not yet thought about all angles, how to best implement this,
> here are some notes:
>
> We have a clang-format file in qtrepotools. You can use it today,
> simply make sure it's in any parent directory of the files you are
> editing. I'd actually propose simply moving this into the root directory of
> qt5.git.
> https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
>
> If you want to clean one file:
> clang-format -i myfile.cpp/h
>
> To clean a commit (only modifies the working tree):
> git clang-format
>
>
> Getting clang-format seems easy enough:
> On macOS: brew install clang-format
> Linux: install clang-format
> Windows: it comes with normal clang
>
> Then there is the tooling/workflow perspective. Creator and other IDEs
> have support (you may need to enable the beautifier plugin in about plugins).
> I imagine we add this to the sanity bot ("git clang-format --diff -q"
> should return empty, otherwise post a message).
>
> Local hooks are basically the same, any ideas how to best set up the
> git hooks appreciated :)
>
> And then there is the big question when we run it once over the entire
> codebase.
>
> Cheers,
> Frederik
>
>
>
> ___
> 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
