Create Task
Maniphest T15956

KIO worker config: sharing/syncing between KF5 & KF6?
Open, Needs TriagePublic
Actions

Description

There are two challenges here:

1.) The config of KIO workers is stored in a file "kioslaverc". That file is accessed by that name from multiple places, both for reading & writing.
Ideally the file should be renamed to "kioworkerrc", to match the new lingo.

2.) The D-Bus signal by name "reparseSlaveConfiguration" from object path:"/KIO/Scheduler" with interface "org.kde.KIO.Scheduler" is emitted and listened for from multiple places, without being bound to a well-known DBus service name, and thus also not to a KF version.
Ideally the signal should be renamed to "reparseWorkerConfiguration", to match the new lingo.

Related Objects
Search...

kossebau created this task.Nov 9 2022, 11:41 AM
kossebau updated the task description. (Show Details)
vkrause added a subscriber: vkrause.Nov 22 2022, 4:41 PM

Discussed during the bi-weekly KF6 meeting:

We basically only see two options:

  1. Support both names starting now and/or in KF6, drop the old names in KF7.
  2. Do nothing.

Any faster change would likely be hard due to the widespread use of the config file not just in our applications but also in e.g. https://github.com/libproxy/libproxy/blob/master/libproxy/modules/config_kde.cpp#L185 and possibly similar code in Qt.

kossebau added a comment.Nov 22 2022, 5:01 PM

Support both names

Names of the config files, right? To ensure syncing between the files, might be doable by a symlink perhaps, which should work on all platforms where KF-based software relies on shared config, and for bundled apps which do not share config anyway they could just use the new name.

Though a question which runtime instance would ensure the ymlink exists?

kossebau added a comment.Nov 29 2022, 1:05 PM

Looking at how this was approached for kdelibs4 parallel to KF5, I could not find any config file sync code though. Or migration code. Given kdelibs4 config files were located in the KDE-specific folders, where KF5 had switched to XDG folders, such synchronizing would have been needed.

Perhaps we can just do the same breakage again here, given there was no uproar, and thus avoid to carry on the old term for another decade.,

@dfaure Would you remember anything about kio config for kdelibs4 vs. kf5?

dfaure added a comment.Dec 19 2022, 10:50 PM

I don't understand the question. As you correctly state, kdelibs4 config files were in ~/.kde while KF5 config files are in ~/.config so there was no clash, but also no syncing of any kind. Two completely different worlds. Why would one want to keep them in sync? Config changes made in kdelibs4 systemsettings didn't apply to KF5-based apps any more than they would apply to GTK/Gnome apps. And vice-versa.
This was a different situation than your renaming-but-keeping-compat case, maybe.

I vaguely remember some distros implementing some hacks on top (but certainly not for kioslaverc which isn't used all that much).

Migration code exists, generally speaking, in kcoreaddons/src/lib/util/kdelibs4migration.cpp, to let apps read from ~/.kde on first start of the KF5-based version. No mass-migration, we instead let each app decide what to carry over.

Why not do the same here? KF6-kio copies kioslaverc to kioworkerrc, once, if kioworkerrc doesn't exist yet. Later changes to kioslaverc (which only happen if someone is running a mixed environment) are ignored by KF6-based apps.

(BTW I'm impressed by all the work you're putting in this slave->worker renaming. I know that I would personally have thought it a huge amount of effort for very little gain)

kossebau added a comment.Dec 21 2022, 11:16 AM

Why not do the same here? KF6-kio copies kioslaverc to kioworkerrc, once, if kioworkerrc doesn't exist yet. Later changes to kioslaverc (which only happen if someone is running a mixed environment) are ignored by KF6-based apps.

Challenge is that kioslaverc is both written & read from multiple places, So they all would need to care for the migration, in case they are run first.

But if there was no official migration then for kdelibs4->kf5 config data of kioslaverc, not providing one for KF5->KF6 as well might be an option then.

And KF6 (based) code would just switch to "kioworkerrc" named config file (and related signals) and again live in a separate world. Would then push for that approach.

Even more radical might also be looking into dropping any custom config and instead trying to read any configuration (like proxy or smb settings) from config data valid for the whole respective platform where feasible, instead of having a separate kio subsystem config bubble. Even more as for a plain non-toolkit-aware user (and ideally no-one should need to be) it is hard to tell which apps comply to any settings done in Plasma Systemsettings/Network vs. any other system settings tools. Some related xdg config scheme work might be good here I guess. But not going there myself, just stating what I would do if I were young and had time.

(would personally have thought it a huge amount of effort for very little gain)

Seeing clutter growing (like the created mix of "slave" & "worker" terms both referring to the same concept) gives me pain. Less pain thus is my gain here :)