Kup in KDE Review
Simon Persson
simon.persson at mykolab.com
Thu Apr 9 06:25:34 BST 2020
Hello!
On 2020-04-07 06:01, Nicolas Fella wrote:
>
> Hi,
>
> I briefly skimmed trough the codebase. Looks all sane to me. A few
> minor observations:
>
> - You may want to look into KConfigXT. It should be able to generate
> the classes from settings/ from an XML description.
>
I think that I looked at it when I started Kup, about 10 years ago...
don't remember exactly but I think the issue was about dynamic
configuration entries. Kup allows user to create as many backup plans as
they want and each will have some settings.
>
> - You are using KInit for the daemon executable. We are looking into
> killing that in the KF6 transition
> (https://phabricator.kde.org/T12140 ) so consider it deprecated
> (although it is not offically yet). If you do not care about using kup
> outside of Plasma you might also consider implementing the daemon part
> as a kded module.
>
Ok, thanks for the info. And yes, moving it to kded might be possible.
Again, I think I looked at doing that in the beginning but don't
remember the reason that I went for a standalone executable instead.
>
> - In
> https://invent.kde.org/kde/kup/-/blob/master/filedigger/mergedvfsmodel.cpp#L60 please
> check if instead of calling loadMimeTypeIcon simply returning the
> iconname is enough, or return QIcon::fromTheme(name). loadMimeTypeIcon
> looks like a likely candidate for deprecation/removal to me. That
> would also get rid of the KIconThemes dependency.
>
Excellent finding! I have pushed a commit now to remove this dependency.
Simon
More information about the kde-core-devel
mailing list