KCMultiDialog: Port away & deprecate desktop file plugin loading
Open, Needs TriagePublic

Description

Based on T14500.

Currently the one has to use the desktop file based plugin loading to display any KCM.

Instead the plugins should be loaded using KPluginMetaData. By still installing the desktop files and prepending the install namespace to the X-KDE-Library property the old-style KCM loading still works. That is for example in the settings dialog in Kontact needed.

alex created this task.May 23 2021, 4:25 PM
alex added a project: KF6.
alex added a comment.EditedJun 16 2021, 6:03 PM

Frameworks method added in https://invent.kde.org/frameworks/kcmutils/-/commit/b0c3db286a5844ac63ac1c555dcb203eac7878be

https://invent.kde.org/pim/korganizer/-/commit/d6684c34393245fc3ababacde11d34e73c01a2e8
https://invent.kde.org/pim/korganizer/-/commit/5421d42b69c17d1904148e9b408d9ae46572cb85

https://invent.kde.org/pim/knotes/-/commit/59b075a8ea62b66b0510456387abe32d9a087125
https://invent.kde.org/pim/knotes/-/commit/e876f8caf77423aa79943601cd8d96625b041800

https://invent.kde.org/pim/akregator/-/commit/3a59f94d41640104460dd290895458fced282096
https://invent.kde.org/pim/akregator/-/commit/9f5e65a8db45b10e01e42846ca94745942b2ecab
https://invent.kde.org/pim/akregator/-/commit/809df6cb634295b9b230c1545d2499748fd53869

https://invent.kde.org/pim/kmail/-/commit/b17e8c2387c206e20e84bff1f3b254865e93b400
https://invent.kde.org/pim/kmail/-/commit/7769b79eb8e2448063ddc3209b08f45509863912

https://invent.kde.org/utilities/basket/-/commit/e69798bd3bfd37bf1dee6156d2eb0be00c94a7ab
https://invent.kde.org/utilities/basket/-/commit/0d1475151e01dbd99a2edaf73cf7787cc0b5ca10

The summary KCMs needed some extra work:
https://invent.kde.org/pim/kmail/-/commit/3d0fcc9c1689c9f10cdb7c675b49db553000b73b
https://invent.kde.org/pim/korganizer/-/commit/f8938fdcfca3bf300bab2fb9a1f6ec55d6e6b41d

and some cleanup of the previously used methods:
https://invent.kde.org/pim/kmail/-/commit/67b53edd84dc907b5ac267ced596aa6791c28519
https://invent.kde.org/pim/korganizer/commit/459fb10460d7ee7255dbd5b4a600fdd0581cb0b5

And the kleopatra KCM:
https://invent.kde.org/pim/kleopatra/-/commit/3ccc25fdeda51a9ed5438ad794ec431716905013
https://invent.kde.org/pim/kleopatra/-/commit/86365f3367315d6aa92f0053edce9cd92ff90c44
https://invent.kde.org/pim/kmail/-/commit/627a5e0bd241d25788b7598c87a670b953f97dda

alex moved this task from Backlog to In Progress on the KF6 board.Aug 23 2021, 2:38 PM

I just realized that Konqueror uses the hierarchical view too, just like Kontact did before the classes were imported there.

@stefanocrocco Not sure what to make of this. Could the settings dialog just be flattened? Then the issue would go away without the need to adjust anything in frameworks.

In T14501#262376, @alex wrote:

I just realized that Konqueror uses the hierarchical view too, just like Kontact did before the classes were imported there.

@stefanocrocco Not sure what to make of this. Could the settings dialog just be flattened? Then the issue would go away without the need to adjust anything in frameworks.

I'm not sure I understand what you mean by "flattened". Do you mean not passing the parent argument to addModule? If so, I think it looks quite bad, as can be seen from the attached screenshot

. As you can see, the list of entries is quite long, to the point of requiring a scrollbar, which I think is not good from the user's point of view.

I'm not sure I understand what you mean by "flattened". Do you mean not passing the parent argument to addModule?

Yeah, that is what I meant. Though this is what Kate for example is doing too if one has plugins enabled which have a config page.

But honestly I am not really keen on introducing an extra overload in KCMUtils for only one usecase. Especially if we would need to take care of the "insert at correct position" stuff (which is how it is currently done).

Of course having a custom KPageDialog would be an option. Not sure what is best here. @ahmadsamir Thoughts?

Even without passing a parent to addModule(), you can still have a treeview by setting the FaceType: dialog->setFaceType(KPageDialog::Tree)

(which IMHO looks better than the List facetype).

I tested with konqueror, that seems to work and I get a treeview, but the order of the modules is a bit different than when using addModule() with a parent, I guess that can be fixed by tweaking the "weight" stuff in each modules .desktop / json file?

alex added a comment.Aug 30 2021, 5:16 AM

But then one does not have the "subtrees" with the expandable/collapsable sections. Though it wold fix the concern that the the list is scrollable by default ๐Ÿ‘

I guess that can be fixed by tweaking the "weight" stuff in each modules .desktop / json file?

Yeah, or with the KPluginMetaData one could look in a specific namespace, load the plugins dynamically and then sort them before inserting.

That is how I have ported in the PIM stuff, IMHO nicer than hardcoding the KCMs.

I tried using dialog->setFaceType(KPageDialog::Tree) and I think it could work, even if it's not as nice as the current version. Something must be done for the ordering: one problem is that the .desktop files don't all belong to Konqueror (for example, some are from dolphin).

alex added a comment.Aug 30 2021, 8:23 AM

That is of course doable, we can just specify a weight property or maybe just the initial preference one since that has a nice read-accessor in KPluginMetaData.

All the MRs above landed, this is not actionable anymore until KF6 branching.

@alex anything left to do here?

alex moved this task from Waiting on KF6 Branching to Done on the KF6 board.Jun 28 2023, 2:39 PM