Done, but as in the other cases, this should be called only once.

an assert would be valid in such a scenario

then add an Q_ASSERT(!m_appletInterface), this documents your intent and does not pollute the code

use an assert then

double spaces after =

remove {, you don't use them above either

m_folderDir = nullptr

remove extra space before +

When QObject dies it's disconnected to all signal/slots. In this case if you want to not notify FolderModel you can use

m_screenMapper->disconnect(this);

{} braces even on one line, done it on all places.

When you use singleton it's better to make variable construction in one line

static ScreenMapper *s_instance = new ScreenMapper();
return s_instance;

or

static ScreenMapper s_instance;
return &s_instance;

In this way you don't have unwanted check for creation and variable at class scope.

Yes, I know, indeed this might be more clear.

Ok, although I don't see this commonly used in KDE (or Qt). If you really want, I can change it of course.

remove the init and cleanup if both are empty?

remove if empty

dito

can you add a comment why this explicit disconnect is needed? is it b/c removeScreen would otherwise emit a signal that we'd try to handle but don't want to? otherwise the QObject dtor would disconnect us

ws only, unneeded change, can be unset

this is a pretty arbitrary timer, can you add a comment on why 100ms is better than going through the eventloop once via QMetaObject::invokeMethod with the delayed flag set?

should this maybe be QUrl::fromUserInput with a prefer local file flag set?

could be rewritten/simplified:

const auto it = std::min_element(...);
m_firstScreenForPath[path] = it == m_availableScreens.constEnd() ? -1 : *it;

so if path is empty, this adjusts all paths? can you add a comment on when this happens and what it's for?

these three lines are shared with above, introduce a helper function in an anon namespace for it: QUrl screenUrlForPath(const QString &path);

m_itemsOnDisabledScreensMap stores "names" from the m_screenItemMap, so I think this line here is wrong and should also use the proposed screenUrlForPath above, or QUrl::fromUserInput, no? Otherwise you may end up with relative urls for file paths?

again, seems like an empty path has a special meaning, can you document that somewhere please?

is name also a path?

dito

this needs to be documented, i.e. why and when is it required to distinguish between these signal behaviors?

Done. InvokeMethod would not help, as the idea here is to get only one screenMappingChanged instead of e.g 50 when FolderModel gets the entries on startup.

personally I'd make this code explicit. i.e. this here is somewhat harder to grasp I think (and also slower, due to the repeated lookups) to something like this:

const auto newFirstScreen = std::min_element(m_availableScreens.constBegin(), m_availableScreens.constEnd());
for (auto &screen : m_firstScreenForPath) {
    if (screen == screenId) {
        screen = newFirstScreen;
    }
}

potentially we also need to update m_screensPerPath though, which the current code doesn't do either. The branch above does write to pathIt though, is this missing here?

unused variable, remove

You're not testing m_screenMapper!=nullptr here.

I know it's a very theoretical case, but you're not disconnecting from an old non-null ScreenMapper here.

You're also not calling invalidateFilter even though filterAcceptsRow uses the mapper. It's all a bit non-hygienic in the sense of "allow stuff to be set and reset in any order". Which can be somewhat important, especially as FolderModel doesn't inherit from QQmlParserStatus (hint: would be a great follow-up patch) and sometimes things can fall apart in config-dependent ways during initialization.

I'd appreciate a pass through this code for that concern for good Qt Quick hygiene.