[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: David Edmundson <david () davidedmundson ! co ! uk>
Date: 2020-04-16 21:38:23
Message-ID: CAGeFrHBdT7n3rOiQ8Fs+xD8180jZ3cHFV__5E9O_AToARr940A () mail ! gmail ! com
[Download RAW message or body]
On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens <ervin@kde.org> wrote:
>
> Hello,
>
> 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.
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.
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.
> > 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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic