Page MenuHomePhabricator

enlightenment_open still uses deprecated defaults.list
Closed, ResolvedPublic



I was having trouble modifying default applications for some mimetype (inode/directory and application/x-bittorrent) without success, and I realized that's because enlightenment_open still uses the deprecated $XDG_DATA_HOME/applications/defaults.list to determine default applications.


I am using Arch Linux x86_64, and have several WM and DE installed (Enlightenment 0.22.1, GNOME 3, Xfce 4). efl 1.20.7.

When using GNOME or Xfce, opening downloaded items from Firefox or opening folders from transmission-qt will open my default applications (like thunar and transmission), but in Enlightenment, opening folder from firefox/transmission-qt/xdg-open results in opening visual-studio-code, and gvim for opening torrents.

After some debugging I found out that those applications all use xdg-open to handle opening urls, who then calls enlightenment_open.

I tried editing default applications using xfce4-mime-settings but enlightenment_open didn't change its behavior; Enlightenment Default Application Settings doesn't have an entry for inode/directory, but does for application/x-bittorrent, although set to GVim.

Some straceing of enlightenment_open leads me to ~/.local/share/applications/defaults.list which I googled that is deprecated and should be merged to $XDG_CONFIG_HOME/mimeapps.list (usually ~/.config/mimeapps.list). The difference between these files is that defaults.list only has one [Default Applications] section, while mimeapps.list has 3 sections: [Added Associations], [Removed Associations] and [Default Applications]. Their [Default Applications] have exactly the same purpose and should be merged to mimeapps.list if possible.

I also checked the source file for enlightenment_open, in src/bin/e_open.c:116 function handler_find, the logic is hard coded to find $XDG_DATA_HOME/applications/defaults.list. I think change the path is sufficient.

Currently I created a symlink defaults.list -> ~/.config/mimeapps.list and it works like a charm.

caiye created this task.Mar 20 2018, 2:41 AM
Herald closed this task as Invalid. · View Herald TranscriptMar 20 2018, 2:41 AM
Herald added a project: Restricted Project. · View Herald Transcript

The Enlightenment ticket system is currently receiving high amounts of spam tickets. This ticket has been closed as spam because it lacks both a project and an assignee. If this ticket is not spam, please reopen it after adding these items.

caiye assigned this task to raster.Mar 20 2018, 2:46 AM
caiye reopened this task as Open.
caiye updated the task description. (Show Details)
caiye edited projects, added enlightenment-git; removed Restricted Project.

when did they change it from defaults.list?

btw - enlightenment still writes to defaults.list when it updates what the last app you used to open a file in efm... so it's consistent within e. to move files around is a bit of a pain. have to provide an upgrade path to copy old content over to the new location. if a file already exists - should e go overwrite it or not? likely not as that'd be the trigger to know if it should migrate over. bah. why did they change?

well first you need to double check on your pam build if it was enabled or not. but my reproduction case was "pam not enabled". if you have some other reason for it to fail, then i am not aware of what it would be right now. maybe it cant run enlightenment_ckpasswd (/usr/local/lib/enlightenment/utils/enlightenment_ckpasswd or maybe different depending on prefix and what autotools decides to do). you can test by just doing:

echo "mypasswd" | /usr/local/lib/enlightenment/utils/enlightenment_ckpasswd

if it says nothing - it authed correctly. if it said "Password auth fail" ... then it failed to auth. e reiles on the return code.

gah. there's 12 different places e looks for defaults.list in ~/.local/share/ ... spread around.

caiye added a comment.Mar 20 2018, 4:08 AM

The freedesktop specification says in April 2014 that default applications should go to mimeapps.list, and xdg-utils adds support back in 2011. I guess defaults.list is used before the specification came out?

defaults.list was what the thing was before then... i dont remember if it was specced or not. i just made it work. beats me what added and removed associations are for. if i were to change stuff i need to provide an upgrade path and that most likely will be the above. i don't imagine i'd write support for the added or removed ones so they'll be lost if e modifies this file.

caiye added a comment.Mar 20 2018, 4:26 AM

Well I don't really know how e writes defaults.list, but I just symlink'ed defaults.list to mimeapps.list, tried to modify default application, and the added and removed sections are kept, with default application modified.