Don't link directly against Purpose for sharing
Needs ReviewPublic

Authored by sandsmark on Oct 11 2019, 9:34 PM.

Details

Reviewers
cfeck
ngraham
nicolasfella
apol
Group Reviewers
Gwenview
Summary

Because Purpose is a pretty heavy library with a ton of weird dependencies it seems to be fairly normal for people to not want it.

So instead of linking against it directly use the plugin it provides, then people who want it can install Purpose and it magically works.

Test Plan

Sharing works, doesn't crash when Purpose is not installed.

Diff Detail

Repository
R260 Gwenview
Lint
Lint Skipped
Unit
Unit Tests Skipped
sandsmark created this revision.Oct 11 2019, 9:34 PM
Restricted Application added a project: Gwenview. · View Herald TranscriptOct 11 2019, 9:34 PM
sandsmark requested review of this revision.Oct 11 2019, 9:34 PM
sandsmark updated this revision to Diff 67756.Oct 11 2019, 9:38 PM

This results in the purpose functionality disappearing even though I have Purpose installed.

apol added a comment.Oct 13 2019, 11:00 PM

I don't really understand. What Purpose dependency actually bothers you?

It's just QtBase, KF5::ConfigCore and KF5::CoreAddons.

target_link_libraries(KF5Purpose

PUBLIC
    KF5::CoreAddons
    Qt5::Gui
PRIVATE
    Qt5::DBus
    Qt5::Network #QLocalSocket
    KF5::ConfigCore

)

In D24576#546716, @apol wrote:

I don't really understand. What Purpose dependency actually bothers you?

It's just QtBase, KF5::ConfigCore and KF5::CoreAddons.

Just testing here now in a fairly "complete" KDE environment (though without plasma-workspace), it needs to install 10 new packages (kirigami2, accounts-qml-module, libaccounts-glib, several signon- packages with their own deps, etc.) just to install purpose.

And pulls in qt5-webengine via via, and though I obviously have it already, I understand why people don't want that when they just want an image viewer.

But I see that at least the nodejs dep is removed at least. :-)

IIRC why I actually started looking into this was because it pulled in some QML modules that crashed when QtCreator tried to inspect them, and it's fairly easy to fix but I saw people had started creating separate "foo-no-purpose"-packages so I assumed this was something that more people would like as an optional runtime dependency.

This results in the purpose functionality disappearing even though I have Purpose installed.

Did you get any warnings? And which version of purpose?

It Works On My Machine™, this is just after installing purpose and starting gwenview again:

I can still reproduce.

I have purpose installed from git master (like everything else KDE). The CMake log for Gwenview no longer even mentions Purpose at all. Console output says:

Invalid plugin number of Share file plugins (colliding IDs)
Invalid plugin number of Share file plugins (colliding IDs)
Invalid plugin number of Share file plugins (colliding IDs)

I'm still not sure why this match really makes sense. Even if we fix the issue preventing it from working, if Purpose is no longer marked as a dependency in CMake, it's quite likely that it won't get installed by casual users of Gwenview in other desktop environments, who will then just miss the purpose-related functionality. Why is Purpose so bad that we should essentially discourage its installation? Just because it has some other dependencies? I'm not convinced.

I can still reproduce.

I have purpose installed from git master (like everything else KDE). The CMake log for Gwenview no longer even mentions Purpose at all. Console output says:

Yeah, it's on purpose (pun intended) that it doesn't check for anything named purpose, it just checks for plugins exposing the purpose interface (sharefileitemaction).

Invalid plugin number of Share file plugins (colliding IDs)
Invalid plugin number of Share file plugins (colliding IDs)
Invalid plugin number of Share file plugins (colliding IDs)

And nothing in between? It's supposed to print all the plugin filenames, and the list can't be empty because that's checked above... Kind of seems like your sycoca is in an invalid state, tried running kbuildsycoca5 --noincremental?

I'm still not sure why this match really makes sense. Even if we fix the issue preventing it from working, if Purpose is no longer marked as a dependency in CMake, it's quite likely that it won't get installed by casual users of Gwenview in other desktop environments, who will then just miss the purpose-related functionality.

Well, the point is to make it an optional runtime dependency, if packagers doesn't add it as optional without explicitly showing them via cmake I can add a message() to the CMakeLists.txt in my patch.

Or I could change the patch to still show the Share menu, but with a message with something like "No Share plugins installed" or something? Or explicitly mention Purpose, though the name is pretty confusing for casual users.

Why is Purpose so bad that we should essentially discourage its installation? Just because it has some other dependencies? I'm not convinced.

Because it has a lot of large and intrusive dependencies.

As mentioned, just on my system with a fairly "complete" KDE setup it pulls in 10 new semi-intrusive ones (autolaunching daemons etc.), and it also pulls in e. g. webengine which is fairly huge for someone without any KDE applications already. And as I said, some of those dependencies crash a lot when e. g. QtCreator tries to inspect them (with accompanying coredumps in my journal).

And as already mentioned, for every KDE application that starts depending on Purpose people start creating separate "foo-no-purpose"-packages, so it isn't just a theoretical problem.

And FWIW as a user who does stuff that Purpose helps with (sharing cat pictures on the internet), e. g. uploading an image to Imgur is much quicker with drag-n-drop from gwenview or dolphin onto imgur.com in the browser.