Should we retire the QMake support for KF6? - plan is to drop after branching, unless somebody steps up to maintain this
https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/452 - needs feedback, the approach discussed two weeks ago wasn't entirely applicable due to QXcbWindow not being accessible Android/Qt6 CI - waits for https://invent.kde.org/libraries/phonon/-/merge_requests/5 to be reviewed plasma-integration port - if somebody wants to have fun with D-Bus menu API that no longer exists ;) - possibly related: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/52 https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/95 - move to widgetaddons is conceptually not ideal, but matches the current practical usages, which are all in widget-based consumers - Kirigami as a tier1 frameworks couldn't use it anyway even if it was in KGuiAddons - Plasma 6 would probably need a QML API for this, replacing the current data engine - alternative: leave this in gui addons but move the password edits to a yet to be defined tier2 framework - possible approach: rename kcompletion to kinputwidgets to widen its scope so we can move the password widgets there - only actionable once we branch - we can accept the MR and add a task to clean this up in KF6, but we won't need to export the class, we can keep it as an implementation detail https://phabricator.kde.org/T12232#268214 - David F replied Plasma 6 sprint - Mar 5-6, attend! https://phabricator.kde.org/T12183 - Android matches our current .desktop based model relatively well - next steps: research how this works on Windows/macOS, ie. does our existing data model/query API work for those too? - might be entirely independent of KF6
signature.asc
Description: This is a digitally signed message part.