fully port away from kdelibs4support
ClosedPublic

Authored by sitter on Dec 13 2018, 1:51 PM.

Details

Summary

the only remaining use was klocale:

  • languageCodeToName now goes through qlocale. it's worse data than before, with variants not being properly mapped into native names. alas, what isn't worse when relying on posix locales :|
  • readOptions' default setting of a langauge now iters the configured languages in klocalizedstring (which in turn comes from the LANGUAGE env var + some extra fallback sugar) to find a language we know. if none was found we continue to fall back to en.soundtheme
Test Plan

builds + loads correct default language based on what is configured in systemsettings + language list looks somewhat sane

Diff Detail

Repository
R418 KTuberling
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 8674
Build 8692: arc lint + arc unit
sitter created this revision.Dec 13 2018, 1:51 PM
Restricted Application added a reviewer: KDE Games. · View Herald TranscriptDec 13 2018, 1:51 PM
Restricted Application added a subscriber: kde-games-devel. · View Herald Transcript
sitter requested review of this revision.Dec 13 2018, 1:51 PM
aacid added a comment.Dec 13 2018, 2:02 PM

I don't want the language name regression.

You're welcome to pickup https://phabricator.kde.org/D10446 if you have time.

Fair enough. If you tell me what needs doing I can poke it. I don't want to invest too much time, but at a glance what you have done seems pretty much done really.

sitter planned changes to this revision.Feb 18 2019, 1:53 PM

Now that KLanguageName is landed: do you want to ifdef and retain compatibility with older KF5s or bump the required version?

aacid added a comment.Feb 18 2019, 7:46 PM

Let's just get rid of it altogether, it's going to be a bit painful do an if version in cmake

sitter updated this revision to Diff 52044.Feb 19 2019, 10:06 AM

use klanguagename instead of qlocale to get better language names for the UI

aacid added inline comments.Feb 19 2019, 7:16 PM
toplevel.cpp
236 ↗(On Diff #52044)

this is wrong, you moved the language.isEmpty up and now the else triggers in cases it should not trigger.

sitter planned changes to this revision.Feb 20 2019, 11:12 AM
sitter added inline comments.
toplevel.cpp
236 ↗(On Diff #52044)

Hm. That is true. Truth be told even after pointing that out it still took me way to long to see the problem -.-

I think I wanted to avoid the extra level of nesting. With that motivation in mind, what do you think about splitting the if

if (soundEnabled && language.isEmpty())
{
  const QStringList &systemLanguages = KLocalizedString::languages();
  ....
}

if (!soundEnabled)
{
  soundOff();
  language = QString();
}

In my mind the two code blocks aren't two sides of the same coin. One is language fallback-handling the other is the unrelated disabling of all sound. The only thing that links them is the fact that the only thing language is used for is to figure out what sound set to use.

I don't mind particularly though, so if you'd like to have

if (soundEnabled) {
  if (language.isEmpty()) { ... }
} else { ... }

I'm fine with that too

aacid added inline comments.Feb 21 2019, 6:15 PM
toplevel.cpp
236 ↗(On Diff #52044)

Not attached to any solution, just want one that works :)

sitter updated this revision to Diff 52280.Feb 22 2019, 11:10 AM

fix broken conditional. sound disabling condition is now detatched from the language fallback condition

sitter marked 3 inline comments as done.Feb 22 2019, 11:10 AM
aacid accepted this revision.Feb 26 2019, 10:28 PM
This revision is now accepted and ready to land.Feb 26 2019, 10:28 PM
This revision was automatically updated to reflect the committed changes.