KDeclarative breakup plan
Open, Needs TriagePublic

vkrause created this task.Sep 9 2019, 4:12 PM
ngraham added a subscriber: ngraham.Sep 9 2019, 9:57 PM

For the calendarevents/ part (that is also spread into plasma-framework) I'm working on a replacement based on KCalendarCore

bshah added a subscriber: bshah.Sep 23 2019, 6:10 AM
ognarb added a subscriber: ognarb.Sep 23 2019, 8:53 AM
ervin moved this task from Backlog to Waiting on Qt Changes on the KF6 board.Nov 25 2019, 9:21 PM
ervin moved this task from Waiting on Qt Changes to Metatasks on the KF6 board.

I took a closer look at KDeclarative::setupEngine(). It does a couple of setup things and presumably the intention at some point was that all QML apps use it. However in practice most apps don't, partly likely due to the unfortunate deps of KDeclarative.

This is what it does in detail:

  • Replace the stock QNetworkAccessManager with KIO::AccessManager. The usefulness of this is questionable (see T12472), but it's hard to judge how many places rely on this. This is the only place in the code KDeclarative lib where KIO is needed (the other usages are in the frameworks bindings)
  • It adds platform/formfactor specific import paths. This seems to be entirely unused.
  • It adds an image provider that allows to use icons as images (via image://icon/foo URLs). This is used (I learned that the hard way in https://invent.kde.org/multimedia/elisa/-/merge_requests/266). The usual way of loading icons is Kirigami.Icon, but there are use cases where you want to use an image. I think it would make sense to export the KIconProvider so apps can enable that manually instead of using setupEngine