Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?
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* is (mostly) about mobile platforms, but that's a > different topic :) > >> all powerful features of QtWebKit's WebView are located in >> WebView.experimental. > > Which doesn't get documented by the `qch_docs` build target, correct? Correct, but Qt Creator gladly autocompletes those properties, also there is info in the net. > >> Out of curiosity, what do you want to add there? > > QtWebView has a method to run javascript code, and the signals aren't the > same. It might be useful if QtWebKit's WebView class were a drop-in > replacement for the one from QtWebView, so you can use the one or the other > by just changing the import statement. Makes sense. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?
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 different topic :) >all powerful features of QtWebKit's WebView are located in >WebView.experimental. Which doesn't get documented by the `qch_docs` build target, correct? > Out of curiosity, what do you want to add there? QtWebView has a method to run javascript code, and the signals aren't the same. It might be useful if QtWebKit's WebView class were a drop-in replacement for the one from QtWebView, so you can use the one or the other by just changing the import statement. R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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 Qt 5.15 indefinitely. We still have customers doing this for Qt 4.8. This is essentially the same thing Microsoft is offering. Corey Pendleton -Original Message- From: Development On Behalf Of coroberti . Sent: Thursday, June 11, 2020 9:17 AM To: Oliver Wolff ; Qt development mailing list Subject: Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6 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 initially launched in 2009 and reached its > >> official end of life in January 2020. That means that Microsoft no > >> longer provides security updates and instances running Windows 7 > >> should be replaced as soon as possible. > >> > >> Br, Olli > > > > Dear Oliver, > > > > The fact is that Windows-7 is supported at least till 2023. > > > > Please, correct your fact table. > > > > https://www.microsoft.com/microsoft-365/partners/news/article/announ > > cing-paid-windows-7-extended-security-updates > > > It's true that Microsoft offers extended support for Windows 7. This > support does not come for free though and there is a price tag attached. > > I think the same might apply inside The Qt Company. If you are a > commercial customer and want to buy extended support for Qt beyond > regular support availability periods, please get in touch with your > Sales representative. If you remove Win-7 from Qt-6, your suggested option of support for commercial customers will be void for Qt-6. After removal, it will be a mess to re-introduce it back whatever money you will be paid. Period. Full-Stop. Qt-6 will have less attractiveness for those bodies that need Win-7: governments, corporates, military, health, insurance, finance, banks and their suppliers. At least talk to your Sales prior to doing it since they have a better smell for money. If Microsoft smells the money - think twice if you'd like to lose this market in Qt-6. Kind regards, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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 to use Qt 5.15 for a long time. Hi, I think a lot of developers/companies will have pain because of this, if they have 1) some large customers staying on Windows 7 until really EOL for them 2) all other customers having modern Windows 10+ You will want to have the fixes/improvements Qt 6 will get in the next 1-2 years (e.g. better HiDPI support, ...) but you will still need to support the other customers on Windows 7. Staying on Qt 5.15 isn't really an option then and in the worst case you will have to maintain & support 2 builds of your software, which is really not that nice. Thought I can understand that if the Qt Company doesn't have resources to maintain both, not a lot can be done against this decision. Greetings Christoph Philippe On Thu, 11 Jun 2020 14:41:34 +0200 Oliver Wolff wrote: 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 discussions about this topic on the corresponding bug report [2] 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 security updates and instances running Windows 7 should be replaced as soon as possible. With this official Microsoft standing in mind our current plan is to remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is planned towards the end of 2020, roughly one year after Windows 7s end of life. Of course, we do not make decisions like this easily or to upset our users but there are clear advantages that speak in favor of dropping support: - We can rely on Windows functions being available instead of trying to dynamically load libraries which might or might not be available. - We can use functionality that only became available in later Windows versions unconditionally. One example of this can be UWP APIs which are Microsoft's "new way of writing APIs". Our new graphics abstraction (RHI) can also rely on newer features being available on Windows - 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 Br, Olli [1] https://lists.qt-project.org/pipermail/development/2019-March/035532.html [2] https://bugreports.qt.io/browse/QTBUG-74687 ___ Interest mailing list inter...@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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. Philippe On Thu, 11 Jun 2020 14:41:34 +0200 Oliver Wolff wrote: > 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 discussions > about this topic on the corresponding bug report [2] > > 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 security updates and instances running Windows 7 should > be replaced as soon as possible. > > With this official Microsoft standing in mind our current plan is to > remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is > planned towards the end of 2020, roughly one year after Windows 7s end > of life. > > Of course, we do not make decisions like this easily or to upset our > users but there are clear advantages that speak in favor of dropping > support: > - We can rely on Windows functions being available instead of > trying to dynamically load libraries which might or might not be available. > - We can use functionality that only became available in later > Windows versions unconditionally. One example of this can be UWP APIs > which are Microsoft's "new way of writing APIs". Our new graphics > abstraction (RHI) can also rely on newer features being available on > Windows > - 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 > > Br, Olli > > > [1] > https://lists.qt-project.org/pipermail/development/2019-March/035532.html > [2] https://bugreports.qt.io/browse/QTBUG-74687 > ___ > Interest mailing list > inter...@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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 don't move resources from Win10 to Win7. The Windows team is already spread pretty thin and there's many QPA bugs to fix. Win10 shouldn't suffer at the expense of legacy. Besides, Qt 5.15 is supported until 2023 too. If Microsoft ever extends paid-support further I suggest Qt 5.15 is extended too. Regards, Sérgio M. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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 initially launched in 2009 and reached its > >> official end of life in January 2020. That means that Microsoft no > >> longer provides security updates and instances running Windows 7 should > >> be replaced as soon as possible. > >> > >> Br, Olli > > > > Dear Oliver, > > > > The fact is that Windows-7 is supported at least till 2023. > > > > Please, correct your fact table. > > > > https://www.microsoft.com/microsoft-365/partners/news/article/announcing-paid-windows-7-extended-security-updates > > > It's true that Microsoft offers extended support for Windows 7. This > support does not come for free though and there is a price tag attached. > > I think the same might apply inside The Qt Company. If you are a > commercial customer and want to buy extended support for Qt beyond > regular support availability periods, please get in touch with your > Sales representative. If you remove Win-7 from Qt-6, your suggested option of support for commercial customers will be void for Qt-6. After removal, it will be a mess to re-introduce it back whatever money you will be paid. Period. Full-Stop. Qt-6 will have less attractiveness for those bodies that need Win-7: governments, corporates, military, health, insurance, finance, banks and their suppliers. At least talk to your Sales prior to doing it since they have a better smell for money. If Microsoft smells the money - think twice if you'd like to lose this market in Qt-6. Kind regards, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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. That means that Microsoft no longer provides security updates and instances running Windows 7 should be replaced as soon as possible. Br, Olli Dear Oliver, The fact is that Windows-7 is supported at least till 2023. Please, correct your fact table. https://www.microsoft.com/microsoft-365/partners/news/article/announcing-paid-windows-7-extended-security-updates It's true that Microsoft offers extended support for Windows 7. This support does not come for free though and there is a price tag attached. I think the same might apply inside The Qt Company. If you are a commercial customer and want to buy extended support for Qt beyond regular support availability periods, please get in touch with your Sales representative. BR, Olli Kind regards, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] Windows 7 support will be dropped in Qt 6
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 security updates and instances running Windows 7 should > be replaced as soon as possible. > > Br, Olli Dear Oliver, The fact is that Windows-7 is supported at least till 2023. Please, correct your fact table. https://www.microsoft.com/microsoft-365/partners/news/article/announcing-paid-windows-7-extended-security-updates Kind regards, Robert ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
> 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, Norway paul.wick...@qt.io +47 90 500 666 https://qt.io The Future is Written with Qt -- ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Windows 7 support will be dropped in Qt 6
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 discussions about this topic on the corresponding bug report [2] 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 security updates and instances running Windows 7 should be replaced as soon as possible. With this official Microsoft standing in mind our current plan is to remove support for Windows 7 in Qt 6.0 onwards. Qt 6.0 release is planned towards the end of 2020, roughly one year after Windows 7’s end of life. Of course, we do not make decisions like this easily or to upset our users but there are clear advantages that speak in favor of dropping support: - We can rely on Windows functions being available instead of trying to dynamically load libraries which might or might not be available. - We can use functionality that only became available in later Windows versions unconditionally. One example of this can be UWP APIs which are Microsoft's "new way of writing APIs". Our new graphics abstraction (RHI) can also rely on newer features being available on Windows - 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 Br, Olli [1] https://lists.qt-project.org/pipermail/development/2019-March/035532.html [2] https://bugreports.qt.io/browse/QTBUG-74687 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
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 needed anyhow to support pre-C11 compilers. Qt itself can stop using them in C++ code (switching over static_assert). And I'd say that C++ mode we can assume static_assert presence everywhere, although the compiler detection will still be needed for C. Whether the macros should be documented or not: I keep asking, are they supposed to be public API? My answer is more towards a "no", but given we're keeping them around anyhow for C, I'd say to keep them working also for C++. Maybe we can use some trick to raise a warning for C++ code, but the maintenance burden for the C++ version is going to be 0. A data point: KDE has (only) ~30 hits of Q_STATIC_ASSERT. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
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 now. Adding a deprecation warning to the macros is something we probably can do sometime later in 6.x when people are not porting over from 5.15 anymore. Cheers, Lars > On 11 Jun 2020, at 12:46, Marc Mutz via Development > wrote: > > 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 > use-case) or document-to-obsolete them. They weren't documented for 16 out of > the 16 Qt 5 releases. Why then should we document the thing in 5.15.1? And, > pretty please, decide NOW! > > When and if we remove the Q_STATIC_ASSERT macros, there will hopefully be a > [ChangeLog]. That's a much more fitting place for a macro deprecation/removal > notice. We can reasonably expect people to read these. Who, otoh, would go to > the API reference to look at macro definitions to see which ones are new > \obsolete. That makes no sense. > > Thanks, > Marc > > On 2020-06-11 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 know of no way to tell the compiler to >> warn about their use, so the only deprecation we can do is in the >> documentation - that doesn't yet exist; that's what [0] is seeking to >> fix. So the deprecation would simply be a matter of marking them >> \obsolete; in 5.15, we can mark the two-arg form as obsolete (since >> static_assert(cond, msg) exists in C++11) but not the single-arg form. >> [0] https://codereview.qt-project.org/c/qt/qtbase/+/303218 >> I also note that there's non-trivial #if-ery, still on dev, to support >> compilers/platforms on which static_assert isn't available. I have to >> suppose that is redundant, given that we expect a C++11 compiler in 5.15 >> and static_assert() is a compiler feature, not a standard library one >> (where we allow some gaps on C++11, IIUC). So does anyone believe that >> #if-ery is actually still needed - i.e. does anyone believe there is a >> platform for which Q_COMPILER_STATIC_ASSERT *doesn't* get defined in >> qcompilerdetection.h ? >> Assuming there's no such platform, I propose to rip out (from both dev >> and 5.15) Q_COMPILER_STATIC_ASSERT on the premise that it's always >> defined and we can always use static_assert (or, in C, _Static_assert). >> 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. >> Are there any compelling reasons to just document these macros and >> retain them, without marking as \obsolete in the docs ? >> Eddy. >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
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 use-case) or document-to-obsolete them. They weren't documented for 16 out of the 16 Qt 5 releases. Why then should we document the thing in 5.15.1? And, pretty please, decide NOW! When and if we remove the Q_STATIC_ASSERT macros, there will hopefully be a [ChangeLog]. That's a much more fitting place for a macro deprecation/removal notice. We can reasonably expect people to read these. Who, otoh, would go to the API reference to look at macro definitions to see which ones are new \obsolete. That makes no sense. Thanks, Marc On 2020-06-11 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 know of no way to tell the compiler to warn about their use, so the only deprecation we can do is in the documentation - that doesn't yet exist; that's what [0] is seeking to fix. So the deprecation would simply be a matter of marking them \obsolete; in 5.15, we can mark the two-arg form as obsolete (since static_assert(cond, msg) exists in C++11) but not the single-arg form. [0] https://codereview.qt-project.org/c/qt/qtbase/+/303218 I also note that there's non-trivial #if-ery, still on dev, to support compilers/platforms on which static_assert isn't available. I have to suppose that is redundant, given that we expect a C++11 compiler in 5.15 and static_assert() is a compiler feature, not a standard library one (where we allow some gaps on C++11, IIUC). So does anyone believe that #if-ery is actually still needed - i.e. does anyone believe there is a platform for which Q_COMPILER_STATIC_ASSERT *doesn't* get defined in qcompilerdetection.h ? Assuming there's no such platform, I propose to rip out (from both dev and 5.15) Q_COMPILER_STATIC_ASSERT on the premise that it's always defined and we can always use static_assert (or, in C, _Static_assert). 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. Are there any compelling reasons to just document these macros and retain them, without marking as \obsolete in the docs ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Switch the main "Qt Build System"
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 don't intend to develop it, you can use >>> the regular, release builds made by others. >> Mhh but that only works if your system have packaged the same Qt version >> isn't it ? I'm talking about future changes/new features of moc which >> might be needed by newer Qt versions. > See my reply to Bogdan. We should not require exact same version. We may need > to require "not newer" > > Qt needs to continue supporting older moc-generated code that was compiled > into libraries and applications and ditto for rcc, uic. So there's little > reason why the version of those tools has to be the exact same. > > Being newer could be a problem. > +1 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?
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 replace QtWebEngine on platforms with >> no "native" browser component, it might make sense. > > I couldn't yet find a description of the reason(s) behind QtWebView, but > given the similarity between the WebView classes from it and from QtWebkit > you'd almost think that QtWebView was written as a replacement that uses > QtWebEngine as a backend unless it shouldn't (and that seems to be only on > Mac). 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. There is similarity between QtWebView's and QtWebKit's WebView QML types, however it happens because all powerful features of QtWebKit's WebView are located in WebView.experimental. Note that QtWebEngine provides WebEngineView type which is also quite similar. > > There's no such thing as a native browser component on Linux. Maybe if you > look at the DE level that GNOME has such a thing ... and using that would > probably mean reopening a discussion we had before (about webkit2-gtk) ;) > > Is possible in QML to "proxy" QtWebkit's WebView class, adding just the few > missing things to it, without taking a significant performance hit? It's possible to extend any QML item in QML, or inherit from underlying C++ class and register it as a new QML type. Out of curiosity, what do you want to add there? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
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 know of no way to tell the compiler to
warn about their use, so the only deprecation we can do is in the
documentation - that doesn't yet exist; that's what [0] is seeking to
fix. So the deprecation would simply be a matter of marking them
\obsolete; in 5.15, we can mark the two-arg form as obsolete (since
static_assert(cond, msg) exists in C++11) but not the single-arg form.
[0] https://codereview.qt-project.org/c/qt/qtbase/+/303218
I also note that there's non-trivial #if-ery, still on dev, to support
compilers/platforms on which static_assert isn't available. I have to
suppose that is redundant, given that we expect a C++11 compiler in 5.15
and static_assert() is a compiler feature, not a standard library one
(where we allow some gaps on C++11, IIUC). So does anyone believe that
#if-ery is actually still needed - i.e. does anyone believe there is a
platform for which Q_COMPILER_STATIC_ASSERT *doesn't* get defined in
qcompilerdetection.h ?
Assuming there's no such platform, I propose to rip out (from both dev
and 5.15) Q_COMPILER_STATIC_ASSERT on the premise that it's always
defined and we can always use static_assert (or, in C, _Static_assert).
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.
Are there any compelling reasons to just document these macros and
retain them, without marking as \obsolete in the docs ?
That's right, Q_STATIC_ASSERT was introduced before C++11 support was required
in Qt and since C++11 is required, its use is counter productive because one
get worse error message due to the fact that it is a macro indirection.
(even the fact that one does not need a message in it is not a good reason to
use it instead of static_assert(foo, "...");)
With a bit of creativity, it is not too difficult to find a way to show a
compiler warning on its use. For example:
[[deprecated]] constexpr bool Q_STATIC_ASSERT_IS_DEPRECATED(){
return true;
}
#define Q_STATIC_ASSERT(cond) static_assert(Q_STATIC_ASSERT_IS_DEPRECATED() &&
cond)
--
Olivier
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Deprecating Q_STATIC_ASSERT_X and Q_STATIC_ASSERT
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 about their use, so the only deprecation we can do is in the documentation - that doesn't yet exist; that's what [0] is seeking to fix. So the deprecation would simply be a matter of marking them \obsolete; in 5.15, we can mark the two-arg form as obsolete (since static_assert(cond, msg) exists in C++11) but not the single-arg form. [0] https://codereview.qt-project.org/c/qt/qtbase/+/303218 I also note that there's non-trivial #if-ery, still on dev, to support compilers/platforms on which static_assert isn't available. I have to suppose that is redundant, given that we expect a C++11 compiler in 5.15 and static_assert() is a compiler feature, not a standard library one (where we allow some gaps on C++11, IIUC). So does anyone believe that #if-ery is actually still needed - i.e. does anyone believe there is a platform for which Q_COMPILER_STATIC_ASSERT *doesn't* get defined in qcompilerdetection.h ? Assuming there's no such platform, I propose to rip out (from both dev and 5.15) Q_COMPILER_STATIC_ASSERT on the premise that it's always defined and we can always use static_assert (or, in C, _Static_assert). 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. Are there any compelling reasons to just document these macros and retain them, without marking as \obsolete in the docs ? Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Patching QtWebView to use QtWebkit "rebooted"?
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" browser component, it might make sense. I couldn't yet find a description of the reason(s) behind QtWebView, but given the similarity between the WebView classes from it and from QtWebkit you'd almost think that QtWebView was written as a replacement that uses QtWebEngine as a backend unless it shouldn't (and that seems to be only on Mac). There's no such thing as a native browser component on Linux. Maybe if you look at the DE level that GNOME has such a thing ... and using that would probably mean reopening a discussion we had before (about webkit2-gtk) ;) Is possible in QML to "proxy" QtWebkit's WebView class, adding just the few missing things to it, without taking a significant performance hit? R. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
