Re: [Development] QProperty and library coding guide

On 23/07/20 22:54, Thiago Macieira wrote: On Thursday, 23 July 2020 12:34:06 PDT Simon Hausmann wrote: I think the primary environment where a transition and resulting BC breakage would be annoying is the Linux system environment with gcc. This is where Olivier’s solution is quite elegant IMO.

Re: [Development] QProperty and library coding guide

On 17/07/20 19:00, Thiago Macieira wrote: On Friday, 17 July 2020 09:34:54 PDT Lars Knoll wrote: I'll just post this and let you ponder the consequences of this choice for Linux: https://godbolt.org/z/nhex5x Yes, that’s why we need to encode that into a static_assert(). But the support it

Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT

On 11/06/20 11:11, Edward Welbourne wrote: Hi all, On [0] there is discussion of deprecating these two macros, or even outright removing them in Qt 6. I see the sense of deprecation, on dev at least, since we expect C++17, in which static_assert() does the whole job. Since they're macros, I

Re: [Development] Stepping down as moc maintainer.

will take over the job of maintaining it. Cheers, Lars On 4 May 2020, at 07:34, Olivier Goffart wrote: Hi, Officially, I am the maintainer of moc. However, in practice, I have not been doing much development on it in the last years. I even have conflict of interest since I maintain "comp

[Development] Stepping down as moc maintainer.

Hi, Officially, I am the maintainer of moc. However, in practice, I have not been doing much development on it in the last years. I even have conflict of interest since I maintain "competing" project[1]. I am not keeping up with my gerrit folder (not only moc though), and I don't see the time

Re: [Development] New Qt vulnerabilities

On 30/01/20 17:16, Lisandro Damián Nicanor Pérez Meyer wrote: Hi Thiago! On Wed, 29 Jan 2020 at 22:19, Thiago Macieira wrote: [snip] Issue 2) CVE-2020-0570 Score: 7.3 (High) - CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H/E:F/RL:O/RC:C * Vendor: Qt Project * Product: Qt * Versions affected:

Re: [Development] New Qt vulnerabilities

On 30/01/20 17:12, Thiago Macieira wrote: On Thursday, 30 January 2020 03:05:50 PST Olivier Goffart wrote: $PWD is not the same as the binary dir (QCoreApplication::applicationDirPath) The later is still searched while looking for plugin. (so that covers the case where plugin is in the folder

Re: [Development] New Qt vulnerabilities

On 30/01/20 11:30, Dominik Holland wrote: Doesn't the first fix break the standard way of deploying plugins on windows ? I'm also not sure why this shouldn't affect windows ? Most applications using Qt on windows just deploy their plugins in the folder next to the binary. Same like all dlls

Re: [Development] Metatype system in Qt6

On 25/01/20 17:31, Stottlemyer, Brett (B.S.) wrote: Apologies for reviving an old thread, but this just came up in a code review (https://codereview.qt-project.org/c/qt/qtremoteobjects/+/287828 if anyone is curious). On 12/5/19, 11:56 AM, "Development on behalf of Olivier Goffart&quo

Re: [Development] How do you build dev/qt6?

On 25/01/20 15:26, Stottlemyer, Brett (B.S.) wrote: Building HEAD for qtbase, qtdeclarative and qtremoteobjects is failing to compile. At this point in time, I’m getting an error in building qtdeclarative: /code/qt6/qtdeclarative/src/quick/scenegraph/util/qsgplaintexture.cpp:50:11: fatal

Re: [Development] Are we already allowed to use C++17 in dev?

On 2020-01-13 19:38, Thiago Macieira wrote: On Sunday, 12 January 2020 23:18:40 PST Olivier Goffart wrote: Well it might, since this patch forces the use of C++17 everywhere, regardless of the configure test. which i believe is the problem. There's a reason we wrote the test like

Re: [Development] Are we already allowed to use C++17 in dev?

On 2020-01-08 23:50, Thiago Macieira wrote: On Wednesday, 8 January 2020 14:12:17 PST Olivier Goffart wrote: On 08.01.20 18:21, Thiago Macieira wrote: qcc doesn't seem to support it. kernel/qcoreapplication.cpp: In static member function 'static void Not yet: - qmake isn't build

Re: [Development] Are we already allowed to use C++17 in dev?

On 08.01.20 18:21, Thiago Macieira wrote: qcc doesn't seem to support it. kernel/qcoreapplication.cpp: In static member function 'static void QCoreApplicationPrivate::initLocale()': kernel/qcoreapplication.cpp:601:45: error: expected ')' before ';' token if (int dot =

Re: [Development] Metatype system in Qt6

On 05.12.19 21:19, d3fault wrote: On 12/5/19, Olivier Goffart wrote: That will not be working anymore if the MyType is only worward declared. The user will have to do one of these: 1. #include "MyType.h" in the header 2. Q_DECLARE_OPAQUE_POINTER(MyType *) 3. Q_MOC_INCLUDE

Re: [Development] Metatype system in Qt6

Hi, Reviving an old thread as I am currently working on QMetaType. QMetaType is a low level API of Qt, normally a developer shouldn't use it much in its application, and the goal for Qt6 is that there is even less to know about it. In short, the goal was to remove the use for

Re: [Development] QAction in Qt 6 - next step proposal

On 27.11.19 11:19, Friedemann Kleint wrote: Hi, as discussed on the change, there is not much one can do with the newly introduced QGuiAction; it serves as a base class for QAction and QQuickAction, The naming follows the Q(Gui)Application pattern. > QMenu *menu() const; > -> static QMenu

Re: [Development] QTCS2019 Notes from QtQml session

On 25.11.19 16:36, André Somers wrote: On 25-11-19 15:53, Ulf Hermann wrote: 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

[Development] QtCS2019: moc and QMetaObject

Here are the notes from the session https://wiki.qt.io/Qt_Contributors_Summit_2019_-_moc_and_QMetaObject Summary: We discuss if we should rewrite moc using libclang. moc currently hasn't still fully be ported to support C++11 yet. Features such as raw literals, trailing returns and other will

Re: [Development] RFC: QVariant changes in Qt6

out there have sufficient test coverage to catching automatically. What are your plans to support Qt users to catch these behavior changes? Ciao Mathias Am 22.11.2019 um 14:32 schrieb Olivier Goffart: Hi, This is a follow-up on what was discussed in the (second part of the) QtCore session

Re: [Development] RFC: QVariant changes in Qt6

On 24.11.19 12:36, Lars Knoll wrote: Hi Olivier, Thanks for looking through this and coming up with a proposal. I like the direction. On 22 Nov 2019, at 14:32, Olivier Goffart wrote: Hi, This is a follow-up on what was discussed in the (second part of the) QtCore session in the QtCS

Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate

On 24.11.19 12:24, Giuseppe D'Angelo via Development wrote: Il 21/11/19 17:38, Joerg Bornemann ha scritto: It works and produces seemingly the correct output, able to consume modern C++ constructs. But it's sloow. Running on Qt Creator takes 1 min with the old parser, and 50 min with the

[Development] RFC: QVariant changes in Qt6

Hi, This is a follow-up on what was discussed in the (second part of the) QtCore session in the QtCS. Lars and others have been mentioning that they dislike implicit conversions within QVariant. Creating a new class (QAny) has been suggested, that would be like QVariant but without the

Re: [Development] Property bindings in Qt 6

On 26.09.19 20:50, Ville Voutilainen wrote: On Thu, 26 Sep 2019 at 21:08, Pierre-Yves Siret wrote: I feel like custom getters and the ability to mark a property dirty are needed too. You might have a property that's provided by an outside system, and you maybe don't want to query it every

Re: [Development] Property bindings in Qt 6

On 26.09.19 18:22, Julien Cugnière wrote: Le jeu. 26 sept. 2019 à 17:03, Simon Hausmann a écrit : I would like to propose an API that replaces the setter and getter functions on objects with a new property template class that encapsulates the property value instead, and the ability to tie

Re: [Development] Updating/changing "default" branch for qtbase repository

On 17.09.19 11:27, Kevin Funk via Development wrote: OT: Out of curiosity: Why was "dev" chosen over "master" as main development branch in the first place? What's the benefit? This is also something which might confuse new contributors easily, as it's not the Git standard nomenclature. If we

Re: [Development] Extending moc to generate easily accessible metatype descriptions

On 16.09.19 12:32, Ulf Hermann wrote: > [...] The place where all the metatypes are known at compile time is inside moc. Well, unfortunetely, even moc doesn't know about all the metatypes. Many types don't need registration, and moc is not always aware of the Q_DECLARE_METATYPE declaration

Re: [Development] thread_local: replacing GCC with Clang for MinGW

On 25.08.19 17:43, Thiago Macieira wrote: On Sunday, 25 August 2019 00:44:51 PDT Olivier Goffart wrote: One could fix the leak by re-implementing DllMain in QtCore and using the DLL_THREAD_DETACH hook to delete the QAdoptedThread https://docs.microsoft.com/en-us/windows/win32/dlls/dllmain

Re: [Development] thread_local: replacing GCC with Clang for MinGW

On 24.08.19 18:04, Thiago Macieira wrote: [...] That means we must continue to use QThreadStorage where we need non-POD thread-local storage, which only works[*] in QThread-started threads. [*] it won't crash if you use QThreadStorage with a thread started with something else, despite what the

Re: [Development] HEADS-UP: QStringLiteral

On 21.08.19 17:55, Thiago Macieira wrote: On Wednesday, 21 August 2019 08:18:08 PDT Tor Arne Vestbø wrote: Oh, the following is nearly the most optimal: test[u"key"] = u"value”; So that would be utf16, can’t we let test["key"] = “value” assume utf8, ie u8”foo” without the

Re: [Development] Why does Q_ENUM() need qRegisterMetaType()?

On 04.07.19 12:43, Tom Isaacson wrote: The problem is that moc only generates the code that calls qRegisterMetaType if it sees Q_DECLARE_METATYPE. Actually, it does a bit more than that. It could as well do it for Q_ENUM type, just not implemented yet. We should consider doing it for all the

Re: [Development] Why does Q_ENUM() need qRegisterMetaType()?

On 03.07.19 22:25, Tom Isaacson wrote: No response on Qt Interest so trying here. I'm using Qt 5.12.2 on Visual Studio 2019 / Win7. I wanted to make sure Q_ENUM works the way I think it does before updating some legacy code so I wrote a unit test (we use Google Test): TestConnectEnum.h:

Re: [Development] Assistant WebKit/WebEngine support

On 27.06.19 20:14, Thiago Macieira wrote: On Wednesday, 26 June 2019 18:47:32 PDT Lars Knoll wrote: Yes, Webengine uses some memory. But is that really a problem on developer machines? [...] I'm not saying that Qt Web Engine would be a problem. I was arguing against "memory is not a problem

Re: [Development] How to port from Q_FOREACH to range-based for

On 11.06.19 09:17, Lars Knoll wrote: So, is removing it worth all the hassle to us and our users? Q_FOREACH is a macro and it doesn’t really cost us anything to keep it around. Yes, it has issues with non Qt containers and I wouldn’t recommend it for any new code. But maybe we could simply

Re: [Development] Deprecation/removal model going into Qt 6

On 05.06.19 07:24, Thiago Macieira wrote: On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer wrote: $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME SONAME libQt5Core.so.5 Note the two numbers in the SONAME. They mean two

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 01.06.19 17:56, Thiago Macieira wrote: On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote: I am getting mildly irritated by those ongoing suggestions (not just yours) to use anything but Qt to get stuff done, even Qt's own tasks. It's sending an odd message. Sure, one can pull e.g.

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 29.05.19 17:17, Mutz, Marc via Development wrote: But of course, that's a fallacy, because as soon as Qt internally uses said inline functions, every use of them by the user with a different STL is an ODR violation and therefore UB. So, again AFAICT, the decision was that we can use std

Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6

On 29.05.19 12:53, Mutz, Marc via Development wrote: == MT plumbing == Let's make use of the std facilities to enable checkers such as TSAN to work without hacks. It's not Qt's business to reimplement threading primitives. Normally, checkers such as TSAN work out of the box. But they kind of

Re: [Development] QList for Qt 6

On 22.05.19 15:49, Lars Knoll wrote: [...] 2. Move QStringList and QByteArrayList over to inherit from QVector (that should be source compatible) 3. Rename QStringList to QStringVector (keep QStringList as a compatibility name), same for QBAList I wouldn't do that. I'd just make using

Re: [Development] What's the status of a moved-from object?

On 20.05.19 17:27, Konstantin Tokarev wrote: 20.05.2019, 18:21, "Thiago Macieira" : On Monday, 20 May 2019 06:56:56 PDT Lars Knoll wrote:  I actually think we should consider getting rid of shared_null and instead  have d == nullptr as the null/default constructed state of the object. Yes,

Re: [Development] What to expect from QIcon/the icon engine on screen changes

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

Re: [Development] Deprecation of QByteArray operator const char *()?

On 25.01.19 21:11, Christian Ehrlicher wrote: Hello, The two implicit conversions from QByteArray to const char*/void* (QByteArray::operator const char *() and QByteArray::operator const void*()) were marked as obsolete with Qt5.0 but never get decorated as such. This means their usage even

Re: [Development] Qt modules, API changes and Qt 6

On 25.01.19 14:12, Frederik Gladhorn wrote: Hi all, I'd like to start another discussion around our development workflow. We arrived at our current model of Qt modules (in the git repository sense) and using qt5.git as a container for all of them through a series of steps and changes. Mix in

Re: [Development] Qt6: Adding UTF-8 storage support to QString

On 23.01.19 23:15, André Pönitz wrote: On Wed, Jan 23, 2019 at 05:40:33PM +0300, Konstantin Tokarev wrote: 23.01.2019, 16:55, "Edward Welbourne" : All of this discussion ignores a major elephant: QString's indexing is by 16-bit UTF-16 tokens, not by Unicode characters. We've had Unicode for a

Re: [Development] Use QMetaEnum::keyCount() to initialise array

On 07.01.19 19:50, Tom Isaacson wrote: > I wonder if moc-ng could handle this? > https://woboq.com/blog/moc-with-clang.html Not really, even if it can generate things in a header for templates, it still generates te actual data in a .cpp file. As it was said before, we can't really have the

Re: [Development] Qt6 source changes

On 02.11.18 09:20, Ulf Hermann wrote: Depends on usage. See e.g. 551efd91990e07902e5324f720cf5585865c323d QmlProfiler: Use QList for QmlRange container when loading .qtd As we are using this as a queue, with many calls to takeFirst(), a QVector is prohibitively expensive

Re: [Development] Who is in charge of qt-project.org?

On 01.11.18 08:49, Tuukka Turunen wrote: Hi Christian, What comes to the mistake with the mailing list archive, we of course fix it. Meanwhile, use the workaround described by Andy: " It is there, but you have to go to http://lists.qt-project.org for now, it is being moved to a new server so

Re: [Development] Metatype system in Qt6

Hi, On 10/30/18 12:38 PM, Jedrzej Nowacki wrote: [...] Extensions in that respect do not change anything, because it is about error handling. How to inform a user that a type is not qdebug stream-able Not really important. I just want to do qDebug() << my_variant; and have some useful

Re: [Development] Build system for Qt 6

On 10/30/18 6:29 AM, resurrect...@centrum.cz wrote: Honestly I feel very disappointed as well with this decision. I feel similarly to others, Qbs is now being phased out so fast (half a year of development, another half a year of maintanance after that it seems). So better get to porting stuff

Re: [Development] Metatype system in Qt6

On 10/29/18 5:39 PM, Jedrzej Nowacki wrote: Hi everyone! While main heat on the mailing list is taken by topic how to encode that we are nice, friendly and respectful to each other, I would like to show some side project that I had. It is a proposal for base of metatype system for Qt6. You

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

On 10/29/18 4:56 PM, Thiago Macieira wrote: 2) it's implemented by way of a for loop inside a for loop, which is known to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17:

Re: [Development] Undeprecating Q_FOREACH

I'm just replying to this email to sumarize my opinion from the other email in the "qMoveToConst helper for rvalue references to movable Qt containers?" thread. I do not think it is time to deprecate foreach. Currently, the documentation says it is discouraged, and that's fine. But the

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

On 10/28/18 8:17 PM, Thiago Macieira wrote: On Sunday, 28 October 2018 11:49:08 PDT Olivier Goffart wrote: It is a bit ironic that one reason given to deprecate Q_FOREACH is that it may copy the container in some cases, while the alternative has the same problem in much more common cases

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

On 10/27/18 5:27 PM, Sérgio Martins 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. But what's the percentage of Qt developers that understand the subtleties between Q_FOREACH and range

Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?

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 =

Re: [Development] QButtonGroup: When the "right thing to do" is absolutely the wrong thing to do

On 10/13/18 9:03 AM, Boudewijn Rempt wrote: On vrijdag 12 oktober 2018 14:31:33 CEST Konstantin Ritt wrote: It didn't. Then what else made it necessary to suddenly add lots of #include lines? Maybe that was commit 000c76ada5cc21479fc479be16a7507fed6490f8 ? The commit you mentioned does

Re: [Development] Strange behavior on 5.12 branch and moc genrated file ( KDE application )

On 9/5/18 2:11 PM, Ville Voutilainen wrote: On 5 September 2018 at 14:42, Helio Chissini de Castro wrote: Unfortunately not. Just compiled again reverting this commit and the issue still there. No ideas for now :-/ Any volunteers to bisect the problem? Most likely

Re: [Development] Automatic signal-slot statistics

On 2018-08-08 08:48, Taras Kushnir wrote: Hi Olivier Thanks for fast response. Sorry for asking trivial questions but I didn’t quite understand about “redeclaring” things in my project. As far as I understand all I need to do is pass an instance of [QSignalSpyCallbackSet] struct with my

Re: [Development] Automatic signal-slot statistics

On 2018-08-08 06:53, Taras Kushnir wrote: Hello I’ve been refactoring giant pieces (like 50-60%) of one project's codebase and I’m concerned about validity/quality of the result. Except different kinds of tests I’m thinking about statistical metrics one of which would be to get a feel how

Re: [Development] clang-format

On 2018-06-21 16:02, Thiago Macieira wrote: On Thursday, 21 June 2018 04:51:38 PDT Frederik Gladhorn wrote: checkout the change before we run clang-format run clang-format on the changed files push on top of the formatting change I'd appreciate such a script. As I said, I will dedicate no

Re: [Development] unique_ptr and Qt

On 2018-06-05 14:40, Daniel Teske wrote: Hi, I've done some research into how supporting unique_ptr in Qt might look like. I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. Qt:

Re: [Development] RFC: unified data model API in QtCore

On 2018-06-14 02:08, Thiago Macieira wrote: [...] For example, the next data model over would be XML. And we are indeed missing a DOM structure for it since we deprecated QDomDocument. Can anyone see a data structure that works for both JSON/CBOR and generic XML? More importantly, one that is

Re: [Development] Conventions for using qmlRegisterType in qtdeclarative

On 2018-04-11 11:00, Tomasz Olszak wrote: Hello, In [1] Michael Brasser pointed out that I should introduce new revision after adding new property to QQmlLoggingCategory. First question: 1. Why in [2] QQuickTextInput is registered for versions > 9 with revision 0? I would expect that it should

Re: [Development] Qt branches & proposal how to continue with those

Am Freitag, 9. Februar 2018, 08:13:01 CET schrieb Thiago Macieira: > On Thursday, 8 February 2018 23:02:36 PST Kevin Kofler wrote: > > IMHO, you need to rethink your whole CI approach. This is increasingly > > being the one bottleneck slowing down Qt development and releases. It > > might make

Re: [Development] Deprecation of Qt Quick Controls 1

Am Mittwoch, 7. Februar 2018, 15:35:34 CET schrieb NIkolai Marchenko: > even stuff like that? > https://imgur.com/a/tTFeO > I doubt it. I really don't want to delve into manual painter usage and > styleoptions when I can just quickly make such stuff with qml listview. > And basically the only

Re: [Development] Undeprecating QString::null

Am Dienstag, 16. Januar 2018, 16:20:54 CET schrieb Uwe Rathmann: > Hi all, > > I received a bug report concerning a header of the Qwt library ( http:// > qwt.sf.net ), that is using the deprecated QString::null. > > Sure this is only a warning, but it is obviously something where Qwt > users get

Re: [Development] QML and Qt Quick versioning of our modules

Am Donnerstag, 7. Dezember 2017, 14:53:06 CET schrieb Frederik Gladhorn: > Hi all, > > I've lately been discussing with a few people in The Qt Company about our > versioning. > Historically it was a good idea to not couple Qt Quick too tightly to > general Qt releases. There were quite some

Re: [Development] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

Am Dienstag, 29. August 2017, 17:30:56 CEST schrieb Thiago Macieira: > On Tuesday, 29 August 2017 01:10:53 PDT René J.V. Bertin wrote: > > Which we just rediscovered :) Funny though, apparently 1 misdirected > > startTimer() call can turn any application in a CPU hog that burns cycles > > without

Re: [Development] QTabBarPrivate::hoveredTabIndex() visibility

Am Donnerstag, 6. Juli 2017, 13:53:35 CEST schrieb René J.V. Bertin: > Hi, > > Is QTabBarPrivate::hoveredTabIndex() supposed to be visible for software > having "QT += widgets-private" in their .pro file? Only from Qt 5.10 (since commit 4f3249f32dbe5c20aabbfd9b4f9c558aaf449e48 in the dev branch)

Re: [Development] What to do with qrand/qsrand?

Am Dienstag, 13. Juni 2017, 21:52:34 CEST schrieb Thiago Macieira: > I've changed almost all uses of qrand in Qt sources to QRandomGenerator and > eliminated the use of qsrand. That is actually the biggest advantage: not > needing to seed the generator. I was quite surprised how much use of qrand

Re: [Development] [Releasing] Qt 5.10 pre-built bunaries

Am Donnerstag, 8. Juni 2017, 12:00:02 CEST schrieb Marc Mutz: [...] > Thread ended inconclusive, but with two strong oppositions to drooping GCC > 4.7 and MSVC 2013 each. Note that this was before we knew that Qt 5.9 would be a LTS. ___ Development

Re: [Development] QList

Am Donnerstag, 18. Mai 2017, 10:58:23 CEST schrieb Ville Voutilainen: > [...] the QUIP is here for review: > https://codereview.qt-project.org/#/c/194984/ Thanks, (Sorry for not replying to the QUIP, but discussions on gerrit are not so easy to follow) Here are what what are the

Re: [Development] QUIP 6: removing top-level const from return types

Am Dienstag, 23. Mai 2017, 08:36:00 CEST schrieb Lars Knoll: > > On 23 May 2017, at 07:26, Marc Mutz wrote: > > > > On Tuesday 23 May 2017 00:48:53 Thiago Macieira wrote: > >> Then we are right now concluding this kind of change should not be in > >> that > >> part of the

Re: [Development] QUIP 6: removing top-level const from return types

Am Montag, 22. Mai 2017, 12:04:10 CEST schrieb Marc Mutz: > Hi, > > Removing top-level const from return types is a QUIP-6 Cat-A SiC, but was > missing from the examples. > > https://codereview.qt-project.org/195285 proposes to add it to the QUIP. > > Precedence: E.g.

Re: [Development] QHash iteration vs std::unordered_map

On Montag, 17. April 2017 18:48:26 CEST Marc Mutz wrote: > On Monday 17 April 2017 18:08:20 Thiago Macieira wrote: > > Em segunda-feira, 17 de abril de 2017, às 00:30:23 PDT, Marc Mutz escreveu: > > > The problem with QT_STRICT_ITERATORS is _not_ that they are changing > > > begin() and end(), >

Re: [Development] Adding Q_GADGET here and there

On Sonntag, 16. April 2017 16:41:27 CEST Alberto Mardegan wrote: > Hi all, > I'm about to use QMimeType in my application, and I'd found it useful > if it were a Q_GADGET. Can I just go on and submit a patch to add that, > or are there some cons (a small increase on the library size, I assume)?

Re: [Development] As Qt contemplates its future..

On Samstag, 15. April 2017 00:23:01 CEST Shawn Rutledge wrote: [...] > The Rust guys make the point that it’s necessary to rewrite lots of old > stuff in Rust in order to have all the security that it can guarantee. No, that's a common myth. I've heard people say: "There is no point in

Re: [Development] supported compilers in 5.10?

On Donnerstag, 30. März 2017 11:21:35 CEST Marc Mutz wrote: > Hi, > > Can we drop GCC 4.7 from the list of supported compilers for 5.10? It has a > bug that makes writing constexpr classes like QSizePolicy, QUuid, ... very > annoying: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54922 > > If

Re: [Development] QList

On Donnerstag, 30. März 2017 08:32:24 CEST Marc Mutz wrote: > On Thursday 30 March 2017 08:18:52 Olivier Goffart wrote: > > On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > > > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > > > On quarta

Re: [Development] QList

On Donnerstag, 30. März 2017 07:20:11 CEST Marc Mutz wrote: > On Wednesday 29 March 2017 22:12:30 Thiago Macieira wrote: > > On quarta-feira, 29 de março de 2017 11:11:58 PDT Marc Mutz wrote: > > > Keyword: inline namespaces. This is the C++ mechanism for API > > > versioning. It allows to make

Re: [Development] Wishes for C++ standard or compilers

On Mittwoch, 29. März 2017 11:53:16 CEST Ville Voutilainen wrote: > On 29 March 2017 at 12:49, Marc Mutz wrote: > > This is probably one of the most important things. Ville asked on std- > > proposals to show hard numbers. You don't need hard numbers. You just need > > to

Re: [Development] QList

On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote: > On Wed, 29 Mar 2017 10:39:42 +0200 > > Olivier Goffart <oliv...@woboq.com> wrote: > > I don't think we need QArrayList. As you said, it's not often used (only > > one known use?). and QToolBox is not even usi

Re: [Development] QList

On Mittwoch, 29. März 2017 09:37:04 CEST Marc Mutz wrote: > To bring this thread back on-topic: > > I have prepared a patch that implements QArrayList as outlined below (as a > template alias): https://codereview.qt-project.org/188938 > > The only well-known user of stable references into QList,

[Development] RFC: Containers member functions for algorithm

Hi everyone, I have been wondering if we should enhance Qt container with member functions to help using some of the standard algorithm. a peace of code is better than many words. We would be able to do: myList.sort(); //or myList.sort([](auto , auto ){ return a.member < b.member; }); if

Re: [Development] Diff between Qt-5.7.1 and Qt-5.8.0 on Android - Pointer Below the Cursor at Text Fields

On Sonntag, 19. März 2017 09:39:57 CET Robert Iakobashvili wrote: > Hi, > Sorry for cross-posting, but maybe Qt Android maintainer is knowledgeable > about the issue below. > > Nexus-7 with Android-6 > > The same Qt app built with 5.7.1 works properly > and with 5.8.0 appears a blue pointer down

Re: [Development] Wishes for C++ standard or compilers

On Montag, 20. März 2017 11:27:44 CET Konrad Rosenbaum wrote: > Hi, > > On Mon, March 20, 2017 08:20, Olivier Goffart wrote: > > On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: > >> The name is necessary for compatiblity iwth other languages. &g

Re: [Development] Wishes for C++ standard or compilers

On Sonntag, 19. März 2017 19:51:47 CET Thiago Macieira wrote: > On domingo, 19 de março de 2017 02:24:56 PDT Olivier Goffart wrote: > > But because QMetaType was historically made for QueuedConnection, it needs > > the name, and so needs to be declared or registered with > &g

Re: [Development] Wishes for C++ standard or compilers

On Samstag, 18. März 2017 22:20:49 CET Thiago Macieira wrote: > Ville asked what would be nice to have, so I put together a list: > > == SD-6 feature macros == > We made a decision not to add Q_COMPILER_xxx macros in Qt past C++11, and > only depend on the ones from the standard. But there are

Re: [Development] Need advise on acceptable timeouts for autotests

On Donnerstag, 16. März 2017 10:00:55 CET Marc Mutz wrote: > Hi, > > We repeatedly have the problem that timeouts that developers think are ample > (because they exceed typical runtime by, say, two orders of magnitude) are > found to be insufficient on the CI. > > Latest example: >

Re: [Development] syncqt.pl in C++

On Donnerstag, 9. März 2017 21:19:51 CET Egor Pugin wrote: > Hello again, > > Pretty long discussion is moved to build systems. > Here are some my general notes and brief presentation of my project. > > 1. For those who may be interested - my simple implementation of > syncqt.pl in C++ available

Re: [Development] Use of std::function in Qt API

On Dienstag, 14. März 2017 10:33:44 CET Simon Hausmann wrote: > Hi, > > > I understand that there are limitations (to put it mildly) regarding the use > of API from the C++ standard library in Qt API itself due to the inability > to extend our binary compatibility promise. I'm curious though

Re: [Development] Qt mobile input context scrolling

On Donnerstag, 9. März 2017 06:33:11 CET Vlad Seryakov wrote: > Hello, > I am trying to disable Qt auto-scrolling on mobile devices(iOS, Android) > when focusing on an input field in QtQuick. > > For iOS it was pretty simple and just for a proof of concept making >

Re: [Development] Don't use Private *d when your class is immutable

On Freitag, 3. März 2017 12:19:42 CET Marc Mutz wrote: > But don't - ever- use ref-counting on immutable classes. It's not easier > (you need to implement all the special member functions, which peoole, me > included[1][2], get wrong more often than we dare to admit). refcounting is easy: class

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

On Mittwoch, 15. Februar 2017 12:52:50 CET Shawn Rutledge wrote: > users into upgrading to 5.9 sooner than they might otherwise I don't think that's true. I even think it's the opposite. Users of 5.6.2 or 5.7.1, that did not upgrade to 5.8.0 because it is a .0 release will also have to wait

Re: [Development] Removing fromUtf8() fallback in QStringLiteral

On Donnerstag, 9. Februar 2017 17:32:42 CET Marc Mutz wrote: > On Thursday 09 February 2017 10:41:05 Marc Mutz wrote: > > AFAICT, (2) could only possibly affect ICC and VxWorks. > > From the change set: > > - VxWorks uses GCC 4.8, that's enough. > - The ICC minimum version since Qt 5.7 (cf.

Re: [Development] Nominate Mike Krus as approver

On Mittwoch, 8. Februar 2017 10:52:10 CET Edward Welbourne wrote: > ... which may well have been the intent, but the thing about Rules, > Policies, Laws and Constitutions is that they have to actually *say* > what they mean, And you can say the same about the code in any programming language. >

Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows?

On Montag, 30. Januar 2017 08:32:50 CET Thiago Macieira wrote: > On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev wrote: > > What about Intel? (IIRC they use EDG frontend, aren't they?) > > icc on Mac and Windows operates like GCC and Clang. > > I'll check icl.exe on

Re: [Development] QFlags Zero handling

On Samstag, 21. Januar 2017 11:30:40 CET Stephen Kelly wrote: > Hi, > > Does anyone know why QFlags has a constructor taking a Zero pointer? My > guess is that it's a hack to make initializing like > > Qt::WindowFlags = 0 > > work? Correct. We want to be able to initialize it with the literal

Re: [Development] invokeMethod() with function pointers

On Dienstag, 17. Januar 2017 11:21:56 CET Grégoire Barbier wrote: > Le 16/01/2017 à 10:34, Olivier Goffart a écrit : > > What's the use case for this function? For direct call you better of > > calling the function directly, and the equivalent of QueuedConnection > > can be

Re: [Development] invokeMethod() with function pointers

On Freitag, 20. Januar 2017 09:59:55 CET Benjamin TERRIER wrote: > 2017-01-20 3:01 GMT+01:00 Thiago Macieira : > > we also catch the even more dubious code: > > char func[] = "deleteLater"; > > QMetaObject::invokeMethod(, func); I think we should still

Re: [Development] invokeMethod() with function pointers

On Montag, 16. Januar 2017 12:57:01 CET Konstantin Tokarev wrote: > 16.01.2017, 12:34, "Olivier Goffart" <oliv...@woboq.com>: > > On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote: > >> Hi everyone, > >> > >> I'm trying to c

  1   2   3   4   5   6   >