In T15232#270137, @ahmadsamir wrote:

Gitlab CI runs unittests as root, can looking into these wait until it's not running them as root?

Remaining issues:

• Kirigami: needs port to QtShaderTools
• KTextEditor: needs QTextCodec port
• kdesu: blocked on one remaining KToolInvocation usage
• KDeclarative: builds apart from some classes in kquickcontrolsaddons (needs https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/36 and QQuickItem porting)
• Baloo: PropertyMap vs PropertyMultiMap porting needed
• Purpose: needs Kirigami, needs Qt6 version of KAccounts, various build errors in plugins
• KQuickCharts: needs port to QtShaderTools
• Plasma Framework: https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/494
• KNewStuff: needs https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/11

I'm not saying this is the right fix for the problem at hand, I don't fully understand that yet myself. This is just meant as documenting my local observations :)

I can reproduce what Ahmad sees here (self-compiled Qt 6.3).

See tests/locationpicker.qml for a reasonably well working as-you-type location selector.

Another option might be to go directly for Qt6 builds (which imply EXCLUDE_DEPRECATED_BEFORE_AND_AT=CURRENT). The upside of this is that it is something we need long-term anyway, the downside is that we so far have only one module ready for this (I expect this to change shortly though, but possibly not to full KF coverage before branching).

KCountry::currency meanwhile provides the missing mapping, so it's down to showing this in the location info element.

For fully compliant repos we have REUSE checks for the CI already I think, see e.g. https://invent.kde.org/libraries/kpublictransport/-/blob/master/.gitlab-ci.yml#L5. Probably worth enabling for krunner as well.

Closing as we wont be able to avoid using non-public Poppler API for the foreseeable future as we meanwhile also process vector barcodes, so this image API would only solve a very small part of the problem now.

The reason for the complexity in the current header code is that this is a performance hot path. The heavily polymorphic design however isn't really suited for that, and thus we have dirty tricks in there like removing the vtable from the private class hierarchy.

The parts I have implemented are those dealing with country and country subdivision translations, as well as country/country subdivision and timezone lookups. It's still in a branch but given feedback/review it should be mergable for KF5.
What's still missing is:
(1) Language/locale translations.
(2) Human readable timezone names, and translations of those.
(3) Country/country subdivision to language(s) mapping.

Obsolete, now that libvkontakte has been moved to unmaintained.

I have no idea about those features in Lokalize, but maybe it's worth asking on the i18n lists for all the scripts in use right now? That should allow us to reach a large part of the userbase, and might give us a better idea on how big that problem really is.

Updated diff against the latest summit version.

In D29925#678524, @schwarzer wrote:

Oh and there already is a review for itenerary ... I know, Phabricator is weird (I never know why some reviews are listen in one category and other in another and some in both ...) ... ... So I will merge the first one first and then this one. The translations that occurred in both reviews and that I saw on a quick glance were the same.

Apply review feedback.

https://invent.kde.org/frameworks/kio/-/merge_requests/535 addresses the remaining part of this.

I don't mind this being changed, my point is that touching that part of the CI tends to have unforeseen side-effects, so better be prepared for that :)

https://invent.kde.org/frameworks/kio/-/merge_requests/505 should fix this

I couldn't find a reason for KIO being newly pulled into the dependency build, and it turns out it has always been there, there's just a build breakage due to recent KIO changes. Might be easier to fix that than dealing with the hard to calculate fallout of pulling KIO out of the middle of the dependency chain.

upstream has this now: https://github.com/schemaorg/schemaorg/issues/1755

confirmed to work: https://twitter.com/CarlKDE/status/1414170954914320385

Before starting this in a branch, it might be worth adding Android support first (which can be done now I think), I suspect this will identify a number of additional places in the API that would benefit from adjustments/generalizations.

If we see KService as a functional/platform implementation framework this is probably not much of an issue. If we want KService to become a platform abstraction that also covers systems not based on a .desktop file store and instead also support the native mechanisms on e.g. Android or Windows, the leaking of the sycoca implementation is less ideal, as it prevents us from not including that part on platforms where it isn't needed at all.

https://invent.kde.org/frameworks/kio/-/merge_requests/483 addresses half of this.

https://invent.kde.org/frameworks/kconfigwidgets/-/merge_requests/56 removes the widget dependency, and there's a number of MRs already to adapt PIM to that.

Deprecating KStatefulBrush::brush(const QWidget*) const would make KColorScheme widget-free it seems, and fortunately that is both easy to replace (via KStatefulBrush::brush(const QPalette&) const) and apparently unused in at least Frameworks itself.

In T13722#257973, @ognarb wrote:

Small warning with emojis, in QML apps there are some difficulties to render them: https://bugreports.qt.io/browse/QTBUG-85744 if you don't explicitly set the font to 'emoji'

In D29913#678020, @schwarzer wrote:

Wo hast du die Datei her, in der du die Korrekturen gemacht hast?
Hier in trunk-kf5/de/messages/kitinerary waren einige der Strings schon übersetzt.

add missing placeholders

In D29912#677956, @schwarzer wrote:

Interessant, dass da einige Dinger trotz Kontext durchgerutscht sind. Gibt mir etwas zu denken.

Conclusion from the 2021-04-21 frameworks meeting: Do not deprecate in 5, so this remains working and isn't dropped as part of preperational porting, and remove for 6.

https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/108 prototypes the 5/6 split of KDEInstallDirs, but still lacks implementations for the interesting bits: how to decide in the version-less wrapper which one to include, and how to replace the ECMQueryQMake calls.

In T14233#253318, @dfaure wrote:

However the request here (AFAIU) is for a transitional period where code can be compiled with both Qt5 and Qt6.

Meeting notes from the KF6 sprint (thanks to Luigi):

That's "solution 1", we ended up preferring the find_package() removal as that seemed overall cleaner (cf. problems with implicit find_package calls for Python in the past), and both options require large scale changes anyway. Technically this could be done in a very similar fashion though, with enforcing that variable set for a sufficiently recent ECM version.

Prototype implementation: https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/103

Oh it does! In about 10 places outside tests. Examples are the designer plugin, qch, qm, and query qmake macros as well as parts of the Android support.

After some more discussion with Steve yesterday I realized the full implications of my earlier statement that versionless targets must not leak into CMake config files:

Meeting notes:

Overlaps with T13869.

In T14164#251954, @skelly wrote:

As far as I know, it also makes it impossible to use Qt5-based and Qt6-based code in the same buildsystem. Doesn't seem worth it to me https://bugreports.qt.io/browse/QTBUG-83774 I'm not sure what the current state of the Qt 6 cmake files is though.

> Considered that and then lamented that C++ doesn't allow redefining a template.

off topic but you could specialize the template for unique_ptr

Ah, right, and you could probably do that with a macro to keep the syntax generic. Fun! :)

Thank you Carl for looking into this! This task is probably the biggest porting blocker for PIM, I'm very happy to see we have a way forward for this now :)

In T14164#250600, @dfaure wrote:

I'm wondering if this is really a good idea. Both for Qt and KF.

find_package(Qt 5 COMPONENTS Core) will happily pick up Qt5, Qt6 or Qt7, no? But that doesn't mean the code is ready for Qt6 or Qt7, so we don't want that for Qt5 code.

Right, for language names the situation is already much better than for much of the rest. This would just be moving that functionality to ki18n/tier1, and switch to the iso-codes translation catalogs instead of having to maintain our own.

Based on input from here, previous discussions and what I could find in existing code, here's a first draft for an API proposal for KI18n: https://invent.kde.org/-/snippets/1525

The primary use of this seems to be checking for network availability, not anything more detailed.

Not strictly limited to KF6 even, changing d-pointer types can be done at any time as long as we don't change the size of the public class, and assuming there is no inline code using d (which there very likely isn't, that would defeat the point of the d-pointer in the first place).