[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-frameworks-devel
Subject: Re: Problems in KWayland causes by API and ABI compatibility promises
From: Kevin Ottens <ervin () kde ! org>
Date: 2020-04-17 5:25:34
Message-ID: 3562902.uuDegYsK1h () wintermute
[Download RAW message or body]
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@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
["signature.asc" (application/pgp-signature)]
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic