Last question: give the button text, or stick with the icon only? I ask because go-jump is kind of an odd icon IMO:

Use more semantically correct icon

Actually I played with that and in retrospect I don't think it would work. If we give it a "link-like" appearance, that would suggest that clicking on it would actually open the destination file/folder (i.e. the typical link behavior), which is not what we want here. We want to show it in the file manager, not open it. I'll stay with the current approach and change the icon as @ndavis requested.

I see.

So much red!

@pdabrowski can you rebase this?

@davidedmundson are you still good with this?

Are you not seeing these for instance when browsing an MSWin share in Dolphin (with the same or newer versions of kio-extras, Samba and MSWin)?

I think that tests are still passing properly, but this change may have unexpected consequences. I would like to tqke the opportunity of this pqtch to discuss if it's a valid approach for floating date time input. Thank you.

There's also a lot of code duplication making the diff hard to read. Please group if statements together where it makes sense, e.g. avpod things like

if (foo) {
    return plasmoid.title;
} else if (foo) {
    return plasmoid.title;

or

if (foo) {
    if (bar) {
        baz();
    }
} else {
    if (bar) {
        baz();
    }
}

In D25279#561853, @jgrulich wrote:

There is already a method to enable/disable BT, why don't you reuse it?

In D25281#561861, @broulik wrote:

However Once we implement the Breeze color scheme changes

How is that related? If i keep using a dark title bar I will still have that issue. Merely changing the colorscheme doesn't fix the underlying bug?

In D25273#561852, @davidre wrote:

Since this directly uses KColorSchemeManager, do you also see duplicated entries in Kate's color scheme menu?

When we call this line:

connect(m_surface, &SurfaceInterface::damaged, this, &Toplevel::addDamage);

@bruns: I've missed D16593: [ExtractorCollection] Use only best matching extractor plugin, and had in mind previous situation where we've matched all extractors based on inheritance. In that case, "Secondly" part indeed does not seem to apply anymore.
(as for my previous answer: I misunderstood you, thought you were asking about the case where PlainTextExtractor did not match & matched afterwards)

^ Plays into https://github.com/ximion/appstream/issues/240

Seems sane to me and nice since it removes some code.

Technically there's one potentially interesting behavioural change.
If a client is server side decorated and then draws a subsurface outside the main surface, previously I believe we would have drawn our frame over the main surface, whereas now I think we'll draw our frame over the union. Probably not a real world issue though.

The issue could be as well located in previewjob.cpp.
Could you debug why KMountPoint::List::findByPath is called with an empty string or non-existing file.
We might want to prevent this to happen instead.

In D23787#541963, @poboiko wrote:

In D23787#537891, @bruns wrote:

Can you please provide an example which:

• is currently indexed though it should be skipped due to size
• is skipped after this change

Sure. Any mimetype inherited from "text/plain", but starting with "text/" counts. I've made an actual list:

list.txt3 KBDownload

(using simple python script, which iterates over QMimeDatabase().allMimeTypes(), checks if type.inherits("text/plain") and is not already excluded by default Baloo config from file/fileexcludefilters.cpp)

In D23787#541963, @poboiko wrote:

and another example which:

• is currently skipped though it should be indexed
• is indexed after this change

There shouldn't be any. I mean, "PlaintextExtractor" should be inside exList for anything that starts with text/...