Where to put kwayland integration plugins

[Martin Graesslin]

On Saturday, July 2, 2016 8:59:28 PM CEST you wrote:
> On samedi 2 juillet 2016 15:25:39 CEST Martin Graesslin wrote:
> > On Saturday, July 2, 2016 11:41:11 AM CEST David Faure wrote:
> > > 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.
> > 
> > That's actually not the case. Both KIdleTime and KWindowSystem (runtime)
> > depend on additional Wayland protocols currently only provided in KWin/
> > Wayland. That means your KIdleTime based application won't work in e.g.
> > GNOME.
> 
> OK so things are less interoperable than I thought
>   -- so much for "whatever the problem is, wayland will fix it!" ;-)

Only currently. I hope to see at least the idletime integration getting 
standardized.

> 
> However that only makes my last paragraph moot, not the rest of the
> argument, AFAICS.
> 
> In fact it even leads to another possible solution : if these plugins are
> only useful in Plasma5, then there's no problem with putting them into
> plasma- integration, is there?

Except that e.g. LXQt might use KWin and then they need it. But given that 
KWin is from Plasma one could argue that they should also use kwayland-
integration from Plasma.

Ok, I'll leave it as it is for now and will reevaluate the situation once we 
have the protocols standardized.

Cheers
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160704/6d036e4a/attachment-0001.sig>