D25563: Remove -std=c++0x flag and duplicated -Wall flag

This revision was automatically updated to reflect the committed changes. Closed by commit R290:d6a6c210b0d1: Remove -std=c++0x flag and duplicated -Wall flag (authored by kossebau). REPOSITORY R290 KPackage CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25563?vs=70408=70412

D25563: Remove -std=c++0x flag and duplicated -Wall flag

kossebau created this revision. kossebau added reviewers: Frameworks, apol, mart. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. kossebau requested review of this revision. REVISION SUMMARY -Wall is set by KDECompilerSettings (via

D25311: Add KColumnHeadersProxyModel

kossebau added a comment. Two more nitpicks while this has my attention (sadly no time/idea to comment on the general usefulness) :) INLINE COMMENTS > kcolumnheadersmodel.h:57 > +void setSourceModel(QAbstractItemModel *newSourceModel); > +Q_SIGNAL void sourceModelChanged(); > + For

D25545: Rename signal for avoiding overload signal

kossebau added inline comments. INLINE COMMENTS > Doxyfile.local:4 > +# define so that deprecated API is not skipped > +PREDEFINED += \ > +"KCOREADDONS_ENABLE_DEPRECATED_SINCE(x, y)=1" \ The predefined macros we want to tell doxygen about in the case of kapidox (being run in a non-build

D25561: Remove unused signal we can use directly "signal(const QUrl&)

kossebau added a comment. Looks correct from deprecation-markup POV. Did you do a test build with EXCLUDE_DEPRECATED_BEFORE_AND_AT=5.65.0, to check if any tests or examples still use the deprecated signals and need some additions of #if KWIDGETSADDONS_ENABLE_DEPRECATED_SINCE(5, 65) in

D25545: Rename signal for avoiding overload signal

kossebau added a comment. In D25545#568090 , @dfaure wrote: > Looks good to me. Friedrich, what did we conclude about deprecating signals? From https://phabricator.kde.org/D24466#547023 & ff. I took with me that deprecating signals like

D25311: Add KColumnHeadersProxyModel

kossebau added inline comments. INLINE COMMENTS > kcolumnheadersmodel.cpp:22 > + > +class KColumnHeadersModel::Private > +{ Instead of using a nested class Private, consider using a non-nested KColumnHeadersModelPrivate class. Otherwise you want to tag this class to not inherit the symbol

D25546: Deprecate KRecursiveFilterProxyModel

kossebau added a comment. Looks good, besides nitpicks :) INLINE COMMENTS > krecursivefilterproxymodel.cpp:22 > > +#if KITEMMODELS_ENABLE_DEPRECATED_SINCE(5, 65) > #include This should be KITEMMODELS_BUILD_DEPRECATED_SINCE (BUILD., not ENABLE) > krecursivefilterproxymodel.h:28 > >

D24695: Add a KF6 TODO to make KXMLGUIClient generic over a state enum

kossebau added a comment. IMHO such idea notes should also be put into the source file or, better, a separate TODO file in the toplevel source, not the header (which is going to be deployed as part of devel-packages), as this note is uninteresting to users of current KXMLGUIClient.

D24349: More (and last) fixes to compile without implicit conversion from ASCII/ByteArray

kossebau edited reviewers, added: Frameworks; removed: kossebau. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24349 To: ahmadsamir, dfaure, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25059: KPluginSelector: use new KAboutPluginDialog

This revision was automatically updated to reflect the committed changes. Closed by commit R295:918978c7e26e: KPluginSelector: use new KAboutPluginDialog (authored by kossebau). REPOSITORY R295 KCMUtils CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25059?vs=69004=70260 REVISION

D25063: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog

kossebau marked an inline comment as done. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D25063 To: kossebau, #frameworks, apol, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25063: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog

This revision was automatically updated to reflect the committed changes. Closed by commit R244:e8f558f8b2c7: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog (authored by kossebau). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D25063?vs=69017=70259#toc

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

This revision was automatically updated to reflect the committed changes. kossebau marked 2 inline comments as done. Closed by commit R263:415402081d92: Add KAboutPluginDialog, to be used with KPluginMetaData (authored by kossebau). CHANGED PRIOR TO COMMIT

D25489: Deprecate KonqBookmarkMenu and KonqBookmarkContextMenu

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Seems fine by pure patch reading. INLINE COMMENTS > konqbookmarkmenu.h:51 > * @param collec parent collection for the KActions. > */ > +KBOOKMARKS_DEPRECATED_VERSION(5,

D25489: Deprecate KonqBookmarkMenu and KonqBookmarkContextMenu

kossebau added a comment. That should be upcoming 5.65 here though, not 5.64. Moving things into visibility-protection guards of recent versions will break things for people who used DISABLE_DEPRECATED_BEFORE_AND_AT after having properly checked their source is properly building against

D25444: Fix assistant dialog margins

kossebau added inline comments. INLINE COMMENTS > kassistantdialog.cpp:102 > +q->pageWidget()->layout()->setContentsMargins( > +q->pageWidget()->style()->pixelMetric(QStyle::PM_LayoutLeftMargin), > +q->pageWidget()->style()->pixelMetric(QStyle::PM_LayoutTopMargin), Ideally

D25010: [StatJob] Use A QFlag to specify the details returned by StatJob

kossebau added a comment. Ah, EXCLUDE_DEPRECATED_BEFORE_AND_AT is not yet available with KIO (compare the TODO next to the ecm_generate_export_header call). So as result also the BUILD macros are not available. Using instead the ENABLE macros in the sources of the library instead does not

D25010: [StatJob] Use A QFlag to specify the details returned by StatJob

kossebau added inline comments. INLINE COMMENTS > directorysizejob.cpp:137 > KIO::ListJob *listJob = KIO::listRecursive(url, KIO::HideProgressInfo); > -listJob->addMetaData(QStringLiteral("details"), QStringLiteral("3")); > +#if KIOCORE_ENABLE_DEPRECATED_SINCE(5, 65) > +// TODO KF6:

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

kossebau updated this revision to Diff 70052. kossebau marked 2 inline comments as done. kossebau added a comment. Update to first review by @dfaure REPOSITORY R263 KXmlGui CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25058?vs=69002=70052 BRANCH addaboutplugindialog

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

kossebau marked 3 inline comments as done. kossebau added inline comments. INLINE COMMENTS > dfaure wrote in kaboutplugindialog.cpp:119 > (I'm surprised by the explicit '&' in all those labels, doesn't > KAcceleratorManager take care of this automatically?) Seems it does. So removing then

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

kossebau added a comment. In D24990#564670 , @dfaure wrote: > So we need to set FOO_DISABLE_DEPRECATED_BEFORE_AND_AT to N-1 while building FOO itself, right? Either magically here, or manually in every module... Nono,

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

kossebau added a comment. Hm, only noticed now that this actually has an unwanted sideeffects: it triggers deprecation warnings for all deprecated warning also inside each library itself. Which is not what one wants. Because so far FOO_DISABLE_DEPRECATED_BEFORE_AND_AT as set while

D25401: Fix deprecation syntax in ktcpsocket.h

kossebau added a comment. One thing I saw with the Qt deprecation tags is that deprecation attributes were only added to constructor calls, not the class itself. Which to me made some sense, as one should be warned when creating instances of that class. But once you are passed an instance

D25364: KNumberModel: gracefully handle a stepSize of 0

This revision was automatically updated to reflect the committed changes. Closed by commit R275:13a039441fdb: KNumberModel: gracefully handle a stepSize of 0 (authored by kossebau). REPOSITORY R275 KItemModels CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D25364?vs=69909=69916

D25364: KNumberModel: gracefully handle a stepSize of 0

kossebau created this revision. kossebau added reviewers: Frameworks, davidedmundson, vkrause. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. kossebau requested review of this revision. REVISION SUMMARY While setting a stepSize of 0 is undefined in the API

D25323: [text thumbnail] Force Syntax Highligthing when no definition for file was found

kossebau added a comment. In D25323#562989 , @meven wrote: > In D25323#562908 , @kossebau wrote: > > > Thanks for looking at the issue. No time to look closer the next days, but curious about this

D25323: [text thumbnail] Force Syntax Highligthing when no definition for file was found

kossebau added a comment. Also am I wonfering how this relates to the bug report you referred to? Can you tell what effect your code change has on the symptoms reported in https://bugs.kde.org/show_bug.cgi?id=409380#c0 ? REPOSITORY R320 KIO Extras REVISION DETAIL

D25323: [text thumbnail] Force Syntax Highligthing when no definition for file was found

kossebau added a comment. Thanks for looking at the issue. No time to look closer the next days, but curious about this partial change (which has been discussed before and discarded): changing `QColor ( 245, 245, 245 ); // light-grey background ` to

Re: Quick Charts in KDE Review

Am Montag, 21. Oktober 2019, 15:22:23 CET schrieb Arjen Hiemstra: > Hi, > > Quick Charts has been moved to KDE review. The intent is to make it a > Tier 1 framework. Any chance the official name can be "KQuickCharts"? "Quick Charts" is a generic name which only asks for being misunderstood, is

Re: HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

Am Mittwoch, 6. November 2019, 16:13:28 CET schrieb David Edmundson: > >Any chance this is about KGamma and you ran clazy with a Qt 5.14 copy > >locally? > It was! Okay :) So no new holes to fix then discovered. > >So here repeating the recommendation done by a few, which project > >maintainers

Re: HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

Am Mittwoch, 6. November 2019, 14:14:41 CET schrieb David Edmundson: > I just found a slight issue when using _DEPRECATED_SINCE. > > If one of two overloaded Q_SIGNALS is deprecated, clazy will blindly > port the signal without an overload as to the compiler only one signal > exists. This then

Re: HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

Am Mittwoch, 6. November 2019, 14:14:41 CET schrieb David Edmundson: > I just found a slight issue when using _DEPRECATED_SINCE. > > If one of two overloaded Q_SIGNALS is deprecated, clazy will blindly > port the signal without an overload as to the compiler only one signal > exists. This then

D24979: KRunner: port away from deprecated KF5 API

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R308:7bbd29591094: KRunner: port away from deprecated KF5 API (authored by dfaure, committed by kossebau). CHANGED PRIOR

D24979: KRunner: port away from deprecated KF5 API

kossebau commandeered this revision. kossebau edited reviewers, added: dfaure; removed: kossebau. kossebau added a comment. This revision now requires review to proceed. @dfaure I allow myself to take over here given your are off the next days and I would like to get this off the table :)

D24979: KRunner: port away from deprecated KF5 API

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Untested, but looks okay, besides the unneeded #f in the sources. INLINE COMMENTS > abstractrunner.cpp:327 > > +#if PLASMA_ENABLE_DEPRECATED_SINCE(5, 28) // Plasma::Package is

HEADS-UP: from now do new deprecations in KF API by *_DEPRECATED_* macros only using upcoming version number

Hi, with KF 5.64 now branched and thus the new deprecation macros going to be released for the first time, now please make sure when in the future marking API as deprecated to use the correct current version, i.e. the one where the deprecation will be made public the first time. So if pushing

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

This revision was automatically updated to reflect the committed changes. Closed by commit R240:879769daf047: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings (authored by kossebau). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

kossebau added a comment. Merci, will land later tonight. Bonnes vacances :) REPOSITORY R240 Extra CMake Modules BRANCH enableallqtkfdeprecationwarningsforframeworks REVISION DETAIL https://phabricator.kde.org/D24990 To: kossebau, #frameworks, #build_system, apol, dfaure Cc: dfaure,

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

kossebau added a subscriber: dfaure. kossebau added a comment. @dfaure Hi. Any chance you you can sneak in before you are away (enjoy :) ) to remove the "-DQT_DEPRECATED_WARNINGS_SINCE=0x06" from all the KF modules in the next days? Otherwise would land this here with just the

D25039: Fix Clazy performance issues, const

kossebau added a comment. In D25039#557609 , @meven wrote: > Feel free to do the code removal, Done now, as I had the files still open. REPOSITORY R241 KIO BRANCH arcpatch-D25039 REVISION DETAIL https://phabricator.kde.org/D25039

D23801: Port kpac from QtScript

kossebau added inline comments. INLINE COMMENTS > carewolf wrote in script.cpp:316 > Sure, as I said, I only write it this way because a copy should be taken, and > while Qt can work around declaring an async argument as a reference, I still > consider it bad style to make that mistake. > >

D25039: Fix Clazy performance issues, const

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Not tested, only read code. Looks good to me. Please remove the newInstance method in a direct commit before, and drop change from this patch. (If you prefer, can do the remove commit

D25039: Fix Clazy performance issues, const

kossebau added inline comments. INLINE COMMENTS > ahmadsamir wrote in ftp.cpp:1376 > IIUC, the compiler will use a temporary object to hold the return of > tempurl.fileName(). > > The temporary is used to initialize filename, and then it's gone: > const QString filename = tempurl.filename(); >

D25039: Fix Clazy performance issues, const

kossebau added inline comments. INLINE COMMENTS > ftp.cpp:1376 > QString parentDir; > -QString filename = tempurl.fileName(); > +const QString = tempurl.fileName(); > Q_ASSERT(!filename.isEmpty()); `QUrl::fileName()` returns a value QString, so just const QString filename

D23801: Port kpac from QtScript

kossebau added inline comments. INLINE COMMENTS > carewolf wrote in script.cpp:316 > Invokables can be called asynchronously (queued), if you take a reference and > the isn't evaluated immediatly the reference might be invalid by the time the > call is evaluated. With queued signals, any

D23801: Port kpac from QtScript

kossebau added inline comments. INLINE COMMENTS > carewolf wrote in script.cpp:316 > Not really. I prefer to do it that way for invokable as the value will be > copied, but const ref works too. So why would it be preferable to have the value be copied there? In general, one prefers to avoid

D25039: Fix Clazy performance issues, const &, noexcept

kossebau added a comment. As excuse for bad drive-by comment, here now hopefully making up a bit by giving some in-detail review, please see in-line comments. No idea about exceptions. I would the noexcept also make a different commit, for more separation of concerns. When looking

D23801: Port kpac from QtScript

kossebau added inline comments. INLINE COMMENTS > script.cpp:316 > // @returns true if @p str matches the shell @p pattern > -QScriptValue ShExpMatch(QScriptContext *context, QScriptEngine *engine) > +Q_INVOKABLE QJSValue ShExpMatch(QString str, QString patternStr) > { Hi @carewolf . Curious:

D25039: Fix Clazy performance issues, const &, noexcept

kossebau added inline comments. INLINE COMMENTS > kossebau wrote in slavebase.h:351 > Would be a proper change, but sadly also changes the signature of a API under > ABI promise, so here and in all other public API places not possibe. > Can be only done when breaking the ABI with KF6. > >

D25039: Fix Clazy performance issues, const &, noexcept

kossebau added a comment. (Quick drive-by comment only as I had this in a search result...) INLINE COMMENTS > slavebase.h:351 > */ > -bool configValue(QString key, bool defaultValue) const; > +bool configValue(const QString , bool defaultValue) const; > Would be a proper

D25059: KPluginSelector: use new KAboutPluginDialog

kossebau added inline comments. INLINE COMMENTS > anthonyfieroni wrote in kpluginselector.cpp:799-803 > Can you guard for nullptr? The pluginEntry? That would be inconsistent with the rest of the code here, which does no such checks. We should be relatively safe here, as the slot should be

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Tired given the time, but let's see if I get things straight this time: Given KF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00, in the API of KConfig we just see

D24966: KXmlGui: port away from KF5 deprecated API

kossebau added a comment. To leave KAboutData::programIconData as a deprecated property and instead turn to use KPluginMetaData where the iconName property is undisputed in its usefullnes, I have now uploaded 3 patches for view; - D25063 : Add

D25063: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog

kossebau created this revision. kossebau added reviewers: Frameworks, apol, dfaure. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. kossebau requested review of this revision. REVISION SUMMARY Depends on D25058

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

kossebau added a dependent revision: D25063: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D25058 To: kossebau, #frameworks, apol, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh,

D25059: KPluginSelector: use new KAboutPluginDialog

kossebau created this revision. kossebau added reviewers: Frameworks, dfaure, apol. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. kossebau requested review of this revision. REVISION SUMMARY Depends on D25058

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

kossebau added a dependent revision: D25059: KPluginSelector: use new KAboutPluginDialog. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D25058 To: kossebau, #frameworks, apol, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D25058: Add KAboutPluginDialog, to be used with KPluginMetaData

kossebau created this revision. kossebau added reviewers: Frameworks, apol, dfaure. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. kossebau requested review of this revision. REVISION SUMMARY When showing an About dialog for a plugin, so far a

D24966: KXmlGui: port away from KF5 deprecated API

kossebau added a comment. Playing with reviving my programIconName undeprecation patch (by adding a new property iconName w/ setter/getter), and looking through the rest of the API, I though now think that we should keep KAboutData untouched and leave it for metadata about programs, while

D25010: [StatJob] Use A QFlag to specify the details returned by statJob

kossebau added inline comments. INLINE COMMENTS > kossebau wrote in statjob.h:181 > I wonder if this should not be rather a member of StatJob, instead of being > on generic KIO namespace level. > It feels unbalanced to have the enum being in the class, but a util flag set > not. Actually,

D25010: [StatJob] Use A QFlag to specify the details returned by statJob

kossebau added inline comments. INLINE COMMENTS > jobremotetest.cpp:70 > { > -KIO::Job *job = KIO::stat(url, KIO::StatJob::DestinationSide, 0, > KIO::HideProgressInfo); > +KIO::Job *job = KIO::stat(url, KIO::StatJob::DestinationSide, > KIO::StatJob::Basic, KIO::HideProgressInfo); >

D25010: [StatJob] Use A QFlag to specify the details returned by statJob

kossebau added inline comments. INLINE COMMENTS > statjob.h:96 > + > /** > * Selects the level of @p details we want. All deprecated API should be also wrapped in visibility controls., so same #if/#endif also here. Basic structure: if deprecated api should be visible to compiler

D25010: [StatJob] Use A QFlag to specify the details returned by statJob

kossebau added a comment. Now that is a quick turn-around, +1 for doing the work :) No time myself to look at this closely the next days, also not that much into KIO, but here some quick feedback with an API police hat on. Would be also good to have some patches which make use of

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

kossebau added a comment. As said, I do not think this would be "better" code. And it's violating a bit the goal of zero cost abstractions, given this adds runtime need which could be avoided compared to the old code. When using the I18N_NOOP, one has to know what you do and when you later

D24884: I18N_NOOP2 was deprecated but we can't replace by I18NC_NOOP as it expends it as 2 elements (context + text)

kossebau added a comment. Looking at deprecated API usage in Okteta, I came over the use of some use of I18N_NOOP2 as well. The use-case there though seems pretty fine to me, porting to I18NC_NOOP will complicate the logic without further need, as the context is the same for all strings in

D24999: [KIO::stat] Add a KF6 TODO to make details a Bitmask

kossebau added a comment. It's actually an approach to be preferred in such cases, as it moves some of the work to be done at creating KF6 and porting to its new API for users of KF to now and the time span until KF6, keeping the unavoidable hurdle at the actual KF5->KF6 change as small as

D24999: [KIO::stat] Add a KF6 TODO to make details a Bitmask

kossebau added a comment. Instead of the TODO one could already add an overload of the method now, and deprecate the current one. So that in KF6 times the deprecated could be dumped, and there would just be the preferred variant. REPOSITORY R241 KIO REVISION DETAIL

Re: [sysadmin/release-tools/frameworks/5.0] /: KF5: auto-increase QT_DISABLE_DEPRECATED_BEFORE when upgrading the min Qt version

Am Sonntag, 27. Oktober 2019, 11:26:51 CET schrieb David Faure: > On dimanche 27 octobre 2019 03:07:01 CET Friedrich W. H. Kossebau wrote: > > Am Freitag, 25. Oktober 2019, 00:35:46 CET schrieb David Faure: > > > On jeudi 24 octobre 2019 22:24:55 CEST Friedrich W. H. Kossebau

D24974: KService: fix kded compilation with -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00

kossebau added a comment. Alternatively kded could be build with additionally `-DKSERVICE_DISABLE_DEPRECATED_BEFORE_AND_AT=0x05`. So it will would be still hidden to anyone else who uses -DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x050x00 REPOSITORY R309 KService REVISION DETAIL

D24966: KXmlGui: port away from KF5 deprecated API

kossebau added a comment. Actually I have a WIP undeprecation patch somewhere, which reduced the deprecation to notes with setApplicationData/appliactionData, Guess I should pick this from the attic, clean up and share, REPOSITORY R263 KXmlGui REVISION DETAIL

D24990: KDEFrameworkCompilerSettings: enable all Qt % KF deprecation warnings

kossebau created this revision. kossebau added reviewers: Frameworks, Build System. Herald added projects: Frameworks, Build System. Herald added subscribers: kde-buildsystem, kde-frameworks-devel. kossebau requested review of this revision. REPOSITORY R240 Extra CMake Modules BRANCH

D24979: KRunner: port away from deprecated KF5 API

kossebau requested changes to this revision. kossebau added a comment. This revision now requires changes to proceed. One of the Interesting challenges with all the cross-library deprecation visibility control setup. Let me try to collect requirements: - Plasma::Package is part of

Re: [sysadmin/release-tools/frameworks/5.0] /: KF5: auto-increase QT_DISABLE_DEPRECATED_BEFORE when upgrading the min Qt version

Am Freitag, 25. Oktober 2019, 00:35:46 CET schrieb David Faure: > On jeudi 24 octobre 2019 22:24:55 CEST Friedrich W. H. Kossebau wrote: > > BTW, we want to also set > > > > -DQT_DEPRECATED_WARNINGS_SINCE=0x06 > > > > otherwise the deprecations done with

D24971: KCoreAddons: make programIconName() available to KConfigWidgets and KXmlGui

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. Good with me. REPOSITORY R244 KCoreAddons BRANCH master REVISION DETAIL https://phabricator.kde.org/D24971 To: dfaure, kossebau Cc: kde-frameworks-devel, LeGast00n, GB_2,

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added inline comments. INLINE COMMENTS > kossebau wrote in kstandardaction_p.h:103 > Hm, KStandardShortcut::SaveOptions_DEPRECATED_DO_NOT_USE should not be needed > to be used here. > Does the use of KF_DISABLE_DEPRECATED_BEFORE_AND_AT trigger this? If so, IMHO >

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added inline comments. INLINE COMMENTS > kstandardaction_p.h:103 > #if KCONFIGWIDGETS_BUILD_DEPRECATED_SINCE(5, 38) > -{ SaveOptions, KStandardShortcut::SaveOptions, "options_save_options", > I18N_NOOP(" Settings"), nullptr, nullptr }, > +{ SaveOptions,

D24971: KCoreAddons: make programIconName() available to KConfigWidgets and KXmlGui

kossebau added inline comments. INLINE COMMENTS > CMakeLists.txt:96 > add_definitions(-DQT_DEPRECATED_WARNINGS_SINCE=0x06) > +add_definitions(-DKF_DISABLE_DEPRECATED_BEFORE_AND_AT=0x053f00) > add_definitions(-DQT_NO_FOREACH) Given KCOreAddons does not link against other KF modules, this

D24971: KCoreAddons: make programIconName() available to KConfigWidgets and KXmlGui

kossebau added inline comments. INLINE COMMENTS > kaboutdata.h:944 > > -#if KCOREADDONS_ENABLE_DEPRECATED_SINCE(5, 2) > +#if KCOREADDONS_BUILD_DEPRECATED_SINCE(5, 2) > /** Possibly best to document why only BUILD, pointing out infrastructure code supporting legacy code needs to always

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added a comment. So seems I missed to make clear what I meant, next try :) The goal is: make clients (e.g. apps) which are still using this method to set the app icon aware by a compiler warning that they should port their code to use QApplication::setWindowIcon. For that we

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added a comment. In D24965#554393 , @dfaure wrote: > So basically we just use //KF6 TODO REMOVE for programIconName, but still use the macro around setProgramIconName? Works for me. Yes, remove the

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added a comment. This falls into a category I also saw elsewhere doing all the patches, where the same API is used from two sides: the client side, like application code, and the serving side, like infrastructure. While we want to tell the client side, stop using this and for

D24966: KXmlGui: port away from KF5 deprecated API

kossebau added a comment. For backward-compatibility, we want to support this still, no? See D24965#554354 REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D24966 To: dfaure, kossebau, elvisangelaccio, vkrause Cc:

D24965: KConfigWidgets: port away from KF5 deprecated API

kossebau added a comment. While being deprecated, there might be code still using it, and you are killing support for that now, which is backwards-incompatibel. IMHO the support should be kept. And we want to rather have a generic way to disable the warning here (still TODO to have

D24892: Fix usage of the new deprecation macros for assignIconsToContextMenu

kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land. In D24892#553597 , @vkrause wrote: > In D24892#552838 , @kossebau wrote: > > > Looks good.

Re: [sysadmin/release-tools/frameworks/5.0] /: KF5: auto-increase QT_DISABLE_DEPRECATED_BEFORE when upgrading the min Qt version

Am Donnerstag, 24. Oktober 2019, 22:16:47 CEST schrieb David Faure: > Git commit fb4639b0b5f2a51d124949d59b9a327bf66c8f04 by David Faure. > Committed on 24/10/2019 at 20:15. > Pushed by dfaure into branch 'frameworks/5.0'. > > KF5: auto-increase QT_DISABLE_DEPRECATED_BEFORE when upgrading the min

D24841: Use modern way to set the C/CXX standard

kossebau added a comment. In D24841#552842 , @vonreth wrote: > Where are those tests running? I'm only aware of https://build.kde.org/job/Frameworks/job/extra-cmake-modules/ The tests are currntly sadly skipped on CI, compare T11858

D24892: Fix usage of the new deprecation macros for assignIconsToContextMenu

kossebau added a comment. Looks good. Perfect would be if you tested KIconThemes with EXCLUDE_DEPRECATED_BEFORE_AND_AT set to hexnumber(5.64.0), to see if there is no internal usage still happening, like with autotests which might need to support such a build with

D24764: Deprecate KIconTheme::assignIconsToContextMenu

kossebau added a comment. As KIconThems supports EXCLUDE_DEPRECATED_BEFORE_AND_AT., you want to also wrap the implementation of assignIconsToContextMenu, with #if KICONTHEMES_BUILD_DEPRECATED_SINCE(5, 64) (look out for _BUILD_). Seems you are a candidate to answer the email

Heads-up for developers working _on_ KF modules: how to mark deprecated API from now on

Hi, tldr; For deprecated API of KDE Frameworks modules please use ECMGenerateExportHeader and the respective macros to mark & wrap deprecated API, otherwise the whole effort breaks down. Question: where would you expect the documentation for how to do this? The introduction of

D24261: Modernize code: use range-based for loop in more places

This revision was automatically updated to reflect the committed changes. Closed by commit R263:3836ef74bc2c: Modernize code: use range-based for loop in more places (authored by kossebau). REPOSITORY R263 KXmlGui CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24261?vs=67047=68389

D24663: Use ECMGenerateExportHeader to manage deprecated API better

kossebau added a comment. In D24663#550883 , @romangg wrote: > It's ok that you pushed. Can you give a link to your preferred resource for me to read up on ECMGenerateExportHeader? Not too comprehensive if possible. For one there are the

D24663: Use ECMGenerateExportHeader to manage deprecated API better

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R127:1fb1906ac5c2: Use ECMGenerateExportHeader to manage deprecated API better (authored by kossebau). CHANGED PRIOR TO

D24663: Use ECMGenerateExportHeader to manage deprecated API better

kossebau added a comment. Reviewed myself once more and will be pushing now, given this is fairly straightforward after all, so the KF_* flags can be enabled next. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D24663 To: kossebau, #kwin Cc: zzag,

D24671: Use ECMGenerateExportHeader to manage deprecated API better

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R290:d03f2d7114c4: Use ECMGenerateExportHeader to manage deprecated API better (authored by kossebau). REPOSITORY R290

D24671: Use ECMGenerateExportHeader to manage deprecated API better

kossebau added a comment. Reviewed myself once more and will be pushing now, given this is fairly straightforward after all, so the KF_* flags can be enabled next. REPOSITORY R290 KPackage REVISION DETAIL https://phabricator.kde.org/D24671 To: kossebau, #frameworks, #plasma, mart, apol

D24700: Use ECMGenerateExportHeader to manage deprecated API better

This revision was automatically updated to reflect the committed changes. Closed by commit R249:d6c413a0b779: Use ECMGenerateExportHeader to manage deprecated API better (authored by kossebau). REPOSITORY R249 KI18n CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24700?vs=68059=68275

D24261: Modernize code: use range-based for loop in more places

kossebau added a comment. Ping? REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D24261 To: kossebau, dfaure Cc: dhaumann, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24678: Use ECMGenerateExportHeader to manage deprecated API better

This revision was automatically updated to reflect the committed changes. Closed by commit R242:df7f98189060: Use ECMGenerateExportHeader to manage deprecated API better (authored by kossebau). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D24678?vs=68001=68273#toc REPOSITORY R242

D24671: Use ECMGenerateExportHeader to manage deprecated API better

kossebau added a comment. @apol Hi. Any chance you can give this a review soon, given this is almost the last one remaining before the complete of all (affected) KF modules to ECMGenerateExportHeader is done, and we can enable the respective KF_* macros? REPOSITORY R290 KPackage REVISION

<    1   2   3   4   5   6   7   8   9   10   >