Watch for language change events, and forward those to the QML engine
ClosedPublic

Authored by vkrause on Feb 23 2020, 12:40 PM.

Details

Summary

This fixes a race condition on startup for the Kirigami translation
catalog that happens as follows:

  • QML code triggers the loading of the Kirigami plugin
  • the ECM QM loader is triggered, but since this is running outside of the

main thread, the actual QM loading is deferred to the main thread

  • QML code execution continues, at which point qsTr might still return

unstranslated strings

This is for example visible by the "Actions" header in the context drawer
of the main application page not getting translated.

Diff Detail

Repository
R169 Kirigami
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
vkrause created this revision.Feb 23 2020, 12:40 PM
Restricted Application added a project: Kirigami. · View Herald TranscriptFeb 23 2020, 12:40 PM
Restricted Application added a subscriber: plasma-devel. · View Herald Transcript
vkrause requested review of this revision.Feb 23 2020, 12:40 PM
apol added a subscriber: apol.Feb 23 2020, 11:32 PM

I'm fine with this being done here for convenience, but it feels like it's something that should be in QQmlEngine itself.

In D27595#616544, @apol wrote:

I'm fine with this being done here for convenience, but it feels like it's something that should be in QQmlEngine itself.

Right, or at least in QQmlApplicationEngine.

mart accepted this revision.Feb 26 2020, 1:30 PM
This revision is now accepted and ready to land.Feb 26 2020, 1:30 PM
This revision was automatically updated to reflect the committed changes.

git bisect says this caused https://bugs.kde.org/show_bug.cgi?id=418447.

Would be nice to fix that regression before it gets shipped with Frameworks 5.68.

I can reproduce only if I set a valid translation catalog. Even more surprising since the affected dialog does not seem to contain any qsTr() translations.
I don't think this patch is wrong as such, the layouting glitch is a bug elsewhere that we trigger by the retranslation (but that could be non-trivial to track down). If you need a quick workaround (at the expense of working qsTr translations), just comment the connect() call in initializeEngine().

git bisect also shows that this crashes the virtual desktop and regional settings KCM in Kubuntu 20.04

git bisect also shows that this crashes the virtual desktop and regional settings KCM in Kubuntu 20.04

I haven't seen a backtrace for this, but from what I understood from the chat backlog this is triggering a QML bug (?) due to the re-evaluation of qsTr() with 5.12, rather than actually crashing in the code of this patch? If so, I see three options:

  • ifdef the connect() call in initializeEngine() for Qt 5.12, breaking translations in that version only.
  • Replace this patch by the alternative approach proposed in D25984 for fixing translations, and see if that has less side effects.
  • Revert this entirely and break translations

@mart @davidedmundson @broulik?

I haven't seen a backtrace for this, but from what I understood from the chat backlog this is triggering a QML bug (?) due to the re-evaluation of qsTr() with 5.12, rather than actually crashing in the code of this patch?

Did not have time to last night, but I will file a bug with both backtraces shortly. For now I have reverted the commit in Kubuntu, as a crashing KCM is the greater evil, but a better solution would be great. :)

Is there no better way to do this? e.g. the KWin Rules KCM spends 20% of its startup time in "retranslate" :/