On Sunday, 21 April 2024 00:37:03 CEST Ben Cooksley wrote: > On Sun, Apr 21, 2024 at 1:51 AM Kevin Ottens <[email protected]> wrote: > > Hello, > > > > On Saturday 20 April 2024 15:12:48 CEST Ingo Klöcker wrote: > > > On Freitag, 19. April 2024 22:40:38 CEST Ben Cooksley wrote: > > > > On Sat, Apr 20, 2024 at 4:39 AM Kevin Ottens <[email protected]> wrote: > > > > > The example you give shows Plasma depending on Gear, this shouldn't > > > > > happen, so > > > > > I'd argue: let's fix that instead. > > > > > > In my opinion the same goes for Gear depending on Plasma. > > > > Agreed, just didn't want to muddy my message and so focused on only one > > direction. But it's definitely a topic to explore as well. > > > > One thing I'm unsure for instance is: do we want to make Gear -> Plasma > > dependencies completely forbidden? > > > > We might consider this going one step too far. I could understand if a > > Gear > > app wants to provide "more integration" in a Plasma session. So mandatory > > Gear > > -> Plasma dependencies, I agree are to forbid, but optional ones? I'm less > > certain. > > I've considered whether it was feasible to ban such dependencies in the > past, however always ended up in the position that it wasn't feasible to do > so. > This will require a degree of projects being moved around, code being > broken out into separate modules, etc. but I think it is solvable given > enough commitment to do so. > > We probably need a home for "not quite Frameworks but shared libraries none > the less" to make this achievable. > > The usual tripping points ended up being: > - Various graphics and multimedia libraries such as libkdcraw, libkexiv2, > etc > - Various PIM libraries, often related to Akonadi integration for Workspace
One approach to solve that is/was to actually turn those into frameworks. A bunch of PIM libraries were moved over time (KContacts, KCalendarCore, KDAV, etc) already. More were lined up, the KF6 transition just put a pause on that, but e.g. KMime not too long ago received a bunch of API fixes in preparation for this. However, before continuing down that road I'd like to see a decision on the KF release schedule first now. With a much longer release cycle this becomes a lot less interesting to do. Regards, Volker
signature.asc
Description: This is a digitally signed message part.
