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
https://clang.llvm.or
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 r
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. And
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 is
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 su
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
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 d
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 conclusio
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 c
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 al
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 such
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
libst
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 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
> > use
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 engine
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.
> >
>
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
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 m
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
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
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 m
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 li
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 h
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 msvc-
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 sh
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. Initi
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
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 make
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 gcc/
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 throu
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"
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 ma
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) relea
> 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 assume
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 co
> 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
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
need
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
> rele
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
39 matches
Mail list logo
