So, I don't really know if this is something that used to be working with .desktop/regular application start-up, or if this was introduced with the systemd units work, but I'm seeing currently that the wait fence in qt homescreen isn't doing what it should be doing, meaning waiting until the application has actually started. The qt homescreen for starting applications in the panel, has a specific wait and afterwards, and afterwards do the activation. But I don't believe this is the underlying issue here, but it is connected.

I've also verified with the launcher application, which basically does the same (but the activation happens indirectly), so my speculation at this point is that appStarted event being sent by applaunchd back to homescreen shell client is sent a bit way ahead of the application actually starting (by that, I mean created the surface role). The systemd unit started, but the application itself does take some (epsilon) amount of time to actually start.

Protocol debugging shows that we're sending the activation request to early, point in which the application itself wasn't started. 

It seems we're sending the activation way before the application actually created a surface/top level role, so the start-up & activation works only because the policy that the compositor activates application at start-up, by default.

What prompted me to take a look at this is that I was planning on cutting some of the code in the compositor related to activation by default, but it turns out that's really not an option at this point.

Ideally, I would've like to have the activation driven only the shell client, not indirectly by the compositor. It would've been a far better design.

I can see a few different roads to take here:

• always have this policy and remove the other one. Currently, the biggest issue I have with this thing is that there quite a few corner cases where we need to tackle both start & activate situation but, also start and do not activate situation, but later on, to still allow activation to work out. What I'd like to avoid keeping this situation where we allow both to co-exist. Either we leave this design as is, such that activation is always on, like we do now, but we remove activate-by-default=false functionality. This should avoid at least the need to provide that functionality and minimize the amount of bugs/regressions I have with it. No one is actually testing this, but some people seem to be using it.

• explicitly synchronize start with activation. The way to do that is to allow the compositor to signal back to the shell client, with an event when that surface was actually created so we can correctly correlate the sequence of events. This means that appStarted event is only sent after the shell client received from the compositor an event saying that the application started. Requires adding a new applaunchd <-> shell client message in-between. To me this seems the most reliable way of making sure the application started.

• finally, which is probably a bit more harder to do is to send the appStarted event not when the systemd unit was started but after, but I don't really see how we would this reliably, with having something in application to send back the systemd (much like systemd-notify we have in the compositor).