11.06.2020, 20:19, "René J.V. Bertin" :
> On Thursday June 11 2020 12:43:11 Konstantin Tokarev wrote:
>
>> Main reason behind QtWebView is described in the root page of its
>> documentation, and it's about mobile platforms, namely Android, iOS, and
>> also WinRT.
>
> For me everything QQuick* i
On Thursday June 11 2020 12:43:11 Konstantin Tokarev wrote:
>Main reason behind QtWebView is described in the root page of its
>documentation, and it's about mobile platforms, namely Android, iOS, and also
>WinRT.
For me everything QQuick* is (mostly) about mobile platforms, but that's a
diffe
I can certainly appreciate your concern here.
Our final Qt 5.15 release is an LTS release for commercial customers. This
means we will continue to have support for Windows 7 development under Standard
Support until roughly January 2022 with the option to then buy Extended Support
and remain on
On 2020-06-11 17:23, Philippe wrote:
I hardly see many users that need to stick to an old Windows version to
be keen,
on another hand, to update to the brand new Qt 6.
That would be paradoxal, few would do this.
And that's not the end of Qt for these Windows 7 users anyway, as they
will be able
I hardly see many users that need to stick to an old Windows version to be keen,
on another hand, to update to the brand new Qt 6.
That would be paradoxal, few would do this.
And that's not the end of Qt for these Windows 7 users anyway, as they
will be able to use Qt 5.15 for a long time.
Philip
On Thu, Jun 11, 2020 at 1:42 PM Oliver Wolff wrote:
>
> - We can focus our Windows resources on bug fixes and new
> functionality instead of maintaining this "legacy" operating system
> - CI resources that are used for Windows 7 tests can be used to
> test other configurations
Please d
On Thu, Jun 11, 2020 at 4:48 PM Oliver Wolff wrote:
>
> Hi Robert,
>
> On 11.06.2020 15:02, coroberti . wrote:
> > On Thu, Jun 11, 2020 at 3:43 PM Oliver Wolff wrote:
> >> with Qt 6 approaching it is time to have a look at our set of supported
> >> platforms.
> >
> >> The operating system was ini
Hi Robert,
On 11.06.2020 15:02, coroberti . wrote:
On Thu, Jun 11, 2020 at 3:43 PM Oliver Wolff wrote:
with Qt 6 approaching it is time to have a look at our set of supported
platforms.
The operating system was initially launched in 2009 and reached its
official end of life in January 2020.
On Thu, Jun 11, 2020 at 3:43 PM Oliver Wolff wrote:
> with Qt 6 approaching it is time to have a look at our set of supported
> platforms.
> The operating system was initially launched in 2009 and reached its
> official end of life in January 2020. That means that Microsoft no
> longer provides s
> On 11 Jun 2020, at 12:56, Lars Knoll wrote:
>
> We certainly shouldn’t start documenting the macros now in 5.15.1.
Fine by me; I’ve abandoned the documentation effort and closed the reported bug
as won’t do.
--
Paul Wicking
R&D Manager
The Qt Company
Sandakerveien 116
0484, Oslo, Norw
Hi,
with Qt 6 approaching it is time to have a look at our set of supported
platforms.
One candidate for removal of support was Windows 7. Some considerations
about dropping this support have been communicated on Qt's development
mailing list in March last year [1] and there were some discus
Il 11/06/20 11:11, Edward Welbourne ha scritto:
That then leaves the question of whether we deprecate in Qt 6 or remove
these macros. I shall leave Marc, who I understand as wanting the
latter option, to make the case for it, lest I misrepresent that case.
I fear the macros are going to be ne
We certainly shouldn’t start documenting the macros now in 5.15.1.
IMO they should simply unconditionally expand to static_assert(). I’d also be
ok if someone wants to do a search and replace s/Q_STATIC_ASSERT/static_assert/
in our source code.
But I don’t think we should do much more right n
Hi,
I don't care much about when we remove these macros, as it makes sense
to keep using them in Qt 6 for code that will be backported to 5.
What I don't agree with is to go to extra lengths to deprecate (that
would be cutting our own flesh, if we retain the macros for the
above-mentioned us
Am 10.06.20 um 18:28 schrieb Thiago Macieira:
> On Wednesday, 10 June 2020 04:35:51 PDT Dominik Holland wrote:
>>> Strictly speaking, you don't have to build Qt twice. You can use your
>>> system's packaged Qt, or Conan or Homebrew or one of the binary builds
>>> from qt.io as the other. If you do
11.06.2020, 11:11, "René J.V. Bertin" :
> On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote:
>
>> Whole point of QtWebView is to use platform specific backends on platforms
>> where they do exist, at the cost of limited API. If you need to use
>> platform-specific backends and want to
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
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 know of no way to tell the compiler to
warn ab
On Thursday June 11 2020 04:31:59 Konstantin Tokarev wrote:
>Whole point of QtWebView is to use platform specific backends on platforms
>where they do exist, at the cost of limited API. If you need to use
>platform-specific backends and want to replace QtWebEngine on platforms with
>no "native"
19 matches
Mail list logo
