Page MenuHomePhabricator
Create Task
Maniphest T9004

Unexisting applications should not be added on the bar when creating new desktop
Open, Incoming QueuePublic
Actions

Description

I tried a new build of E25, and noticed the dock has a launcher of an app which is not installed. Seems like the .order file (e/applications/bar/default/.order) is populated without checking if the application is installed or not (I have the .desktop file in the system, but the application is not installed)

Note that this is not the case of the Menus, which does deeper checks on the efreet values, so this applications is (correctly) not included in the menus even if i have the .desktop file installed. I think the menus also check for other important values like NotShowIn=X-Enlightenment;

raster added a comment.Apr 22 2022, 1:46 AM

ibar can't have an icon for an app that is not installed... the desktop file must exist for it to appear. your problem is you have a desktop file for something you don't have. the problem you have is that desktop file... it's advertising the existence of something that is not there.
even if listed in the .order file - it will not show if the .desktop file is not found. if the desktop file appears again the icon will appear.

you shouldn't have the .desktop file if the app doesn't exist. yes - the menus check the notshowin or showonlyin stuff because they list everything you have installed thus will use the filters. ibar is explicit as to what you choose to add to it - it's user controlled. it's explicitly intended to put any desktop files there you like thus it wont look at showin/notshowin.

Thanatermesis added a comment.Sun, Apr 24, 6:10 PM

sometimes there's .desktop files in the ~/.local dir of the user which is not maintained (application can be removed and .desktop stills here), or maybe system .desktop files that are meant to overwrite the default one, in any case if I'm not wrong this is what the TryExec= option is for (to verify that the application actually is installed)

some examples:

efl source code:

src/lib/efreet/efreet_desktop.h
103:    char *try_exec;         /**< Binary to determine if app is installed */
104-    char *exec;             /**< Program to execute */

E source code:

src/bin/e_int_menus.c
754-/*
755: * This function searches $PATH for try_exec or exec
756: * return true if try_exec or exec is found!
757- */
...
raster added a comment.Mon, Apr 25, 1:25 AM

desktop files in ~/.local are to be maintained by the user... so - this is an issue that the user is not maintaining them... :) every check you do to verify something badly maintained costs overhead and certainly something like ibar that is explicitly maintained by a user to only have in it what they want to be there is thee uswer's job.

think of the opposite. user creates a custom desktop file puts in a tryexec and typos the line... then they add to ibar and it just doesn't appear. they keep adding and nothing happens. they go "what the hell?"... is this better than an icon being there that when run fails to run something because the command doesn't exist anymore? the menus are auto-populated from everything that exists. ibar is not. it is explicitly populated by what the user says to populate it with. :) (if a desktop file is there that doesn't exist that's another matter as there is literally ZERO information to present (and no desktop file is ever listed anywhere to add to it so this above add and nothing happens won't happen... and if the desktop file were to be removed then it vanishes which would be pretty much what you'd expect).