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.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 14 2022
Jan 19 2022
Fedora still ships both, and I still use some unported legacy applications using either.
Jan 18 2022
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.
May 20 2020
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:
Jan 9 2020
Looks reasonable.
Jan 1 2020
Dec 21 2019
Modern distributions no longer have the deprecated library in repos.
Aug 24 2019
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.
May 9 2019
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.
Mar 23 2019
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.
Jan 3 2019
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.
May 13 2018
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.
May 12 2018
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.
Jan 21 2018
Nov 14 2017
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.
Apr 7 2017
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.
Mar 22 2017
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.
Mar 18 2017
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.