On Wed, Jun 24, 2015 at 9:51 AM, Martin Gräßlin <mgraess...@kde.org> wrote: > On Tuesday 23 June 2015 19:35:48 Aleix Pol wrote: >> On Tue, Jun 23, 2015 at 9:42 AM, Martin Gräßlin <mgraess...@kde.org> wrote: >> > Hi framework-developers and packagers, >> > >> > with two frameworks I'm currently in the need to have something like QPA. >> > I >> > want to make it possible to provide windowing-system specific plugins for >> > frameworks using a private API. The need arises first of all in >> > kwindowsystem to support wayland [1]. To implement it we need a >> > dependency to KWayland, which is currently part of kde-workspace and not >> > yet up to the quality and stability levels needed to make it a framework. >> > The second framework where I need such functionality is kglobalaccel >> > where kwin needs to take over a large part of the functionality of the >> > runtime to make it work on wayland at all. >> > >> > I see the following possibilities to solve the problem: >> > 1.Make it a private API without any ABI guarantee >> > 2. Make it a public stable API with ABI guarantee >> > 3. Make it a private API with so-version changes whenever the ABI changes >> > >> > Option 1 is closest to what Qt's QPA does, but I think this would be a >> > nightmare for packagers. >> > >> > Option 2 could result in a nightmare for developers especially in the >> > plugin infrastructure itself. With releases every month that could >> > quickly end in classes like KWindowSystemPrivate32 and result in an >> > unmanageable runtime check system. >> > >> > Personally I think Option 3 is the cleanest solution. Would this be >> > acceptable for everyone? If yes are there any suggestions for where to >> > install headers to, for naming the libraries, etc? >> > >> > Looking forward for your input, >> > >> > Cheers >> > Martin >> > >> > [1] And obviously also other windowing systems if distributions/OSes want >> > to add support for it. >> > _______________________________________________ >> > Kde-frameworks-devel mailing list >> > Kde-frameworks-devel@kde.org >> > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel >> >> Hi Martin, >> We already have something similar with frameworksintegration, maybe it >> would make sense to integrate what you need there? > > Frameworksintegration doesn't really help as it's still part of frameworks and > thus cannot depend on workspace libraries like kwayland. Also it's absolutely > no solution for the problem of kglobalaccel (that feature must(!) be provided > by kwin, there is no other way). > >> The biggest problem I see is that you want it in kde-workspace and >> it's really complex to use a changing library within 2 different >> release cycles. It will make things break on one side or another. >> >> What you can do is a stable plugin API and then provide the Wayland >> plugins from Plasma releases. X11 and others can remain within >> frameworks. > > That's option 2 from above. As said above I fear that this will be problematic > due to the very short release cycle of frameworks and will create many > subclasses just to keep it ABI stable. Of course it's doable, but well...
Well, these aren't completely new abstractions I guess, they're just not public interfaces yet. If you start with wayland and X11 backends (and ideally win/mac too), it should be a solid-enough interface already so it doesn't need to change on the very next iteration. Aleix _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel