Re: [Development] On deprecating functions
Am 05.03.2019 um 11:53 schrieb Tor Arne Vestbø: On 5 Mar 2019, at 11:27, Giuseppe D'Angelo via Development wrote: Il 05/03/19 08:14, Lars Knoll ha scritto: One solution I thought about is to replace the QT_DEPRECATED(_X) macros with something that also contains the version (similar to QT_DEPRECATED_SINCE). Then the user could define how current he wants to be, and we could set a reasonable default going e.g. one LTS back. I'd go with this one. Should make everyone happy. Can anyone see any adverse effect? I also prefer this one. Here a possible implementation for discussion, tested with the new QComboBox changes: https://codereview.qt-project.org/255051 Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros
On Tuesday, 5 March 2019 06:52:27 PST Gatis Paeglis wrote: > "This library is present on all supported platforms." Please note the implication on this: the Linux distribution you're using is NOT a supported one. The commit removing xkbcommon explicitly says so: http://code.qt.io/cgit/qt/qtbase.git/commit/? id=c3a963da1f9e7b1d37e63eedded61da4fbdaaf9a Having libxkbcommon in 3rdparty sources is not necessary anymore, after RHEL 6.6 was removed from the list of supported platforms for Qt 5.12. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros
> library doesn't provide another way to build itself. libxkbcommon changelog for 0.7.2 https://lists.freedesktop.org/archives/wayland-devel/2017-August/034721.html "Added a Meson build system as an alternative to existing autotools build system. The intent is to remove the autotools build in one of the next releases. Please try to convert to it and report any problems." libxkbcommon changelog for 0.8.3 https://lists.freedesktop.org/archives/wayland-devel/2019-February/039970.html: "Build note: We've had a report that the autotools build doesn't work with the new version of Bison, 3.3. If this happens to you, please switch to using meson. The autotools build will be removed in libxkbcommon 0.9.0." Note that 0.9.0 does not exist, so even the current master branch still can be built with auto tools. > Unless I misunderstand something this change hits older linuxes real hard. Current minimal required version by Qt is 0.5.0 and only really old distros do not have it. And to quote the commit message that removed the library from bundled sources: "This library is present on all supported platforms." From: Development on behalf of NIkolai Marchenko Sent: Tuesday, March 5, 2019 3:36 PM To: Qt development mailing list Subject: [Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros - [QTBUG-65503] Removed xkbcommon from bundled sources. This library is present on all supported platforms. The minimal required version now is 0.5.0. The change above makes updating Qt a gargantuan task for Centos 6 at least. Building xkbcommon there requires meson (which centos 6 doesn't have) and python 3.5 (same). And the library doesn't provide another way to build itself. Unless I misunderstand something this change hits older linuxes real hard. Is it really necessary? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] forcing libxkbcommon to be present in the system makes newer Qt unusable on older linux distros
- [QTBUG-65503] Removed xkbcommon from bundled sources. This library is present on all supported platforms. The minimal required version now is 0.5.0. The change above makes updating Qt a gargantuan task for Centos 6 at least. Building xkbcommon there requires meson (which centos 6 doesn't have) and python 3.5 (same). And the library doesn't provide another way to build itself. Unless I misunderstand something this change hits older linuxes real hard. Is it really necessary? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
> On 5 Mar 2019, at 11:27, Giuseppe D'Angelo via Development > wrote: > > Il 05/03/19 08:14, Lars Knoll ha scritto: >> One solution I thought about is to replace the QT_DEPRECATED(_X) macros with >> something that also contains the version (similar to QT_DEPRECATED_SINCE). >> Then the user could define how current he wants to be, and we could set a >> reasonable default going e.g. one LTS back. > > I'd go with this one. Should make everyone happy. Can anyone see any adverse > effect? I also prefer this one. This is also how Apple tags their functions, eg: - (void)cacheImageInRect:(NSRect)rect NS_DEPRECATED_MAC(10_0, 10_13, "This method shouldn’t be used as it doesn’t work in all drawing situations; instead, a subview should be used that implements the desired drawing behavior"); The first argument is when the function was introduced, and the second argument when it was deprecated. They also use a special soft deprecation version named API_TO_BE_DEPRECATED that’s just a very high version number. See https://asciiwwdc.com/2018/sessions/209 for a discussion about this, and these headers: https://gist.github.com/torarnv/5f76f09a46ccc94e034fdec62b855e9e https://raw.githubusercontent.com/phracker/MacOSX-SDKs/master/MacOSX10.13.sdk/usr/include/AvailabilityInternal.h Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
Il 05/03/19 08:14, Lars Knoll ha scritto: One solution I thought about is to replace the QT_DEPRECATED(_X) macros with something that also contains the version (similar to QT_DEPRECATED_SINCE). Then the user could define how current he wants to be, and we could set a reasonable default going e.g. one LTS back. I'd go with this one. Should make everyone happy. Can anyone see any adverse effect? 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] On deprecating functions
On Tuesday, March 5, 2019 8:14:00 AM CET Lars Knoll wrote: > One solution I thought about is to replace the QT_DEPRECATED(_X) macros with > something that also contains the version (similar to QT_DEPRECATED_SINCE). > Then the user could define how current he wants to be, and we could set a > reasonable default going e.g. one LTS back. > > So use something like > > QT_WARN_DEPRECATED(5,13) void myDeprecatedFunction() > > And expand it to wither QT_DEPRECATED or nothing depending on the version > limit set. I believe there is also an alternative of making something like that: QT_BEGIN_DEPRECATED_SINCE(5, 12, 123) ... QT_DEPRECATED void foo(); QT_DEPRECATED void bar(); ... QT_END_DEPRECATED_SINCE(5, 12, 123) Begin and end of a block would conditionally disable and enable the deprecation warning. I think that QT_WARN_DEPRECATED(5,13) idea is better, but the block version is a bit easier from scripting perspective. Cheers, Jędrek ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
On Mon, 4 Mar 2019 22:27:42 +0100 André Pönitz wrote: > (5) Use #if (QT_VERSION / QT_VERSION_CHECK. To "fix" perfectly > valid code *for cosmetical reasons*? DUH! Example: https://codereview.qt-project.org/#/c/252715/1 was necessary because of the immediate deprecation of an existing function when a nicer looking replacement was introduced. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On deprecating functions
> On 4. Mar 2019, at 22:27, André Pönitz wrote:
>
> On Mon, Mar 04, 2019 at 05:51:08PM +0100, Christian Ehrlicher wrote:
>> Hi,
>>
>> I recently introduced some new signals
>> (Q(Double)SpinBox::textChanged, QComboBox::textActivated) as
>> replacements for old ones to be able to avoid the use of
>> QOverload<>::of in Qt6 and to better match their respective
>> properties.
>
>> Within those changes I also marked the old signals as deprecated
>> with QT_DEPRECATED so the developer gets an information to no
>> longer use this function in new code.
>
>> This lead to a lot of warnings in old code which needs to be
>> compiled with 5.9 and 5.12 (e.g. in QtCreator) which can't be
>> fixed because there the new function is not yet available. It was
>> requested to remove the QT_DEPRECATED decoration until e.g. 5.15.
>> but I think then it's too later to be able to remove them with
>> Qt6.
>
> Yonder Old Code is kind of actively maintained, and to play its
> role as guinea pig for Qt itself it makes sense to compile it with
> Qt dev at times. I completely agree that the overloaded signals are
> mildly annoying, and getting rid of them in the medium term is a
> worthy goal by itself. So I certainly appreciate the introduction
> of the non-overloaded text* versions, but what is going on top of
> that currently is what I'd call tr("Throw out the baby with the
> bath water").
>
> The issue at hand is purely cosmetical. Either use of static_cast
> or QOverload or qOverload is at most one extra line in user code
> that will only ever be witnessed by someone looking directly at
> those parts of the code. It's unfortunately a safe assumption that
> in this particular case this might be one or less persons worldwide.
>
> All possible workarounds that I am aware of (some of them even
> being actively suggested as possible solution) are worse than that:
>
> (1) Do not do anything: Anyone compiling the code will get the
> warning. That's at least a dozen dayly, i.e. more than a magnitude
> worse. Duh. (1a) Some people compile with -Werror. While I will
> happily argue that they deserve the outcome for unrelated reasons,
> this still makes it: Duh!
>
> (2) Replace the (QString) overloads with the (int) overloads and do
> the data extraction manually. Given that Qt is about making coding
> convenient and this is less convenient than before: Duh.
>
> (3) Only suppport Qt dev of the day. Hard sell to users and
> distributors, a.k.a. "Duh!"
>
> (4) Only support a reasonably safe, a.k.a "antique", version of Qt.
> Hard sell for various reasons, one of them is failing to play the
> guinea pig role. DUH.
>
> (5) Use #if (QT_VERSION / QT_VERSION_CHECK. To "fix" perfectly
> valid code *for cosmetical reasons*? DUH!
>
> Having *some* grace period for peaceful co-existence makes sense to
> me. We can have a round of bikeshedding on what that period should
> look like, but the very existence of LTS releases suggests that it
> is ok for people to stick to LTS only.
> Qt Creator actually uses
> "last LTS minus one minor release" so far,
Just to clarify for Qt Creator I’m using something like min(last LTS, last
released - 1), i.e. we’d like Qt Creator to be compilable with the latest LTS,
but at least 2 released Qt versions. (And Qt version requirements are only
increased for the next minor release, of course not patch releases.)
> so asking for "last LTS"
> is already a kind of concession. Truly personally, I'd even go for
> "no deprecation at all *for purely cosmetical reasons*" as I've seen
> too many taking route (5) because it was perceived too much effort
> to keep up with "random" changes in Qt, but that's a different story.
>
>> See https://codereview.qt-project.org/252208 for the discussion
>> and a possible solution here:
>> https://codereview.qt-project.org/#/c/254909/
>>
>> So what's the correct way to deprecate a function and not
>> forgetting about QT_DEPRECATED later on as it happened with a lot
>> of functions during Qt4 times?
>
> Currently there's apparently no agreed policy beyond the usual
> "submit a patch and find someone to +2 it".
>
> The one I suggested in https://codereview.qt-project.org/#/c/254909/
> makes sure that it is noticed at some time, and at that time there
> was some period in between where people had a reasonable chance to
> update their code base without facing immediate regressions. I
> still don't think that is asked too much for a solution to a truly
> cosmetical issue.
>
> Andre'
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
--
Eike Ziller
Principal Software Engineer
The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin
eike.zil...@qt.io
http://qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB
144331 B
___
Development
