El Dijous, 25 de juny de 2015, a les 08:46:07, Martin Gräßlin va escriure: > On Wednesday 24 June 2015 23:20:21 Aleix Pol wrote: > > 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-de...@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. > > This assumes the API is done and is no longer extended. That's not the case, > the API got extended at a constant pace over the last few months. Each > addition to the API will need an addition to the "private" API in measure > of adding a new virtual method.
There's ways to workaround the virtual method BIC issue, first lame one that comes to mind is using meta object system instead of the C++ virtual stuff if it's not a hot path, afaik our Binary Compatibility page list a few others (virtual_hook). Cheers, Albert > > Cheers > Martin _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team