Hi,
KWayland is a library that provides convenience wrappers for Wayland
protocols. Usually, when we want to implement some Wayland protocol,
first, we add corresponding wrappers in KWayland and after that we
actually implement the protocol in KWin.
Unfortunately, we made a bad design choice
We had a meeting. It resulted in some final action decisions.
These will affect the kwayland folder in frameworks.
The meeting was attended by: Kevin Ottens, Vlad Zahorodnii, Aleix Pol,
Myself, Benjamin Port who all approved the plan.
*Protocols:*
We make a new repo. It will contain just protoco
There's definitely a problem, and I think it's a lot more than just
discussing location and protocol versions.
My typical workflow is reading the wayland protocol in detail, and
kwayland is in that awkward position where I absolutely still need to
read those underlying docs and the abstraction kwa
On Tue, Mar 17, 2020 at 11:27 AM David Edmundson
wrote:
>
> There's definitely a problem, and I think it's a lot more than just
> discussing location and protocol versions.
>
> My typical workflow is reading the wayland protocol in detail, and
> kwayland is in that awkward position where I absolut
On 3/17/20 12:27 PM, David Edmundson wrote:
IMHO we're lacking a "what actually is kwayland?" and an accurate
definition of what's the added value compared to just using the auto
generated classes directly.
That's a good question! On one hand, it's nice to have Qt-friendly
wrappers for Waylan
>
> That's a good question! On one hand, it's nice to have Qt-friendly
> wrappers for Wayland protocols. On the other hand, it would be even
> better to have a library to write Wayland compositors. So, one just
> needs to plug a few classes in order to get started with drm and
> xdg-shell stuff.
>
On Mon, Mar 23, 2020 at 3:45 PM David Edmundson
wrote:
>
> >
> > That's a good question! On one hand, it's nice to have Qt-friendly
> > wrappers for Wayland protocols. On the other hand, it would be even
> > better to have a library to write Wayland compositors. So, one just
> > needs to plug a fe
There's another problem we're going to hit with kwayland at some point
in the future.
KWayland specifies the protocol version.
This means, according to framework policies we might have a released
kwin which suddenly gets a new protocol version of something being
announced.
I just had a near miss
On mardi 24 mars 2020 17:55:48 CET David Edmundson wrote:
> There's another problem we're going to hit with kwayland at some point
> in the future.
Sorry for hi-jacking, but there's another problem we're hitting right now in
kwayland...
There seems to be a nasty use-after-free in the testWaylandS
Hi,
On 3/24/20 6:55 PM, David Edmundson wrote:
I just had a near miss with XdgOutputV1(version2) which luckily we
were able to easily guard. Had the spec claimed that in version2
sending xdg_output.name was mandatory we would have been completely
screwed.
Unfortunately, I have bad news. We're
I'll take care of it. It's still fixable within KF5 in the usual way.
Let's follow up specifics of this on bug 419222 so we can keep this
thread about the more general strategy.
But it serves as a nice example to the type of problem we're facing.
David
Hi,
On 3/24/20 4:35 PM, Aleix Pol wrote:
We can decide what we want for KF6 and act accordingly. If for
example, we were to split kwayland into kwaylandclient and
kwaylandserver and the latter be in plasma, we could consider putting
new code in KWin or a shared repository.
I was also thinking
Hi,
On 3/23/20 4:44 PM, David Edmundson wrote:
Yeah, I feel that's what kwayland was originally going for. Seat, for
example, does a lot of dispatching and logic internally.
Then it drifted into being just wrappers.
We do need to answer that question definitively otherwise we'll be
forever stuc
Hello,
First, a big fat disclaimer: I'm by no mean expert in what's going on the
Wayland side, so take what I'll be writing here with truck loads of salt.
I'm jumping in mainly because it looks like you guys are in pain and I'm
trying to lend a hand to find a way forward. It's obviously written
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 shad
FWIW I ported KDE Connect away from it here:
https://invent.kde.org/kde/kdeconnect-kde/-/merge_requests/199
Leaving the rest as plasma-specific components.
Aleix
On Wed, Apr 1, 2020 at 2:04 PM David Edmundson
wrote:
>
> Here is a list of active uses of the KWayland::Client API.
>
> frameworks
>
Kevin, thanks for your input.
I think there's a general feeling towards forking the server completely.
But we need to decide something concrete, and this ML is dying down. I
propose we have a voice/video chat with the objective of agreeing on a
concrete plan both short term and for KF6 and then j
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)
> yakua
> Given Doodle's take forever and everyone's probably quarantined
> anyway, I propose we do it just after the Monday Plasma meeting. If
> someone is eager to share an opinion and can't make that, message here
> and we'll choose something more formally.
That didn't really work out. Doodle it is!
h
On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens 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
Hello,
On Thursday, 16 April 2020 23:38:23 CEST David Edmundson wrote:
> On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens 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
> > >
> > >
> > 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 w
On Thu, Apr 16, 2020 at 10:26 PM David Edmundson
wrote:
>
> > Given Doodle's take forever and everyone's probably quarantined
> > anyway, I propose we do it just after the Monday Plasma meeting. If
> > someone is eager to share an opinion and can't make that, message here
> > and we'll choose some
23 matches
Mail list logo
