Start terminology (click on ibar) and the icon goes into "busy starting"mode... and stays that way UNTIL you then click again to run a 2nd terminology. Something causes e to be unable to track the window of the first terminology to the exec instance (and thus tell ibar to make the icon active again). This has been going on for a few months ...
it used to work... then broke.
as for it not being possible: there is the ability to tack via PID though in wayland. there is a direct socket to the client... that can be queried for the PID on the other end of it and matched up.
there is also set_app_id that can be used as a fallback as it should match desktop name. just saying... it can be done. on the x side e already can use name+class (equivalent to app id) to match, can use PID (the netwm pid property as in x you cant otherwise know the pid... since the xserver holds the sockets)... but sure - there isn't the equivalent of startup id yet. there should be though.
Definitely not the case, this has always worked under X and continues to work under X.
It worked coincidentally.
I'm aware, and this is why it used to work coincidentally. GNOME already has a protocol for this, but they've been working on other things and haven't reviewed it or polished it enough for standarization yet.
what happened to E_EVENT_EXEC_NEW_CLIENT ? that is the one that is meant to happen when a new window is seen that matches that execution. i assume that's the "no pid ect. etc. matched" you speak of. but without any new protocols we could:
struct ucred cred; int len = sizeof(struct ucred); getsockopt(socket_fd, SOL_SOCKET, SO_PEERCRED, &cred, &len); printf("%i\n", cred.pid);
when a new wayland client connects... then we could at least set up the pid info in e_client... :)
Here is a video of it happening on X ... happens with luncher or ibar... I've always just chalked it up to elm quicklaunch... but I think it shows there could be something larger at play here. Everything up to date. http://www.smhouston.us/stuff/icon_start_stuck.ogv