Where to put kwayland integration plugins

[David Faure]

On lundi 6 juin 2016 11:26:58 CEST Aleix Pol wrote:
> On Mon, Jun 6, 2016 at 8:32 AM, Martin Graesslin <mgraesslin at kde.org> wrote:
> > Hi framework-developers,
> > 
> > in Plasma we have a repository called kwayland-integration. It provides a
> > plugin for:
> > * KWindowSystem
> > * KIdleTime
> > 
> > using the KWayland client API. Thus it makes these frameworks functional
> > on
> > windowing system Wayland.
> > 
> > I want to move the plugins into frameworks and are wondering how to do
> > that
> > and where to move them to.
> > 
> > I see the following options:
> > 1. Integrate directly into kwindowsystem and kidletime
> > 2. Merge them into frameworks-integration
> > 3. Create a new framework kwayland-integration
> > 4. create a new framework "kwindowsystem-wayland" and "kidletime-wayland"
> > 
> > Option 1 is I think an absolute no-no as it would turn kwindowsystem and
> > kidletime from tier 1 to tier 2 and that would affect a huge amount of
> > other frameworks. For everything which is not in tier 1, I think it's the
> > way to go.
> > 
> > Option 2 is something I don't want to do as that would combine windowing
> > system integration code with random other stuff and would result in weird
> > dependencies. (To use KIdleTime on Wayland one needs X11 and Phonon?)
> > 
> > The same actually also applies to Option 3, though it is just two
> > frameworks and all dependencies would be tier 1.
> > 
> > So personally I think option 3 or option 4 are the way to go.
> > 
> > What do you think? Better ideas?
> 
> I agree ideally it's 3 or 4. Where do you have it now? Are they
> already separate repositories? If so, just moving them to frameworks
> could make sense.
> 
> In Purpose I have a similar problem (and I know the discussion is also
> relevant for other frameworks). We usually don't want plugins to raise
> the tier of your base framework, but you still need them to be
> distributed together and either way you need to make sure the plugins
> will be available when the system is deployed (which is actually much
> easier in option 1).

The alternative is to use option 1 with a cmake option to disable the 
kwayland-based plugin. This offers benefits because
- on systems with wayland enabled, you are sure the plugin is present (no bug 
report like "idle detection doesn't work" (because of a missing package))
- on systems where dependencies should be kept to a minimum (e.g. an X11-based 
embedded system) one can easily compile without the kwayland dependency

Application developers using KIdleTime or KWindowSystem do expect it to work 
on all platforms where the application works, so surely a dependency on 
kwayland can't be a problem on wayland.

The benefit of the plugin architecture is that this reduces #ifdefs and  
therefore risk of breakage when only testing with the wayland build enabled. 
It doesn't mean we need to move the plugins to yet-another-framework.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5