QPA plugin like functionality in frameworks?

Milian Wolff mail at milianw.de
Wed Jul 1 16:27:19 UTC 2015


On Tuesday 30 June 2015 20:33:09 Albert Astals Cid wrote:
> 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).

Another way to achieve the same was implemented by Christoph Cullmann in the 
KatePart/Kate/KTextEditor based on KF5. Essentially, the interfaces are non-
virtual and delegate calls to some actual implementation via 
QMetaObject::invokeMethod. See e.g. KTextEditor::MainWindow.

The advantage is that the public headers can be extended at will (adding non-
virtual functions keeps source and binary compatibility). The downside is that 
there is a small performance penalty (which could be somewhat reduced by using 
static QMetaMethod and invoking them). And, probably more important, there is 
no compile-time check that the invoked methods are available in the 
implementation side.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de


More information about the release-team mailing list