[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Raising windows on Wayland
From:       David Edmundson <david () davidedmundson ! co ! uk>
Date:       2018-07-03 16:58:33
Message-ID: CAGeFrHDTfRRng8VKwWFHAvK2PYZFxirLcE-oTEGg3fvHS4QMhQ () mail ! gmail ! com
[Download RAW message or body]

>
> Ideally this needs to be standardized so that it does not only work with
> our applications but with any.
>

Even within just KDE apps, we have code like QDesktopServices spawning
links in code we can't manipulate. Anything non standard, simply isn't
worth merging.

But I don't think standardising anything would be too hard.

Effectively we want something like xdg-foreign which exists. The difference
is that it lasts temporarily and it's not manipulating parents.

There are two interesting questions:

Do we want/need to support wayland window sending activating an xwayland
window?

Would we need a serial of the user event (xdg_popup style)? It would which
kinda matches the X event timestamps?
It's trickier as you'd need a protocol to generate a UUID for both that and
the surface to sidechannel, but it's not impossible.

---

The other potential solution that I was wondering about, that's waaay
simpler, definitely waaay crappier, but possibly simple enough to just work
without really having issues.

Could client A just release focus (somehow) when spawning an app? If
nothing has focus and toplevel B appears, it seems sensible that kwin would
focus it.

[Attachment #3 (text/html)]

<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Ideally this \
needs to be standardized so that it does not only work with our applications but with \
any.<br></blockquote><div><br></div><div>Even within just KDE apps, we have code like \
QDesktopServices spawning links in code we can&#39;t manipulate. Anything non \
standard, simply isn&#39;t worth merging.<br></div></div><div \
class="gmail_quote"><br></div><div class="gmail_quote">But I don&#39;t think \
standardising anything would be too hard.</div><div \
class="gmail_quote"><br></div><div class="gmail_extra">Effectively we want something \
like xdg-foreign which exists. The difference is that it lasts temporarily and \
it&#39;s not manipulating parents.</div><div class="gmail_extra"><br><div \
class="gmail_quote">There are two interesting questions:</div><div \
class="gmail_quote"><br></div><div class="gmail_quote"><div>Do we want/need to \
support wayland window sending activating an xwayland \
window?</div><div><br></div><div>Would we need a serial of the user event (xdg_popup \
style)? It would which  kinda matches the X event timestamps?</div><div> It&#39;s \
trickier as you&#39;d need a protocol to generate a UUID for both that and the \
surface to sidechannel, but it&#39;s not impossible.<br></div></div><div \
class="gmail_quote"><div><br></div><div>---</div><div><br></div><div>The other \
potential solution that I was wondering about, that&#39;s waaay simpler, definitely \
waaay crappier, but possibly simple enough to just work without really having \
issues.<br></div><div><br></div><div>Could client A just release focus (somehow) when \
spawning an app? If nothing has focus and toplevel B appears, it seems sensible that \
kwin would focus it.<br></div><div><br></div><div><br></div><div><br></div></div></div></div></div>




[prev in list] [next in list] [prev in thread] [next in thread]