Btw, if there is a better place for initialization, I'd happily move the code to some other place.
Rebase on master.
As the limit is somewhat arbitrary, maybe we can just limit the QString? I don't think this has any serious side effects.
Actually, there is an issue with that code right now, which I wanted to fix, but forgot.
The trimming part finalArr = finalArr.mid(0, maxTermSize); actually should be performed on QString instead of QByteArray - unicode symbols inside term can consist of two bytes, and cutting at maxTermSize bytes can actually cut half of symbols. I end up with terms like тождественно� inside balooshow -x.
Not to mention that russian terms end up being pretty small.
Any chance this could not be done by abusing KDECMakeSettings.cmake as injection vector? I know you are just following the example of what was done for appstreamcli, but IMHO this has already been a bad hack, screwing over the fine granular design of all the ECM modules trying to keep aspects separate. And yes, by the price of the overhead with more explicit module includes, but it's like that. Or we should just screw it and put everything in one big "KDEECMEverythingEvenKitchenSink.cmake" ;) And yes, one possible would like to have such a generic wrapper module in any case, for quick prototyping. But the individual modules should stay focussed.
- addConfigEntry(ConfigEntry(LineLengthLimit, "Line Length Limit", QString(), 4096));
+ addConfigEntry(ConfigEntry(LineLengthLimit, "Line Length Limit", QString(), 10000));
Then let's try that. Even for all cases without hitting the limit the new code is faster.
The Binary Factory uses the tooling shipped as part of the KDE SDK (which always builds everything from scratch, and I don't know if part of that includes ECM, hence why the issue doesn't show up there).
Please note that there are very few people involved with Windows builds (despite the number of projects that make use of them in general) so people may not always have the ability to respond to every review request.
That is why the CI system monitors the state of code and can catch issues as they happen.
Windows - thanks for ignoring every review request!
This change appears to be responsible for all Android builds being broken.
This change has unfortunately made MSVC unhappy - https://build.kde.org/view/Failing/job/Frameworks/job/kfilemetadata/job/kf5-qt5%20WindowsMSVCQt5.11/lastFailedBuild/
I am not sure about the warning.
The line length limit default should be increased it think, we could just try something like 10000 for a start.
I would propose we try this without a warning and see if we get negative feedback.
Normally this should only kick in situations were before we slowed down to "unusable".
Would that be ok?
I tried the patch and it improved the performance really much! :) I was able to edit a line that contained over a million characters!
- remove unnecessary else