I'd avoid to bump the KF5 version only because of a test.

I'm not sure if there are any other changes to be made.

In D21666#477781, @ngraham wrote:

This does not actually fix https://bugs.kde.org/show_bug.cgi?id=408244:

1. Open Dolphin
2. Use that Dolphin window to navigate to an image
3. Open the image in Gwenview
4. in Gwenview, go to File → Open Containing Folder
   
   Nothing happens.

Yeah it seems I should have used CCBUG: instead. D21691 will fix it.

In D21695#476826, @heikobecker wrote:

I'm not entirely sure about taglib-config on Windows

Where does this FindTaglib.cmake come from?

@jriddell Would it be possible to have https://kde.org/applications/utilities/ark instead of https://kde.org/applications/utilities/org.kde.ark?

In D21403#473053, @rthomsen wrote:

I'm not sure what is going on to be honest. What do you think is the more correct solution?

Thanks for the quick fix :)

Makes sense, thanks!

Well, the point of the preview is that I don't need the full app if I just want to have a quick glance at some file. I don't need the full kate or the full okular if I just want to quickly see what's in a text file or in a PDF.

Thanks for the feedback. We haven't tested Activities indeed, sorry about that.

In D21542#473134, @kossebau wrote:

What is so wrong with hex editor previews? Spot your trojans while they enter your system in a zip !;)

More serious: I am not sure if users want a full-blown application started instead of the previewer. Even more if this cannot be foreseen when triggering the preview, what actually will happen.
I would rather expect no preview if there is no (wanted) previewer available. And have a dedicated "Open" instead.

Ah, weird. Then why is okularApplication_fb.desktop associated with binaries? (even if I right-click any binary in /usr/bin from dolphin)

Note: as side-effect of this patch, now binaries/libraries in an archive will open in Okular, because there is a okularapplication_fb desktop file registered with application/x-sharedlib.

The actual stacktrace here is fixed by dfbbc9561e, but df024e3d13 should prevent this crash from happening in the first place.

Should be fixed by df024e3d13 + 3dbdac8175 + dfbbc9561e.

Thanks

Sorry, one last thing: can you fix the trailing white spaces? The phabricator UI doesn't show them, but there are a lot of them (check with git diff).

Tested also on gnome, window activation works fine also there.

In D16648#470609, @zzag wrote:

Wayland clients can't raise or activate themselves (so maybe ignore that for now?).

If I recall correctly, @davidedmundson proposed a protocol (for rfc) some time ago on wayland-devel that would a wayland client to pass the focus to another client.

This is possibly due to m_tempFile and m_archiveWriter being class member (since @mvlabat's GSoC refactoring), while they used to be local variables in ReadWriteLibarchivePlugin::addFiles().

• Is this the correct way to solve the problem?
• Should this connection type be used for any of the other signals?

Patch looks almost ready now.

Hmm, I just noticed that KWindowSystem::activateWindow() doesn't seem to work on Wayland.

Almost there :)

Please don't forget to bump kio-gdrive's KGAPI_MIN_VERSION to the new libkgapi's KGAPI_VERSION_STRING.

That worked, thanks :)