QPA plugin like functionality in frameworks?

[Albert Astals Cid]

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 <mgraesslin at 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 <mgraesslin at 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 at 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