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 partial change (which has been discussed before and discarded):
changing QColor ( 245, 245, 245 ); // light-grey background to highlightingTheme.editorColor(KSyntaxHighlighting::Theme::EditorColorRole::BackgroundColor) implies, one cannot use KSyntaxHighlighting to render text highlighted e.g. for a print-out on a paper (or only for a PDF). Compare e.g. the example https://phabricator.kde.org/source/syntax-highlighting/browse/master/examples/codepdfprinter/.

I don't think it implies this, and I don't see the point here, textCreator makes thumbnails for text files only anyway.
The change is just so that the background follows the user theme and avoids an hardcoded value that is not good practice.

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 ?

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 highlightingTheme.editorColor(KSyntaxHighlighting::Theme::EditorColorRole::BackgroundColor) implies, one cannot use KSyntaxHighlighting to render text highlighted e.g. for a print-out on a paper (or only for a PDF). Compare e.g. the example https://phabricator.kde.org/source/syntax-highlighting/browse/master/examples/codepdfprinter/.
Is this change for background needed to make that rehighlight approach working?

@starbuck Thanks. Tried a first link with https://store.kde.org/p/1334948 and adapted the KNSRC file of KDevelop, worked as wanted.
(well, once I added a workaround for some strange KNewStuff behaviour on archive extraction, cmp. 39a8a51d33 ;) )

Thanks for the reply, sounds good.

@starbuck @leinir H. Please see "Question to store.kde.org managers" (but better to read first whole text to get the context). I would like to sort this out before end of year.

@cullmann Seems the code style formatter scripts need to be teached not to touch kapptemplate format project templates (by standard in the "template/" subdir).

@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 :)

Okay, seems somebody else was not just messenger,but also fixer, by D25142 in parallel :) So solved then while I was typing, and meanwhile CI also looks good.

@montel Hi (sorry to be the messenger once more :) )
Sadly it does not compile fine with current minimal required AccountsQt5 versions as e.g. currently available on FreeBSD CI, cmp. https://build.kde.org/view/Failing/job/Applications/job/kaccounts-integration/job/kf5-qt5%20FreeBSDQt5.13/28/

Tests are run again now, thanks to 811c7544490031e1faeb4a1597c4d11afbf68eb9

Untested, but looks okay, besides the unneeded #f in the sources.

Merci, will land later tonight. Bonnes vacances :)

@dfaure Hi. Any chance you you can sneak in before you are away (enjoy :) ) to remove the "-DQT_DEPRECATED_WARNINGS_SINCE=0x060000" from all the KF modules in the next days? Otherwise would land this here with just the -DKF_DEPRECATED_WARNINGS_SINCE=0x060000 for now, otherwise people do not see warnings in KF modules when they should.

In D25039#557609, @meven wrote:

Feel free to do the code removal,

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 as well myself)

Sorry, currently no time for Plasma available: see also https://mail.kde.org/pipermail/plasma-devel/2019-October/105088.html

It was not moved, @ndavis seems to have independently without knowing this task renamed pages on community.kde.org instead. Good intentions, but not best execution IMHO. No idea how to resolve.

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.

(Quick drive-by comment only as I had this in a search result...)

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 KStandardShortcut::SaveOptions_DEPRECATED_DO_NOT_USE. And as I just found, there also in no build option to completely get rid of it . Possibly the patch I did there I left it as I assumed a chance the enum value might be stored as number in config entries, so changing any enum values would break data. Too bad there is no related comment, I shall fix that with a follow-up patch, to be put into review the next day.
So, with these considerations,

#if KCONFIGWIDGETS_BUILD_DEPRECATED_SINCE(5, 38)
	​    { SaveOptions,   KStandardShortcut::SaveOptions_DEPRECATED_DO_NOT_USE, "options_save_options", I18N_NOOP("&Save Settings"), nullptr, nullptr },
#endif

should actually be always correct. We do not support people building the library to override any *_DISABLE_DEPRECATED_BEFORE_AND_AT settings for the libraries we build against.

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 KAboutPluginDialog, to be used with KPluginMetaData
• D25059: KPluginSelector: use new KAboutPluginDialog
• D25063: Deprecate KAboutData::fromPluginMetaData, now there is KAboutPluginDialog

Now, there is still the idea of using KAboutData with plugins in the KAboutData API, by the methods void KAboutData::registerPluginData(const KAboutData &aboutData) & KAboutData *KAboutData::pluginData(const QString &componentName), By what lxr.kde.org reports, the register method is still in use, but nothing seems to actually query the registration data by the other method. So possibly we could discard that pair of methods as well. Would be curious though what the usecase for this once was, it surely had a piurpose.

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 instead making use of KPluginMetaData instead when it comes to plugins.

Now that is a quick turn-around, +1 for doing the work :)

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 on pass data pointers instead of literals to i18n calls. Thinking people who do that are in general challenged to ensure the proper context call is still used might be challenged in other places before IMHO.

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 the given array, and always would be: