<div dir="ltr"><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 5, 2018 at 4:56 PM, Drew DeVault <span dir="ltr"><<a href="mailto:sir@cmpwn.com" target="_blank">sir@cmpwn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not sure why an activiation request has to jump through these<br>
surface export hoops first. <br></blockquote><div><br></div><div>I think it's important to distinguish focus/raising from urgent/needs attention hints.</div><div><br></div><div>I'm only interested in focus/raising. <br></div><div><br></div><div>Historically on X there was a problem of windows claiming focus randomly and unexpectedly; especially with things like random password prompts when things loaded. Kwin certainly has an insane amount of focus protection logic and rules.</div><div><br></div></div><div class="gmail_quote">If you're not going to give focus to any client that asks, it means you need some way to separate a client asking for attention and the currently focused client being ok with it. <br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I see where you're going with this, though: an atomic and secure way of<br>
transferring focus to another application. This looks like an attempt to<br>
express something like intents on Wayland. <br>
<br></blockquote><div>I think xdg-portal is becoming the closest thing we have to intents in the desktop space.</div><div><br></div><div>Currently you'll see a "string: window" argument in most the methods which ties in with the current xdg_foreign.</div></div><div class="gmail_quote">I basically want that, but I don't always want a parent/child relationship.<br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Perhaps designing an out-of-band intents system first, then having it<br>
express some kind of handle, which can then be referred to from Wayland<br>
for the purpose of securely transferring focus, would be a better<br>
approach. It's hard to design a good Wayland protocol against the<br>
ephemeral "it may exist eventually" out-of-band negotiation process.<br></blockquote><div><br></div><div>Right, I phrased that very badly.</div><div><br></div><div>There is a pre-existing out of band system for X startup notifications that is defined in the places I said. This exists and is used certainly in Qt/Kde and GTK code (weirdly gtk wayland also uses desktop_startup_id ...)<br></div><div><br></div></div><div class="gmail_quote">X startups are a bit more involved as clients inform the system what exact process they're starting with atoms for the icon and a name, so the taskbar can pre-empt things and do startup feedback then pass an ID of this startup window to the other client.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">But ultimately there's a string ID which gets passes between windows out of band, and kwin on X uses that as a major clue of if a client should get raised.<br></div><div class="gmail_quote"><br></div></div></div><div>Effectively all that needs defining is new variable names. <br></div></div>