QPA plugin like functionality in frameworks?

[Aleix Pol]

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.

Aleix