Page MenuHomePhabricator

E wayland mode - launching apps like terminology always leads to ibar icon being "disabled/busy starting"
Closed, ResolvedPublic

Description

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 ...

raster created this task.Sep 21 2017, 4:09 PM
zmike triaged this task as TODO priority.Sep 25 2017, 11:33 AM
zmike removed a project: enlightenment-git.

There's no protocol for startup ID, so this has never worked and cannot work until such protocol is standardized.

This has been going on with X, Wayland, you name it for as long as I can remember -- Elementary apps never handle their startup signals correctly. Always get stuck.

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.

zmike added a comment.Sep 26 2017, 8:47 AM

This has been going on with X, Wayland, you name it for as long as I can remember -- Elementary apps never handle their startup signals correctly. Always get stuck.

Definitely not the case, this has always worked under X and continues to work under X.

In T6071#99525, @raster wrote:

it used to work... then broke.

It worked coincidentally.

In T6071#99525, @raster wrote:

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.

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.

zmike added a comment.Sep 26 2017, 9:16 AM

This is an ibar issue as far as why it coincidentally stopped working; it watches for the E_EVENT_EXEC_NEW_CLIENT event to change the icon state and doesn't update on E_EVENT_EXEC_NEW.

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... :)

stephenmhouston added a comment.EditedSep 27 2017, 6:34 AM

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

zmike added a comment.Sep 27 2017, 8:21 AM
In T6071#99663, @raster wrote:

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... :)

https://git.enlightenment.org/core/enlightenment.git/tree/src/bin/e_comp_wl.c#n1893

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

Could be quicklaunch I guess? Dunno, always worked fine here.