Problems in KWayland causes by API and ABI compatibility promises

[Kevin Ottens]

Hello,

On Thursday, 16 April 2020 23:38:23 CEST David Edmundson wrote:
> On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens <ervin at kde.org> wrote:
> > On Wednesday, 1 April 2020 14:04:10 CEST David Edmundson wrote:
> > > Here is a list of active uses of the KWayland::Client API.
> > > 
> > > frameworks
> > > 
> > >     plasma-framework (for window positioning)
> > > 
> > > apps:
> > >     spectacle (for window positioning)
> > >     kdeconnect-kde  (for fake input)
> > >     yakuake (for window positioning)
> > > 
> > > extragear
> > > 
> > >     latte-dock (for window positioning, custom shadow (which could be
> > > 
> > > ported already) and windowmanagement)
> > 
> > The part of the list above makes me wonder, shouldn't the window
> > positioning and windowmanager features be on KWindowSystem?
> 
> Yeah, doing that will resolve 90% of the client cases.
> In general for things like blur and everything the slightly higher
> level abstraction is working out better as we can abstract X and
> wayland in one go, which really helps the client code.

Sounds like a plan then.
 
> Also, it's worth really clarifying that in absolutely any proposal
> KWayland as-is can't go away, so clients using that will still
> function.

Of course, it's just that the one in KF would become frozen and deprecated 
until KF6. But then the development would move on with the other copy which 
would be less of a burden for everyone.

> The slight twist on that which we need to be wary of is that client
> code will return shared objects if you request a
> KWaylandClient::PlasmaShellSurface::get(window())
> for the same window from two places you'll get the same PlasmaShell
> instance returned - and therefore the same wl_resource.
> If we hypothetically had a kwayland2::client also have a
> plasmashellsurface::get() method we would have two plasma_shellsurface
> wl_resources's for the same wl_surface which is a protocol error and
> our client will get violently killed.

Honestly you lost me here. :-)

> > > workspace:
> > >     kwin unit tests
> > >     libkscreen
> > >     breeze (till Qt5.15)
> > >     oxyen (till Qt5.15)
> > >     xdg-desktop-portal
> > >     kinfocenter
> > >     plasma-workspace
> > >     plasma-nano
> > >     kscreenlocker
> > >     powerdevil
> > >     kwayland-integration (the backend for kwindowsystem)
> > >     plasma-phone-components
> > >     plasma-integration
> > 
> > I think the above is less of an issue, right? Because workspace would have
> > a copy of KWayland which could be shared with whatever stability
> > constraints needed.
> 
> It means it has to stay as an exported workspace lib, but yeah it
> wouldnt' be a problem.

Yes, exactly my position as well.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20200417/61bd8e34/attachment.sig>