Note that "red" in the page does not always mean unsupported, but also that
nobody tested if the feature is present.
> On 12. Aug 2019, at 14:07, Allan Sandfeld Jensen wrote:
>
> On Monday, 12 August 2019 09:58:39 CEST Lars Knoll wrote:
>> I’d personally be favour of using newer version of
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what such patterns are in
general, std::optional and std::tuple
are full of it. :)
> Integrating feature-test macros: Could
Hi,
I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech
Preview state, and Shawn Rutledge is volunteering to be the maintainer.
Although still staying an independent library from the user's perspective, it
will be hosted and built in the qtwebengine.git repository.
How about ICC 19?
https://software.intel.com/en-us/articles/intel-c-compiler-190-for-linux-release-notes-for-intel-parallel-studio-xe-2019
-T
-Original Message-
From: Development On Behalf Of Ville
Voutilainen
Sent: maanantai 12. elokuuta 2019 12.24
To: Lars Knoll
Cc: Qt development
On Monday, 12 August 2019 09:58:39 CEST Lars Knoll wrote:
> I’d personally be favour of using newer version of gcc/clang, but I’m not
> sure we gain a lot with it, as Apple clang is then probably the limiting
> factor. But we could upgrade that to Apple Clang 11 as well.
Yeah, I was looking
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
> On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen
wrote:
> > explicit(bool): We use some ugly patterns in places to simulate this.
>
> Can you point me to those? I do know what such patterns are in
> general, std::optional and
Hello,
The planned Gerrit maintenance break for today did never happen, so we try
again next week.
DATE AND TIME
Monday, 19 Aug 2019.
Start: 08:00 EEST (UTC + 3).
Estimated end: 08:30 EEST (UTC + 3).
--Jukka
On 05/08/2019, 14.33, "Development on behalf of Jukka Jokiniva"
Il 12/08/19 17:11, Thiago Macieira ha scritto:
I think we should aim for something that is modern, but not bleeding edge
today. For a release in late 2020, we should expect that people may want to
use with close-to-2-year-old Linux distros. I would prefer they didn't, but I
think it's reasonable
On Mon, 12 Aug 2019, 20:23 Konstantin Tokarev, wrote:
>
>
> 12.08.2019, 21:01, "Thiago Macieira" :
> > On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
> >> I guess bigger problem is that Poppler is GPL. PDFium is probably the
> only
> >> permissively licensed PDF engine.
> >
>
On Monday, 12 August 2019 04:07:41 PDT Tony Sarajärvi wrote:
> How about ICC 19?
> https://software.intel.com/en-us/articles/intel-c-compiler-190-for-linux-rel
> ease-notes-for-intel-parallel-studio-xe-2019
>
> -T
ICC should only be supported at the latest version at the time of launch. So
we
On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
> I guess bigger problem is that Poppler is GPL. PDFium is probably the only
> permissively licensed PDF engine.
And? If Poppler is a superior alternative, then people can accept its GPL
requirements or not display PDF.
--
Thiago
12.08.2019, 18:25, "Konstantin Tokarev" :
> 12.08.2019, 18:19, "Thiago Macieira" :
>> On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>>> I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in
>>> Tech
>>> Preview state, and Shawn Rutledge is volunteering to be the
12.08.2019, 21:01, "Thiago Macieira" :
> On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
>> I guess bigger problem is that Poppler is GPL. PDFium is probably the only
>> permissively licensed PDF engine.
>
> And? If Poppler is a superior alternative, then people can accept its
On Monday, 12 August 2019 00:45:01 PDT Allan Sandfeld Jensen wrote:
> Why not the latest for all the compilers, like gcc 9 and clang 8? I assumed
> we would use the 5.15 LTS to justify requiring the latest available
> compiler on all platforms.
>
> Especially clang 6 is a bit old. I know for
On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
> I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech
> Preview state, and Shawn Rutledge is volunteering to be the maintainer.
> Although still staying an independent library from the user's perspective,
> it will be
12.08.2019, 18:25, "Konstantin Tokarev" :
> 12.08.2019, 18:19, "Thiago Macieira" :
>> On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>>> I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in
>>> Tech
>>> Preview state, and Shawn Rutledge is volunteering to be the
12.08.2019, 18:19, "Thiago Macieira" :
> On Monday, 12 August 2019 05:35:06 PDT Kai Köhne wrote:
>> I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech
>> Preview state, and Shawn Rutledge is volunteering to be the maintainer.
>> Although still staying an independent
+1
From: Development On Behalf Of Ryan Chu
Sent: Friday, August 9, 2019 3:16 PM
To: development@qt-project.org
Subject: Re: [Development] Nominating Sona Kurazyan as approver
+1 from Ryan
Best regards,
Ryan
From: Development
On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
> Hi,
>
> As mentioned in my blog, it would be good to move forward with the C++
> version we use for Qt 6 and ideally move it to C++17. That implies that we
> need to drop some older compilers for Qt 6. As 5.15 is going to be an LTS
>
On Mon, 12 Aug 2019 at 11:00, Lars Knoll wrote:
> Here’s the baseline I would like to propose:
>
> VC++ 2019
> GCC 8
> Clang 6
> Apple Clang 10.0
>
> Why not the latest for all the compilers, like gcc 9 and clang 8? I assumed we
> would use the 5.15 LTS to justify requiring the latest available
On 12 Aug 2019, at 09:45, Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:
On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
Hi,
As mentioned in my blog, it would be good to move forward with the C++
version we use for Qt 6 and ideally move it to C++17. That implies that we
On Mon, 12 Aug 2019 at 12:16, Lars Knoll wrote:
> > We gain a slightly better baseline wrt. bugs; GCC for instance doesn't
> > backport to closed branches, and GCC 7 is already
> > closed, and 8 will follow relatively quickly. While we can't keep up
> > with that during our (especially LTS)
> On 12. Aug 2019, at 09:58, Lars Knoll wrote:
>
>
>
>> On 12 Aug 2019, at 09:45, Allan Sandfeld Jensen wrote:
>>
>> On Monday, 12 August 2019 09:17:58 CEST Lars Knoll wrote:
>>> Hi,
>>>
>>> As mentioned in my blog, it would be good to move forward with the C++
>>> version we use for Qt 6
Hi,
As mentioned in my blog, it would be good to move forward with the C++ version
we use for Qt 6 and ideally move it to C++17. That implies that we need to drop
some older compilers for Qt 6. As 5.15 is going to be an LTS release, I don’t
think this is going to be a huge problem.
Here’s the
> On 12 Aug 2019, at 10:54, Ville Voutilainen
> wrote:
>
> On Mon, 12 Aug 2019 at 11:00, Lars Knoll wrote:
>> Here’s the baseline I would like to propose:
>>
>> VC++ 2019
>> GCC 8
>> Clang 6
>> Apple Clang 10.0
>>
>> Why not the latest for all the compilers, like gcc 9 and clang 8? I
+1
On 8/9/19 12:42 PM, Alex Blasche wrote:
> Hi all,
>
> I'd like to nominate Sona Kurazyan as approver for the Qt Project. Sona
> ensured the release of QtCoap by bringing it to a releasable state and
> lately, she has been all over Qt doing major cleanups related to deprecated
> Qt APIs and
On 2019-08-12 22:34, Thiago Macieira wrote:
On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
distributions and Android SDKs use.
Any word on what Clang the Android SDK we'll require uses?
NDK r19 and NDK r20 are shipped with clang 8.0, which according to
On Monday, 12 August 2019 15:10:47 PDT Kevin Kofler wrote:
> The existing implementation based on PDFium, on the other hand, provides us
> with an alternative implementation, which application developers may prefer
> for various reasons (one of which is licensing, as already pointed out).
> This
On Monday, 12 August 2019 13:34:25 PDT Mutz, Marc via Development wrote:
> > QByteArray, due to its dual string / byte array nature, will continue
> > to
> > operate on char.
>
> It was a mistake to merge QCString and QByteArray back then. This design
> doesn't work. Python 2 realized it, and we
On Monday, 12 August 2019 13:23:45 PDT Christian Gagneraud wrote:
> On Mon, 12 Aug 2019, 22:13 Thiago Macieira,
>
> wrote:
> > On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> > > The milestone is std::byte, which which we could put QByteArray on a
> > > sound basis.
On Mon, 12 Aug 2019, 21:37 Thiago Macieira,
wrote:
> On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
> > distributions and Android SDKs use.
>
> Any word on what Clang the Android SDK we'll require uses?
>
Clang 8 AFAIK, and let's not forget about their push of libc++ (Vs gnu
On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> The milestone is std::byte, which which we could put QByteArray on a
> sound basis. And char8_t, which would make QUtf8String(View) fly.
QByteArray, due to its dual string / byte array nature, will continue to
operate on
On Monday, 12 August 2019 08:11:38 PDT Thiago Macieira wrote:
> distributions and Android SDKs use.
Any word on what Clang the Android SDK we'll require uses?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
On 2019-08-12 14:34, Allan Sandfeld Jensen wrote:
On Monday, 12 August 2019 14:21:25 CEST Ville Voutilainen wrote:
On Mon, 12 Aug 2019 at 15:10, Allan Sandfeld Jensen
wrote:
> explicit(bool): We use some ugly patterns in places to simulate this.
Can you point me to those? I do know what
On Monday, 12 August 2019 11:22:23 PDT Konstantin Tokarev wrote:
> 12.08.2019, 21:01, "Thiago Macieira" :
> > On Monday, 12 August 2019 08:24:05 PDT Konstantin Tokarev wrote:
> >> I guess bigger problem is that Poppler is GPL. PDFium is probably the
> >> only
> >> permissively licensed PDF
On Monday, 12 August 2019 10:57:34 PDT Giuseppe D'Angelo via Development
wrote:
> Il 12/08/19 17:11, Thiago Macieira ha scritto:
> > I think we should aim for something that is modern, but not bleeding edge
> > today. For a release in late 2020, we should expect that people may want
> > to
> >
On 2019-08-12 21:33, Thiago Macieira wrote:
[...]
Is there any really cool or
important feature for us to require GCC 8, instead of 7? Like the
enforced
copy elision we'll need to deprecate QMutexLocker.
We don't need guaranteed copy elision, we need CTAD for that. If we have
CTAD, we can
On 2019-08-12 22:13, Thiago Macieira wrote:
On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development
wrote:
The milestone is std::byte, which which we could put QByteArray on a
sound basis. And char8_t, which would make QUtf8String(View) fly.
QByteArray, due to its dual string / byte
Thiago Macieira wrote:
> Has any analysis been done comparing the feature and platform support, and
> codebase size, for PDFium versus Poppler?
I don't see what value a Poppler-based Qt PDF rewrite would bring us
considering that there is already a poppler-qt that can be used directly,
and is
On Monday, 12 August 2019 00:17:58 PDT Lars Knoll wrote:
> As mentioned in my blog, it would be good to move forward with the C++
> version we use for Qt 6 and ideally move it to C++17.
Someone with iOS knowledge please address the C++17 issue reported on the
interest list and provide a
On Mon, 12 Aug 2019, 22:13 Thiago Macieira,
wrote:
> On Monday, 12 August 2019 13:03:47 PDT Mutz, Marc via Development wrote:
> > The milestone is std::byte, which which we could put QByteArray on a
> > sound basis. And char8_t, which would make QUtf8String(View) fly.
>
> QByteArray, due to its
41 matches
Mail list logo
