I feel like it would be a good moment to pick up this again, @ltoscano what do you think?

In D21277#675639, @gregormi wrote:

Hmm, arc land says...

FETCH  Fetching origin/master...
fatal: unable to update url base from redirection:
  asked for: https://git@invent.kde.org/kmines/info/refs?service=git-upload-pack
   redirect: https://invent.kde.org/users/sign_in
Usage Exception: Fetch failed! Fix the error and run "arc land" again.

What can I do now? Except a new merge request on https://invent.kde.org/games/kmines?

Any special reason it's called "No. 2"? Is there a No 1 somewhere?

Yes :) - No. 1 is a slightly modified version of my original proposal, which I uploaded here: https://www.pling.com/p/1397003/.

Ok, i guess you can commit it.

In D26342#675164, @sdepiets wrote:

In D26342#675142, @dfaure wrote:

This actually breaks language auto-detection for me in the KMail composer.

Testcase:

• New Mail
• I type "Bonjour," in the body
  
  Before: It's detected as French and not underlined as a typo
  
  After: The language remains English, and the word is underlined as a typo
  
  Workaround: Tools / Spelling / change language from English to French
  
  Too bad I'm realizing this is the reason for the regression only today (day of 5.71 release) by looking at the KF-5.71 changelog :(

I don't think that's a regression, in the previous behavior you could try to set any language to proofread, it would always auto-detect "Bonjour" as French, thus the "Tools / Spelling / change language" had not effect if autodetect was enabled at system level (while autodetection should be an application or even case by case decision).

It may not seem like an issue for simple cases, but actually for mixed contents (i.e. an email that is 50% French, 50% English) that would be detected as English, you would have no way at all to check the French text without disabling system-wide autodectection.

Calling setAutoDetectLanguageDisabled(false) restores the previous behavior

Given the current state of instability we have due to the gitlab migration + different structure fallout, let's give us a few weeks to try to stabilize things and come back to this?

Yes i understand the scripts are shared between gitlab and jenkins and that lots of projects are not "very good" in keeping their tests clean, that's why i asked this to be opt-in for those projects that try to actually have passing tests :)

In D29826#674634, @aacid wrote:

oh i think i'm too late :D

oh i think i'm too late :D

It didn't really land on Qt 5.15 yet, so we may need to update the comment to say 5.15.1 or something

Potential solution, just drop CHM support https://tsdgeos.blogspot.com/2020/05/chmk-simple-chm-viewer.html

Personally I'm happy enough with this, i guess wait a few days and if noone disagrees, land it

Do you think we should mention something like

In D22488#673575, @poboiko wrote:

UPD: seems like it doesn't. I've added couple qDebug lines, to QIcon::fromTheme() method and near QIcon::setFallbackThemeName() with your patch, and then ran okular and dolphin.
By the time setFallbackThemeName() is called, almost all icons are already loaded :(

In D29826#673572, @poboiko wrote:

Thanks for looking into it! :)

In D29826#673543, @aacid wrote:

I don't think moving this code from KIconThemes to kmainwindow makes sense, what about all the apps that use KIconThemes but no KMainWindow?

I'm just not aware of any. I've looked at some of the most used (by me :]), noted that all of them use KMainWindow and thought it might be a good option.

Now i understand this is causing relatively several issues, sorry for dropping the ball, so we should probably fix for users before Qt 5.15.1

https://codereview.qt-project.org/c/qt/qtbase/+/301588

Not sure if you're subscribed to https://phabricator.kde.org/D22488 see my last comment there i think it's the way to go

Wouldn't it make more sense to fix in Qt?

I don't think moving this code from KIconThemes to kmainwindow makes sense, what about all the apps that use KIconThemes but no KMainWindow?