Forum › Forums › Official Releases › antiX-19 “Marielle Franco, Hannie Schaft, Manolis Glezos, Grup Yorum, Wobblies” › Problems with mimeopen, desktop-defaults-set and antiX
- This topic has 8 replies, 4 voices, and was last updated Dec 28-10:42 am by Xecure.
-
AuthorPosts
-
December 15, 2020 at 5:25 pm #47495Member
Xecure
Since some time ago (I don’t know since when), the /usr/share/applications/ folder divides applications between:
“normal” (as in coming from default debian repos or not managed by the antiX team) – Their .desktop entries are in the main folder.
“antiX” (as the ones worked by the antiX team) – The .desktop files are hosted in a subdiretory named “antiX”.Some time ago, I realized that some programs that use mimeopen (like firefox-esr) would not correctly use the Rox-filer to open the Downloads folder, and instead loaded SpaceFM search. I found the solution was using the mimeopen -d “/any/folder/path” command to set up the correct mime application to manage opening folders.
Fast-forward to today. Now I am better equipped to read and understand (some) code. I was reading the implementation of desktop-defaults-set to try to call it from a separate gui, and found that, when running, it spouted some sed errors. After analyzing the script, I can see it updates the $HOME/.local/share/applications/mimeinfo.cache, and tries to place whatever is the selected favorite program as the first in the list for every option that contains it. But, if the program is not in the list, it cannot be placed first.
I tried to manually place rox-filer.desktop first for some of the entries, but then running the mimeopen command ignored rox-filer.Now we come to the reason for this post. I found that mimeopen cannot load any .desktop file that is not directly inside the first level of /usr/share/applications or inside $HOME/.local/share/applications/ folder, so all .desktop files inside /usr/share/applications/antiX/ cannot be recognized by mimeopen. My best workaround was copying the .desktop to $HOME/.local/share/applications/, but that creates a duplicate when using App Select to search for apps. Is there a better workaround?
Also, what happens when a user tries to set as a preferred application a .desktop file outside any of the default paths I listed above? mimeopen will not work or replace any of the options. Is there any better idea to circumvent this that is not copying the .desktop file to local /applications/ folder?
Also, what is the correct way to update $HOME/.config/mimeapps.list? Could we get desktop-defaults-set to also modify the file? It would be better for setting up the real default application for all programs that uses mimeopen.
Here is an initial implementation of the idea of replacing options in mimeapps.list placed inside the gui I am building for managing desktop-session options. I copied part of the current desktop-defaults-set script (fixing the sed command problems) and added the copying of .desktop files (when not in /usr/share/applications) that leads to duplication in App Select. [It is a bit ugly, but I will fix this with a patch for dialogbox].
https://filebin.net/5m988xl5kozgln9kThe main function that does the updating of mimeapps.list is:
# Build MIME temp files# Check if the desktop file is NOT in /usr/share/applications # and copy it to $HOME/.local/share/applications if [ ! -f "/usr/share/applications/${PROGRAM_NAME}" ] \ && [ ! -f "$HOME/.local/share/applications/${PROGRAM_NAME}" ]; then cp -f "$PROGRAM_PATH" "$HOME/.local/share/applications/" SPECIFIC_MIME_APP="$MIME_ADDED_LIST" fi # Replace every mime entry related to the current Program for word in $CHANGE_MIME_LIST; do # remove the default entry sed -i -e "s#^${word}=.*##g" "$SPECIFIC_MIME_APP" # add the new entry: echo "${word}=${PROGRAM_NAME};" >> "$SPECIFIC_MIME_APP" done # remove empty spaces sed -i -e '/^$/d' "$SPECIFIC_MIME_APP" # Copy back all entries to mimeapps.list echo "[Default Applications]" > "$USER_MIMEAPPS_LIST" cat "$MIME_DEFAULT_LIST" >> "$USER_MIMEAPPS_LIST" echo "" >> "$USER_MIMEAPPS_LIST" echo "[Added Associations]" >> "$USER_MIMEAPPS_LIST" cat "$MIME_ADDED_LIST" >> "$USER_MIMEAPPS_LIST"As you can see, it separates between apps inside /usr/share/applications (and sets them up as [Default Applications]) and the ones that are not (and sets them up inside [Added Associations]). This makes it work (at least in SpaceFM so that all, for example, text files open with the selected preferred application, and not only the command desktop-defaults-run -te). Also, if a browser or file manager is not set properly inside mimeinfo.cache, the mimeapps.list will help open links, html files (or mimeopen folder for file manager) automatically for applications that use mimeopen.
Could we fix this for the future antiX release?
I will help as much as my knowledge permits it. Let me know how to help.antiX Live system enthusiast.
General Live Boot Parameters for antiX.December 15, 2020 at 6:20 pm #47499MemberPPC
::Some time ago, I realized that some programs that use mimeopen (like firefox-esr) would not correctly use the Rox-filer to open the Downloads folder, and instead loaded SpaceFM search. I found the solution was using the mimeopen -d “/any/folder/path” command to set up the correct mime application to manage opening folders.
I’ve been wondering about that for a very long time… I have no idea how I fixed that – Firefox now opens the correct folder under SpaceFM on all my installs…
It’s an annoying little bug that I forgot about…P.
December 15, 2020 at 6:26 pm #47501Anonymous
::what is the correct way to update $HOME/.config/mimeapps.list?
(train of thought)
sudo updatedb
locate mimeapps.list
dpkg-query -S /etc/skel/.config/mimeapps.list
^—v
desktop-defaults-spacefm-antixspaceFM user guide (section titled “MIME Menu”)
http://ignorantguru.github.io/spacefm/spacefm-manual-en.html
After reading that (it is too long to paste here, and it contains inline hyperlinks)
I would ask you to rephrase the question.what is correct way for a user to update his local copy of mimeapps.list seems clear, per the UserGuide
vs
how to amend the content within the “default” (skel) copy of mimeapps.list
seems like would require pull request sent to desktop-defaults-spacefm-antix
but
issuing an updated package won’t benefit existing user accounts
because policy demands “don’t touch user files”
so the updated content will not get populated to each user’s local copy of mimeapps.list____________
related:
sudo apt install galternatives
man update-alternativesDecember 15, 2020 at 6:32 pm #47505Anonymous
::my “I have no idea” thought//realization is this:
Although I make heavy use of spaceFM -} Open -} Choose
and certainly must have, at least once, ticked the box
“set as default application for this filetype”
…the content of my user’s local mimeapp.list is identical the the copy in etc/skelDecember 15, 2020 at 6:43 pm #47506Forum Admin
Dave
::Last I looked into fixing the sed commands there was ~ 4 different files in ~/ that set defaults. ~/.local/share/applications/mimeinfo.cache, ~/.local/share/applications/mimeapp.list, ~/.mimeapp.list, ~/.config/mimeapps.list IIRC. Never mind the system level/non user versions of the files. All the same file but related to different versions of xdg compatibility. Each requiring special attention, and utilized by different programs. Maybe this has settled down and only one or two are used? I was trying to find a cleaner way of doing this, maybe the alternatives system as skidoo points to. However when I last looked, I think the alternatives system is a debian brewed system for setting defaults and therefor added yet another way separate from the others.
- This reply was modified 2 years, 4 months ago by Dave.
Computers are like air conditioners. They work fine until you start opening Windows. ~Author Unknown
December 15, 2020 at 8:55 pm #47512Member
Xecure
::My tests:
mimeopen will default to [Added Applications] inside $HOME/.config/mimeapps.list. If nothing there, it jumps to [Default Applications] and if nothing there it searches the $HOME/.local/share/applications/mimeinfo.cache until something matches. The big problem with mimeopen is that it cannot find .desktop files outside of /usr/share/applications/ and $HOME/.local/share/applications/. It also gets “blocked” when it encounters an “unknown” .desktop in the local mimeapps.list and jumps directly to the general mimeinfo.cache (in /usr/share/applications), skipping $HOME/.local/share/applications/mimeinfo.cache entirely. This is the problem I encountered initially with firefox-esr (it would jump to spacefm-find.desktop).xdg-open will default to [Default Applications] inside $HOME/.config/mimeapps.list. If no option is configured, it ignores [Added Applications] and directly jumps to $HOME/.local/share/applications/mimeinfo.cache (and goes for the first option in the list, and continues jumping until finding a .desktop that works). xdg-open is smarter than mimeopen, and can find .desktop files inside any subfolders in /usr/share/applications/, so it works more reliably.
If we can get mimeopen to register the antiX folder, then there is no need to create copies inside $HOME/.local/share/applications/
Although I make heavy use of spaceFM -} Open -} Choose
and certainly must have, at least once, ticked the box
“set as default application for this filetype”
…the content of my user’s local mimeapp.list is identical the the copy in etc/skelMy experience is that “Set as default” checkbox in spacefm creates an entry in $HOME/.config/mimeapps.list under [Added Applications], so you must be lucky and haven’t customized too much.
Based on skidoo’s link
When MIME looks for a desktop file, first it looks in ~/.local/share/applications, then in /usr/local/share/applications, and then in /usr/share/applications, using the first copy it finds.
Is there a way to also add /usr/share/applications/antiX/ to mimeopen?
antiX Live system enthusiast.
General Live Boot Parameters for antiX.December 15, 2020 at 11:42 pm #47519Anonymous
::“Set as default” checkbox in spacefm creates an entry in $HOME/.config/mimeapps.list under [Added Applications]
That might be the result of selecting an opener which isn’t already in spacefm’s list.
plaintext } Open } multiple handlers are displayed in the (my) context menu:
leafpad, tea, pluma, mousepad, geany, vim.tiny, nano.
-=-
clicking any of these and choosing “Set as default” simply floats the selection to top slot in the context menu and sets it as the spaceFM double-click opener for plaintext filesSeparately, and I’ve seldom ever meddled with it
“Open } File Handlers…”
dialogbox deals with configuring per-mimetype handlersDecember 27, 2020 at 9:19 pm #48217Anonymous
::man update-alternatives
After reading the manpage and interacting with the update-alternatives command, it wasn’t clear to me what “groups” (sets of alternative application peers) were available. Maybe I somehow missed seeing a mainmenu, but none of the options I explored wound up presenting a list of the available groups. Eventually I discovered an easy way to explore what groups it “knows” along with the peers that the update-alternatives is tracking (along with the assigned “priority” for each of the individual peers).
apt install ranger
#(218kb, 862kb installed size)
ranger /var/lib/dpkg/alternatives
# as you navigate up/down the list of files, the content of each is displayed in the rightmost paneI recall wrestling with the issue of quirks (expecting vs “choking on” quotation marks, absence of “hold open” option) inherent to each of the various x-terminal-emulators while working on the code for gexec, and that I had left in place some breadcrumb notes https://gitlab.com/skidoo/gexec/-/blob/master/gexec.c#L64
update-alternatives does not consider such quirks, nor their implications, but a calling application (e.g. antixcc or gexec) absolutely must do so.
The debian update-alternatives mechanism is “global” (is not customizable “per user”) and, unless carefully/frequently curated by a local sysadmin, its highest-priority “selection” within each given program group is prone to becoming “auto-mangled” each time dpkg adds/removes installed packages.
That, above, is my walkthrough toward understaning “Why not (just) embrace the existing debian update-alternatives mechanism?”
[..] it separates between apps inside /usr/share/applications (and sets them up as [Default Applications]) and the ones that are not (and sets them up inside [Added Associations]). This makes it work (at least in SpaceFM so that all, for example, text files open with the selected preferred application, and not only the command desktop-defaults-run -te). Also, if a browser or file manager is not set properly inside mimeinfo.cache, the mimeapps.list will help open links, html files (or mimeopen folder for file manager) automatically for applications that use mimeopen.
Could we fix this for the future antiX release?
Here I’m suggesting (proposing? opining?) that desktop-defaults-run probably should be regarded as “reserved for use from within scripts” rather than something which is exposed to and customizable by end users.
December 28, 2020 at 10:42 am #48257Member
Xecure
::My experiments on changing options in $HOME/.config/mimeapps.list and $HOME/.local/share/applications/mimeinfo.cache have worked so far with SpaceFM, so for now I am happy with the compromise of editing them. My only trouble is that I cannot seem to get a local change for default x-terminal-emulator, so I opted for a global change, as skidoo suggested.
antiX Live system enthusiast.
General Live Boot Parameters for antiX. -
AuthorPosts
- You must be logged in to reply to this topic.