Gerrit was for a long time taken well care of by Ossi and Frederik. In
connection with Ossi's departure we've added a couple of new admins:
- Kari Oikarinen
- Paul Wicking
- Jukka Jokiniva
Frederik Gladhorn continues as well. Given the larger amount of people, to avoid
duplicate work we'd like to
Hi all,
I'd like to have some opinions about the gnuwin32 we currently have in
qt5.git. This way we provide flex and bison for Windows.
I think it's a bit mis-placed, in my opinion the tools which are needed on
Windows should be in their own sub-module.
I think we should continue to ship them a
On torsdag 27. desember 2018 11:05:28 CET Christian Ehrlicher wrote:
> Am 27.12.2018 um 10:52 schrieb Allan Sandfeld Jensen:
> > It has been for me. I always put bugs I have a patch in review for "in
> > progress", and they have been consistently closed, except one time I found
> > a bug in the scr
> -Original Message-
> From: Development On Behalf Of
> Frederik Gladhorn
> Sent: Friday, 18 January 2019 2:09 PM
> To: development@qt-project.org
> Subject: [Development] gnuwin32 in qt5.git
>
> Hi all,
>
> I'd like to have some opinions about the gnuwin32 we currently have in
> qt5.git
They are used on Windows for angle’s glsl parser.
Simon
On 18. Jan 2019, at 14:19, Mitch Curtis wrote:
>> -Original Message-
>> From: Development On Behalf Of
>> Frederik Gladhorn
>> Sent: Friday, 18 January 2019 2:09 PM
>> To: development@qt-project.org
>> Subject: [Development] gnuwi
I’m a fan of the idea that for Qt6 we remove all copies of third party
libraries and provide convenient binaries of them in the qt installed (as
separate package in there) as well as via vcpkg for those wanting to build from
source.
Flex and bison are IMO exactly the same kind of third party s
I suggest to commit the sources to the qtqa repo.
Simon
> On 18. Jan 2019, at 14:15, Frederik Gladhorn wrote:
>
>> On torsdag 27. desember 2018 11:05:28 CET Christian Ehrlicher wrote:
>>> Am 27.12.2018 um 10:52 schrieb Allan Sandfeld Jensen:
>>> It has been for me. I always put bugs I have a p
On 18.1.2019 15.12, Frederik Gladhorn wrote:
> On torsdag 27. desember 2018 11:05:28 CET Christian Ehrlicher wrote:
>> Am 27.12.2018 um 10:52 schrieb Allan Sandfeld Jensen:
>>> It has been for me. I always put bugs I have a patch in review for "in
>>> progress", and they have been consistently clo
> On 18 Jan 2019, at 14:26, Simon Hausmann wrote:
>
>
> I’m a fan of the idea that for Qt6 we remove all copies of third party
> libraries and provide convenient binaries of them in the qt installed (as
> separate package in there) as well as via vcpkg for those wanting to build
> from source
On 1/18/19 2:27 PM, Simon Hausmann wrote:
>
> I suggest to commit the sources to the qtqa repo.
>
+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 1/18/19 2:26 PM, Simon Hausmann wrote:
>
> I’m a fan of the idea that for Qt6 we remove all copies of third party
> libraries and provide convenient binaries of them in the qt installed (as
> separate package in there) as well as via vcpkg for those wanting to build
> from source.
>
> Flex
Hi,
in Qt 5.12; there is a new \nullptr qdoc macro to be used for nullptr
(see "Documentation: Add \nullptr macro and use where applicable"
3eac688ec005833509bffc7097c378af9c5b515f
https://codereview.qt-project.org/#/c/249583/ ).
The underlying motivation (besides using modern C++) is that Qt
On Friday, 18 January 2019, Joerg Bornemann wrote:
> On 1/18/19 2:26 PM, Simon Hausmann wrote:
> >
> > I’m a fan of the idea that for Qt6 we remove all copies of third party
> > libraries and provide convenient binaries of them in the qt installed (as
> > separate package in there) as well as
Dnia środa, 16 stycznia 2019 21:12:55 CET André Pönitz pisze:
> On Tue, Jan 15, 2019 at 10:44:45PM +0100, Allan Sandfeld Jensen wrote:
> > On Dienstag, 15. Januar 2019 19:43:57 CET Cristian Adam wrote:
> > > Hi,
> > >
> > > With every Qt release we see how the new release improved over previous
>
Picking up on this:
If we plan to standardise on our Qt source code being UTF8, can we please allow
QString(“Tor Arne Vestbø") without going through
QLatin1Literal/QStringLiteral/QLatin1String/etc etc?
Tor Arne
> On 18 Jan 2019, at 16:01, Jedrzej Nowacki wrote:
>
> Dnia środa, 16 stycznia 2
> -Original Message-
> From: Development On Behalf Of
> [...]
> Would it make sense to use a package manager like Conan to provide third
> party dependencies as well as Qt modules in source and prebuilt binary form?
> That could solve the availability issue and would probably simplify the
On Friday, 18 January 2019 07:26:51 PST Tor Arne Vestbø wrote:
> If we plan to standardise on our Qt source code being UTF8, can we please
> allow QString(“Tor Arne Vestbø") without going through
> QLatin1Literal/QStringLiteral/QLatin1String/etc etc?
I think we now can. The last problem we had was
> -Original Message-
> From: Development On Behalf Of Tor
> Arne Vestbø
> Sent: Friday, January 18, 2019 4:27 PM
> To: Jedrzej Nowacki
> Cc: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString
>
> Picking up on this:
>
On Friday, 18 January 2019 08:13:40 PST Kai Koehne wrote:
> 1. We generally compile Qt code with QT_NO_CAST_FROM_ASCII that disables the
> QString(const char *) overload. And we do that so that you have to make it
> explicit whether you really want to do the implicit conversion from UTF-8
> to UTF-
noticed that the list of blocker issues for Qt 5.12.1 is reduced to only
2 open issues
so hopefully we can expect Qt 5.12.1 next days
thanx
ekke
Am 14.01.19 um 13:20 schrieb Tuukka Turunen:
> Hi,
>
> Some release blocker bugs have been found in the testing, so we'll need a few
> fixes before the
On Fri, Jan 18, 2019 at 01:29:52PM +, Kari Oikarinen wrote:
> It's not the only automation we have to help development.
>
https://bugreports.qt.io/browse/QTQAINFRA-1958
> qtqa/automation perhaps?
>
http://www.xkcd2.com/927/
___
Development mailin
> On 18 Jan 2019, at 17:21, Thiago Macieira wrote:
>
> On Friday, 18 January 2019 08:13:40 PST Kai Koehne wrote:
>> 1. We generally compile Qt code with QT_NO_CAST_FROM_ASCII that disables the
>> QString(const char *) overload. And we do that so that you have to make it
>> explicit whether you
Den fre 18 jan. 2019 kl 17:47 skrev Kai Koehne :
>
> > -Original Message-
> > From: Development On Behalf Of
> > [...]
> > Would it make sense to use a package manager like Conan to provide third
> > party dependencies as well as Qt modules in source and prebuilt binary form?
> > That coul
Hi! While building Qt creator 4.8.0 I've found:
Project WARNING: Clang LibTooling is disabled. \
Set QTC_ENABLE_CLANG_LIBTOOLING to enable it.
So I went ahead and enabled it. It turned out that this feature was still
experimental:
https://bugreports.qt.io/browse/QTCREATORBUG-21827
So ok,
On Friday, 18 January 2019 08:57:19 PST Tor Arne Vestbø wrote:
> > On 18 Jan 2019, at 17:21, Thiago Macieira
> > Actually, what we should do is allow everywhere
> >
> > functionTakingString(u"Tor Arne Vestbø")
> > // (note the u)
>
> Yes, this would be awesome! Please let’s do this 😊
>
25 matches
Mail list logo