Change Details

Currently we have a bunch of classes for the KNewStuff entries: - KNSCore::EntryInternal - KNS3::Entry - KNSCore::EntryWrapper Ideally we only have one class called KNSCore::Entry. This can be exposed to QML using a Q_GADGET, then the EntryWrapper can be dropped. The KNS3::Entry class should be removed, the remaining usage in the widget classes should be changed to KNSCore::Entry. Unfortunately we can not do a lot of it in a compatible way during KF5, because the unified KNSCore::Entry class does not exist yet and can not be added without keeping compatibility for yet another Entry class variant.

Currently we have a bunch of classes for the KNewStuff entries: - KNSCore::EntryInternal - KNS3::Entry - KNSCore::EntryWrapper Ideally we only have one class called KNSCore::Entry. This can be exposed to QML using a Q_GADGET, then the EntryWrapper can be dropped. The KNS3::Entry class should be removed, the remaining usage in the widget classes should be changed to KNSCore::Entry. Unfortunately we can not do a lot of it in a compatible way during KF5, because the unified KNSCore::Entry class does not exist yet and can not be added without keeping compatibility for yet another Entry class variant. Also the entry classes are used in signals, here we would be forced to either create overloaded signals or create them under a new name. Consumers should ideally use `auto` when interacting with return values from the APIs. Also we should investigate providing typedefs that will allow one to adapt the code during KF5. For the signals one could investigate adding overloads that use the typedefs and guard them with deprecation wrappers. Then consumers that disable deprecated code will not have source-code-compat issues during the KF6 migration.

Currently we have a bunch of classes for the KNewStuff entries: - KNSCore::EntryInternal - KNS3::Entry - KNSCore::EntryWrapper Ideally we only have one class called KNSCore::Entry. This can be exposed to QML using a Q_GADGET, then the EntryWrapper can be dropped. The KNS3::Entry class should be removed, the remaining usage in the widget classes should be changed to KNSCore::Entry. Unfortunately we can not do a lot of it in a compatible way during KF5, because the unified KNSCore::Entry class does not exist yet and can not be added without keeping compatibility for yet another Entry class variant. Also the entry classes are used in signals, here we would be forced to either create overloaded signals or create them under a new name. Consumers should ideally use `auto` when interacting with return values from the APIs. Also we should investigate providing typedefs that will allow one to adapt the code during KF5. For the signals one could investigate adding overloads that use the typedefs and guard them with deprecation wrappers. Then consumers that disable deprecated code will not have source-code-compat issues during the KF6 migration.