mart added a comment.
In D17079#364263 <https://phabricator.kde.org/D17079#364263>, @apol wrote: > In D17079#364163 <https://phabricator.kde.org/D17079#364163>, @ltoscano wrote: > > > In D17079#364157 <https://phabricator.kde.org/D17079#364157>, @mart wrote: > > > > > I think this ui should really go into KCoreAddons itself. Would it be accepted there? > > > > > > kcoreaddons is tier1 just like kirigami. Why not create a new Frameworks, kirigami-addons (or another appropriate name), which would collect all the common UI items which depends on other frameworks? Basically the kxmlgui of Kirigami. > > > I think an external framework is a big overkill. In this case, it's only runtime dependencies so both either kcoreaddons or kirigami could offer it. I would favor putting it in kirigami because there's the duck-typing opportunity there too, but it may be a stretch. > That said, we'll need someone to register the KAbout* types somewhere too, but we can also rely on applications doing that as a first iteration. one thing i'm a bit concerned is kirigami becomeing too much of a QML kdelibs monolith :p REPOSITORY R134 Discover Software Store REVISION DETAIL https://phabricator.kde.org/D17079 To: apol, #plasma, #frameworks Cc: mart, leinir, ngraham, ltoscano, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol
