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.
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 comi
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 k
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
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
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: 5.1
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
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 need
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
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 erro
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 that. I
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
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 = newLocale.in
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
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 Q_DECLARE_METATYP
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 *
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 measure.
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
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 in
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
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 new
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 convers
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 t
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 bin
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 ev
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 (b
On 06.09.19 11:26, Mutz, Marc via Development wrote:
Hi,
I would like to propose to make the existing Qt namespace inline and move all
of Qt's declarations into it.
== TL;DR: ==
Qt can already, optionally, be configured into a user-specified namespace
(QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -
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
That
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
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 explicitne
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 t
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:
clas
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 on
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 fix
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 different
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. any
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 type
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
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 QStrin
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,
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 wel
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 i
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 the
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 c
On 23.01.19 16:51, Jedrzej Nowacki wrote:
Hi,
It is time to rethink our branch model. [...]
Hi,
You do not explain why the proposed solution solve the "problem". I actually
think it is quite the contrary effect of what you think: the proposed model
will slow down patch propagation, and inc
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 con
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
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
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 infor
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
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 ca
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:
https://
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 alternat
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. (It
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
On 10/26/18 10:26 PM, Elvis Stansvik wrote:
For completely other reasons, I came across "Range-based for
statements with initializer" today:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html
With that, the Qt best practice could become
for (const auto list = getQList();
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 n
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 https://codereview.qt-p
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 cust
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 Qt-
On 2018-08-03 08:03, Martin Koller wrote:
On Donnerstag, 2. August 2018 15:45:00 CEST Simon Hausmann wrote:
Hi,
Before concluding that a namespaced Qt is a terrible idea, I recommend trying
out the feature.
It is intended to work transparently and not require any changes to the
application
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 more
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: h
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 wor
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 b
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 more
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 thing
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
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 constr
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 e
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)
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
>
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 mai
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 characteristic
Am Dienstag, 23. Mai 2017, 11:17:32 CEST schrieb Ville Voutilainen:
> On 23 May 2017 at 12:00, Marc Mutz wrote:
> >> Maybe, but I have some questions: the review for removing top-level
> >> consts
> >> from QRegion says "It has no effect and inhibits move semantics." How
> >> does
> >> it inhibit
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 QUIP.
> >
> > The QUIP
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. https://codereview.qt-proje
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(),
> >
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)?
>
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 making/usin
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 we
On Donnerstag, 30. März 2017 11:08:45 CEST Marc Mutz wrote:
> On Thursday 30 March 2017 08:41:51 Olivier Goffart wrote:
> > 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 Donnersta
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
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 tha
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 superficially look at QVe
On Mittwoch, 29. März 2017 13:33:12 CEST Philippe wrote:
> On Wed, 29 Mar 2017 10:39:42 +0200
>
> Olivier Goffart 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 using the implicit
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,
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 &a, auto &b){ return a.member < b.member; });
if (
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
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.
> >
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
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 sev
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:
> http://testres
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
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 whet
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
> QIOSInputContext::scrollableRoot
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
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 5.9.
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. dist/
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.
>
1 - 100 of 687 matches
Mail list logo