<romangg>
jadahl: That's already listed in step 9 though, I thought that 7 meant some other request.
<jadahl>
there is only one way to pass a token and ony one way to request activation, and its the same request
<jadahl>
maybe those steps can be clarified that they mean are in fact a single request being sent
<romangg>
Let me later try to formulate an MR for that. There was also some other description in the actual protocol I stumbled over when trying to understand it.
<gitlab-bot>
wayland issue (Merge request) 95 in wayland-protocols "xdg-activation-v1: clarify set_app_id and set_surface" [Opened]
MatrixTravelerb4 has quit [Remote host closed the connection]
<romangg>
Is my interpretation correct? If yes, why should a client at all specify a surface? If it doesn't we fall back to asking if any surface of the client has focus, so that makes the call to set_surface redundant.
floof58 has quit [Read error: Connection reset by peer]
leon-p has joined #wayland
<emersion>
romangg: yes, and i think we should add the same warning to set_serial
<romangg>
true
<emersion>
whot: thanks for working on ci-templates freebsd
<emersion>
a +1257 patch is pretty scary…
<emersion>
(for comparison, my wayland patch is +104…)
<whot>
emersion: no worries, thanks to you it showed it was mostly down to "download raw file and run it in qemu"
<whot>
emersion: I think only 20 lines of that are the actual freebsd bits, the rest is boilerplate to have the templates (and tests)
<whot>
and it fits in with the rest of ci-templates, so you'd just need to extend from .fdo.qemu-build@freebsd and set all the same variables and you get an image
* emersion
reads the "End of FreeBSD-specific bits" section
<emersion>
well, glad there are some ci-templates wizards out there :)
<whot>
blame bentiss for that bit, I mostly just shuffle things around :)
<emersion>
daniels, did you have comments on the wayland freebsd CI?
<emersion>
pq, what were the missing explciit-sync bits in weston?
<pq>
emersion, err, I guess getting the release fence from KMS and sending it to clients?
<emersion>
ah right
<romangg>
emersion: I thought about it some more and I can imagine one case where the set_serial call would not be redundant: if you have a "special client", like a desktop shell that does never get focus but if you click on some launcher icon in it another client is started,
<emersion>
the click event has a serial
<romangg>
The compositor may only honor the associated activate request of the new client if in the meantime no other click happened on another client.
floof58 has joined #wayland
<emersion>
(1) i suspect if the user launches an app then focuses something else, you won't want to interuupt the user's work by focusing the new toplevel?
<romangg>
"the click event has a serial" yea, but the compositor may not know anymore which one it was once the token request comes in. But tbh I'm not 100% sure if it would work without it too.
<romangg>
emersion: re (1): yea
<emersion>
(2) if the launcher is a special client, the compositor can add a special case for it
<emersion>
if (wl_client == launcher) { activation token is always valid }
<emersion>
or something
<romangg>
re (2): sure
cedric has joined #wayland
<romangg>
Ok with (1): the compositor would ignore the activate of a token, if between requesting token and activate some other client is focused than the one that requested the token. Correct?
<emersion>
that's compositor-specific policy
<emersion>
but that sounds like a reasonable policy, yes
<emersion>
some compositors might have a fallback, e.g. mark the toplevel as urgent
bluebugs has quit [Ping timeout: 480 seconds]
<emersion>
(e.g. red indicator in the taskbar)
<romangg>
And for a special client like a desktop shell, which does not get real focus, it would check on requesting token if the last click happenend on a surface of that desktop shell. If not it can assume between a click on the desktop shell and the arrival of the token request some other client was focused.
<emersion>
the click gives pointer focus
<romangg>
the "it" in "it would check" is the compositor
<emersion>
well
<emersion>
tbh focus isn't really relevant i think
<emersion>
what matters i think is that focus hasn't changed after the click happened
<emersion>
(again, compositors are free to implement what they want here)
<romangg>
true, pointer focus is on the surface of the shell when the click happens. sorry, forgot that.
<romangg>
ok, makes sense then.
<emersion>
focus is kind of complicated, because there are many kinds of focus
<emersion>
pointer focus, keyboard focus, xdg-shell active state
<romangg>
and the set_serial request seems redundant like the set_surface one.
<emersion>
it depends. sometimes the client doesn't have a serial at hand
<emersion>
use-case: a terminal emulator receives a bell sequence from a CLI app. it wants to mark itself as urgent
<emersion>
the foot terminal emulator does this
<emersion>
in this case, bringing the client to the front would be annoying for the user
<emersion>
so the compositor should probably either do nothing or indicate that the client requests attention
<romangg>
true, but what requests would it need to send then so the compositor knows to only set it as urgent?
LordLamer has joined #wayland
LordLamer has quit [Remote host closed the connection]
<emersion>
compositors wouldn't get a set_serial request
<emersion>
(or an invalid one, or an outdated one)
<emersion>
when compositors don't have a valid, up-to-date serial, they can avoid bringing the toplevel to the front
floof58 has quit [Ping timeout: 480 seconds]
<romangg>
Ok, that's a cool idea. But that clients might expect compositors to react to a missing set_serial request on an activate request like this is pretty implicit in the protocol text. :P
<romangg>
I wouldn't thought of this use-case at least. So thanks for bringing it up.
<romangg>
It's a bit a dirty area, because clients are meant to only care about themselves and not the compositor state. But in this case the client's assumptions influence the compositor's global state.
floof58 has joined #wayland
<romangg>
emersion: You got a similar example for when sending or rather omitting to send the set_surface request can be relevant?
<emersion>
omitting should happen if the client doesn't have a surface
<emersion>
or doesn't have a surface that can be tied to the activation
<emersion>
i think it should almost never happen
<emersion>
one possible case is when a client is completely minimized in an icon tray or something
<emersion>
but then not sure why it would need a token
<emersion>
(if the user clicks the tray icon to un-minimize, the client should get the token from there)
<romangg>
Yea, and if the client has no surface the compositor would know that too.
<emersion>
btw, we should add an activation-token field for whatever SNI uses for input events
<emersion>
something like org.freedesktop.StatusNotifierItem.ActivationToken
<emersion>
which can be called right before any of the other methods
<emersion>
cc apol[m]
<romangg>
So is the TLDR about set_serial/set_surface requests like this: the set_serial request has a reasonable use case with a client only wanting attention but not activation (although that could be a request with a single boolean too), but the set_surface request is redundant?
jlindgren has joined #wayland
jlindgren has quit [Remote host closed the connection]
<emersion>
romangg, what do you mean by "redundant"?
<emersion>
how would a bool help for set_serial?
timsmall[m4 has joined #wayland
timsmall[m4 has quit [autokilled: This host has violated network policy. Contact support@oftc.net with questions (2021-06-15 10:16:21)]
<emersion>
in the usual case, clients send both set_serial/set_surface
<emersion>
the special edge-cases are when they don't
<romangg>
Well, that was my question in the beginning: why should we transmit information about a singular surface if a compositor would usually decide about the request token's authorization on the basis if _any_ surface of the requesting client currently has focus.
Peter[m]225 has joined #wayland
<pq>
sounds a bit hazardous to assume that all surfaces of a client are somehow related
Peter[m]225 has quit [Remote host closed the connection]
<emersion>
thunderbird has both an email client and an IM client built in
<emersion>
maybe each of these parts have different surfaces
<pq>
IOW, "any surface of a client" is a phrase that should not be used IMO.
<emersion>
a client might be waypipe, which aggregates surfaces from many different clients on the remote side
<emersion>
some compositors might ignore set_surface, some others might not
<romangg>
pq: why should the phrase not be used.
Woet_ has joined #wayland
Woet_ has quit [Remote host closed the connection]
<pq>
romangg, because it may result in an unrelated, wrong surface
<pq>
exactly what emersion was just explaining
<pq>
If you need "any surface", you have to explicitly define which set of surfaces is considered. All surfaces of a client is a too wide set as the surfaces may be completely unrelated.
sstiller has joined #wayland
<romangg>
emersion: the waypipe example is an interesting one. It would just pipe along xdg-activation requests from its clients and trust in the host compositor to prevent non-allowed "subclient" requests based on the set surface.
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #wayland
<romangg>
pq: Is the waypipe case an example for what you mean?
<pq>
yes
<pq>
even gnome-terminal could be an example of that, as it uses a single daemon for multiple unrelated windows.
rasterman has quit []
rasterman has joined #wayland
aleasto has quit [Remote host closed the connection]
aleasto has joined #wayland
floof58 has quit [Read error: No route to host]
floof58 has joined #wayland
dcz has quit [Ping timeout: 480 seconds]
naveenk2 has quit []
<romangg>
pq: yea, with the set_surface call the compositor gets more information to decide on its own if a request should be honored. otherwise it would need to trust for example on some internal mechanism of gnome-terminal for "focus-stealing prevention" for its separate terminal windows.
<romangg>
Thanks for the discussion.
naveenk2 has joined #wayland
<romangg>
emersion: You mentioned earlier you want to add a field to SNI. You want to discuss that some more or you have already an idea how to proceed? Tbh I don't know much about SNIs though.
<emersion>
romangg: the activate request. this is unclear and should be clarified
andol29 has quit [Remote host closed the connection]
<Levans>
apol: looks like matrix messages are not forwarded to IRC currently
<romangg>
emersion: added a LGTM
<emersion>
thx!
<Levans>
apol: Or, actually, it's only yours, mine went through. You might want to leave & rejoin.
<romangg>
emersion: I'm working on clarifying this.
apol[m] has left #wayland [#wayland]
<emersion>
cool
apol[m] has joined #wayland
<Levans>
apol: your messages still don't get through :/ Probably best to ask for help on #irc:matrix.org, I suspect that's a common issue, they'll likely know how you can fix it.
<romangg>
emersion: Question about this: Is XDG_ACTIVATION_TOKEN only set by the launcher or also populated again with a token value when an already launched app should be activated again. For example when file explorer opens another document in an already launched text editor.
robertmader[m] has joined #wayland
robert_mader has quit [Quit: Leaving.]
apol[m] has left #wayland [#wayland]
apol[m] has joined #wayland
<emersion>
when you launch another client, set XDG_ACTIVATION_TOKEN in its environment
<emersion>
when you're launched, use the XDG_ACTIVATION_TOKEN from your env, then remove XDG_ACTIVATION_TOKEN from your env
apol has joined #wayland
<romangg>
In the second case how does the client which requested the token populate the XDG_ACTIVATION_TOKEN env var in the env of the already launched other client?
<emersion>
the launcher requests a token before starting the child process
apol has quit []
apol has joined #wayland
<pq>
in the second case, the new child process that talks to the daemon that hosts all the document windows needs to take the token and transmit it to the daemon.
<emersion>
right
<pq>
the same way it tells the daemon to open the document
khfeng has quit [Remote host closed the connection]
khfeng has joined #wayland
apol[m] has left #wayland [#wayland]
apol[m] has joined #wayland
<apol[m]>
a
<pq>
apol[m], it works!
<apol[m]>
finally >.< sorry, was saying things until I realised y'all were not just ignoring me but that I wasn't properly logged in oftc
<emersion>
something something OFTC should add SASL support something
<apol[m]>
or we should use a protocol from this century :D
<apol[m]>
but also SNI is not in xdg-specs per se, because some people didn't want it back then
<apol[m]>
that's why I never created that MR
<emersion>
ah, i see
<apol[m]>
but I might be missing something
<emersion>
that's annoying
<emersion>
this addition looks good to me, modulo docs
<emersion>
but why is there a freedesktop.org website for SNI then?
<apol[m]>
because KDE really wanted it to be a standard, notmart did most of the work though
apol has quit []
<emersion>
this "half a fdo standard" situation is confusing
floof58 has quit [Remote host closed the connection]
floof58 has joined #wayland
abc_ has joined #wayland
abc_ has quit [Remote host closed the connection]
st3r4g has joined #wayland
<romangg>
pq: Ok, so one could say in this second case this is some proprietary way of forwarding the token.
<romangg>
But the launched child process still gets it first written into its XDG_ACTIVATION_TOKEN env var.
floof58 has quit [Remote host closed the connection]
<pq>
romangg, yup.
floof58 has joined #wayland
<romangg>
Besides child processes there is also D-Bus Activation which is often used to launch apps. In this case I assume the new/reactivated client should instead look into the platform_data in its D-Bus interface org.freedesktop.Application as the xdg-activation-v1 protocol says.
<gitlab-bot>
xdg issue (Merge request) 47 in xdg-specs "RFC: Let DBus-activated processes properly integrate on Wayland" [Opened]
<romangg>
Too many moving parts! XD
<romangg>
Would an overview document be good to just link all currently open MRs about that xdg-activation?
Fanch has joined #wayland
Fanch has quit [Remote host closed the connection]
s8548a__ has joined #wayland
s8548a__ has quit [Remote host closed the connection]
naveenk2 has quit [Ping timeout: 480 seconds]
<pq>
emersion, should I pick up the wayland-scanner patches from James Legg on the mailing list, or will you? I guess someone just flushed the moderation queue.