As I understand it, 22 showing up in freedesktop.org standards is a result of KDE/Plasma using it rather than the opposite. In fact, GNOME has always used 24, and the difference has always been an issue when trying to use icons designed for one desktop in the other, and an inconsistency in look&feel between KDE and GNOME applications.

Fedora still ships both, and I still use some unported legacy applications using either.

But will the unversioned executables not conflict with kdelibs 4 or 3 applications? At least some of those executables were part of the Plasma 4 kde-runtime which, as the name says, is required by some kdelibs 4 applications at runtime.

And the actual rationale appears to be: https://mail.kde.org/pipermail/kde-frameworks-devel/2020-March/105081.html

If, like me, you land here (after discovering the new dependency) and miss the rationale, see:

• https://phabricator.kde.org/T13025
• https://mail.kde.org/pipermail/kwin/2020-April/004517.html

Looks reasonable.

Modern distributions no longer have the deprecated library in repos.

If you ask me (there are 2 Kevins on this bug), I think this will work. I think it's kinda overkill (it pretty much defeats the point of having version-specific libexecdirs if we end up renaming the binaries anyway), but if it works (which should be the case), I'm OK with it.

LTS distros can upgrade software to new releases. RHEL regularly does this for some components, such as GNOME, lately even Qt (Qt 5 was upgraded from 5.6 LTS to 5.9 LTS in RHEL 7, I'd hope they'll do 5.12 LTS too at some point, though with RHEL 8 having been released, they might also stop upgrading RHEL 7 that way, so I don't know). What components they do that with is purely a policy decision.

When you look at how simple and uninvasive the change is (it just exports code that is there anyway) and that it actually only restores backwards source and binary compatibility (which is normally considered a good thing in KDE land, it would even be mandatory if this were an official KDE Framework), I think you (all three) are really being unhelpful and uncooperative here.

I am trying to resurrect Blogilo in Fedora. I am upgrading from the EOL Fedora 27 to the supported Fedora 28 (and eventually 29) and noticed that Blogilo was going away. So I tracked it down to the build failure caused by this export removal. I already got it building in my Kannolo Copr repository.

Or are there different interfaces that Blogilo should be using instead? If so, which are they? There is no documentation on that.

Exporting these classes is all that is needed to keep Blogilo working. There is no practical reason to break backwards compatibility of the KPIMTextEdit library that way, your only rationale for removing the exports is that they "should not be needed". The classes still exist either way.

Ping? This has been stuck for over a year now.

Are you going to do the merge of my changes to master or shall I do it?

Note: This patch is against Falkon/3.0. (The profile migration was added in 3.0.1, so I think this is also 3.0 material.) For master, the KWalletPasswords changes have to move to KDEFrameworkIntegration.

This version now uses #cmakedefine01 as requested.

Wouldn't it make sense to port the existing PORTABLE_BUILD and DISABLE_DBUS defines too, then? But that's material for a separate commit in any case.

Also, all the existing macros in config.h.cmake are #cmakedefine, not #cmakedefine01, so are you sure you want the latter even though it would be inconsistent?

I don't see a 5.11 check anywhere, at least in Falkon/3.0.

And the historical reason the name was not suffixed is because the binary was moved to a private libexec subdirectory to prevent conflicts. This worked fine as long as /usr/bin did not end up in the search path (in particular, for the whole 4.x series).

In D8810#167568, @cullmann wrote:

Yeah, that was done to be able to provide win/linux install bundles.

So, since this line makes sense on Windows/Mac, let's only get rid of it on Q_OS_UNIX then.

Sorry, but printing errors to stdout in a GUI application does not make sense. The users will not see them in most cases. Even if you run kdesu (without -t) from a Konsole, it will still not show stdout. There is no alternative to bringing up at least a GUI dialog (other than just stopping patronizing the user that way to begin with). Printing the recommended alternative to somewhere the user will not see is not helpful at all. The user will just see an application that does not run and have no idea why nor how to fix it.

Well, I think that in the present case, a single review is acceptable, but it needs to work in all situations. Unfortunately, I don't think your current code satisfies this requirement.

And also, you are again trying to fix 2 bugs in one review request. Please submit one review per issue you fix.

Unfortunately, I don't think your approach at taking the common part of source and destination as the directory and file name is going to work in all cases:

• If a file was added or removed, the source resp. destination will be /dev/null.
• Some revision control systems track renames and moves and output them as a diff section with different source and destination.

Fine with me. I'm not sure what the VDG would say about the UI design, but I cannot think of a better solution either, so I think this is OK.

Looks OK to me, I think the hardcoded 10 is not an issue.

Well, my first nitpick is that you are fixing 2 separate bugs and so should be submitting 2 separate code reviews.

I am still the maintainer, though to be honest, I haven't done much to Kompare lately.