Description of problem: In Mageia-8 beta1, mime types are not bound to file extensions. Version-Release number of selected component (if applicable): Mageia-8-Cauldron How reproducible: --- Tested in MATE and LXDE. I think it's the same in other DE's... su/password update-mime-database /usr/share/mime Results in Mageia-7.1 (comparison): --- touch ./1.url; xdg-mime query filetype ./1.url application/x-mswinurl touch ./1.urpmi-media; xdg-mime query filetype ./1.urpmi-media application/x-urpmi-media touch ./1.urpmi; xdg-mime query filetype ./1.urpmi application/x-urpmi Results in Mageia-8-beta1 (fresh installation from the network): --- touch ./1.url; xdg-mime query filetype ./1.url text/plain touch ./1.urpmi-media; xdg-mime query filetype ./1.urpmi-media text/plain touch ./1.urpmi; xdg-mime query filetype ./1.urpmi text/plain Trying to set your mime type in Mageia-8-beta1: --- touch ./application-x-foobar.xml Content ./application-x-foobar.xml: --- <?xml version="1.0" encoding="UTF-8"?> <mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info"> <mime-type type="application/x-foobar"> <comment>foo file</comment> <icon name="application-x-foobar"/> <generic-icon name="application-x-foobar"/> <glob-deleteall/> <glob pattern="*.foo"/> </mime-type> </mime-info> --- xdg-mime install ./application-x-foobar.xml update-mime-database /usr/share/mime touch ./1.foo; xdg-mime query filetype ./1.foo text/plain As a result of the fact that mime types are not bound to extensions, it is not possible to assign an icon to a specific file and there will probably be problems with assigning default apps to certain file types. Sincerely, Alex
Is the package mailcap present in that installation? On Mageia 7 ... # rpm -q -f /etc/mime.types mailcap-2.1.48-2.mga7 # urpmq --whatrequires mailcap|sort -u alpine apache firefox mailcap
CC: (none) => davidwhodgins
In Mageia-7 the mailcap package is not present: # rpm -q -f /etc/mime.types error: /etc/mime.types: There is no such file or directory # urpmq --whatrequires mailcap|sort -u alpine apache firefox mailcap
Try installing it. If that fixes the issue, it's a missing requires. Another package to check is shared-mime-info.
Hello, Dave Hodgins. Thank you for your cooperation. The packages you specified are installed, unfortunately the result is negative. If you don't mind, I'll explain the situation with a live example (the audacity program)... As you know, audacity can create and save a project file with the *.aup extension. By default, the rpm package does not include icons that are displayed as saved *.aup. To assign an icon to an already registered mime type, just put the *.svg icon in /usr/share/icons/hicolor/scalable/mimetypes and update the icon cache. The simplest option. #urpmi --auto audacity Create and save the audacity project under the name: ./my_project.aup Let's find out its mime type: #xdg-mime query filetype. /my_project.aup application/x-audacity-project Accordingly, the MIME-type icon should be named application-x-audacity-project.svg (the slash is replaced with a hyphen). To avoid searching, I left the icon in the attachment (application-x-audacity-project.svg.tar.gz). Copy the icon to the directory: /usr/share/icons/hicolor/scalable/mimetypes and make a cache update: gtk-update-icon-cache -f /usr/share/icons/hicolor. Let's create another audacity project and save it. Result: --- In Mageia-7.1, the saved project *.aup will be displayed as an icon that was copied earlier. In Mageia-8-beta1, on the contrary, the file is displayed as a plain text (white sheet). This problem applies to programs that pull their own mime types and icons that correspond to the file extensions that these programs work with. As you know, there are many of them. At the moment, Mageia-8-beta1 does not display associative icons brought from outside. Only the built-in ones work (for example, LibreOffice), although the default porgram is assigned (sample: xdg-mime default foobar.desktop application/x-foobar). What else could be the problem? With respect, Alex
Created attachment 12013 [details] application-x-audacity-project.svg.tar.gz
I can't reproduce the issue in current Cauldron Xfce with audacity example from comment 4. After copying extracted application-x-audacity-project.svg to /usr/share/icons/hicolor/scalable/mimetypes and running 'sudo gtk-update-icon-cache /usr/share/icons/hicolor/' I can see correct icon with .aup file in thunar.
CC: (none) => jani.valimaa
Anyhow I added mime-type icon for .aup files in audacity-2.4.2-7.mga8.
Created attachment 12015 [details] Thunar and Caja I can reproduce the issue with Caja (MATE file manager) in Xfce. See the attached screen shot.
Hello, Jani Välimaa. Thank you for the information and screenshots. I just installed XFCE from the network and installed "audacity" with a mime-type icon. It shows everything in Thunar, but not on the Desktop. If you change the system icons from Adwaita to Oxygen, the icons of the "audacity" mime-type are displayed correctly on the Desktop. As soon as I return to Adwaita, on the Desktop again an empty icon. :) If you switch icons to a different system theme in your XFCE, will it have the same effect? Why do the Adwaita icons "overlap" the MIME-type icons of "audacity" (and probably others installed personally in the future)? After all, there are no icons or mime in ~/.local/share? Sincerely, Alex
Looks like that this is a combination of icon theming issue and how apps follows the freedesktop.org icon-theme-spec an/or mime-apps-spec. If I play with different icon themes and their index.theme Inherits key I can see correct mime-type icon with Nautilus, Caja or Nemo. Only Xfce's Thunar seems to be working OOTB.
But how can we take into account the whole factor of mime types, if, for example, the program is used in different DE and different FM? It turns out that it doesn't make sense to take into account mime types with personal icons when developing programs, since these types/icons may be "overlapped" by others in one way or another? What is the right thing to do in this situation?
File upstream bugs against file managers and/or desktop environments you're using. According to freedesktop.org icon spec: "Implementations are required to look in the 'hicolor' theme if an icon was not found in the current theme". [1] "The lookup is done first in the current theme, and then recursively in each of the current theme's parents, and finally in the default theme called 'hicolor' (implementations may add more default themes before 'hicolor', but 'hicolor' must be last)." [2] [1] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout [2] https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#icon_lookup
Jani Välimaa, thank you for the explanation and links, I will definitely read it. Should I close this "bug" or will you do it yourself?
Temporary solution: --- Added all problematic MIME-type icons to the Adwaita theme and made gtk-update-icon-cache -f /usr/share/icons/Adwaita. I checked in MATE, LXDE, XFCE, Budgie (Nemo); in parallel, I changed the themes of the icons built into DE - now everything works and does not fly off. I don't know how much is correct, but I'll leave it at that for now. More icons (*.png) of different sizes are needed; one scalable was not enough.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Temporary solution 2 (cardinal): --- Downgrade "adwaita-icon-theme" 3.38.0 -> 3.37.2 from source code... Hi, Jani Välimaa. After a series of tests, it became clear that the last working version of "adwaita-icon-theme" = 3.37.2. I rolled the "adwaita-icon-theme" it to this version and all previously invisible (white/plain) icons mime-types were displayed correctly, including for example files with extensions VirtualBox (*.vdi, *.vbox, *.vmdk) and others. Downgrade "adwaita-icon-theme" 3.38.0 -> 3.37.2 from source code... go to terminal... su/password urpmi --auto wget make automake autoconf Cleanly delete the installed version of "adwaita-icon-theme" 3.38.0: --- wget https://github.com/GNOME/adwaita-icon-theme/archive/3.38.0.tar.gz tar xvzf 3.38.0.tar.gz cd ./adwaita-icon-theme-3.38.0 ./autogen.sh ./configure --prefix=/usr make install; make uninstall Install the "adwaita-icon-theme" version 3.37.2: --- wget https://github.com/GNOME/adwaita-icon-theme/archive/3.37.2.tar.gz tar xvzf 3.37.2.tar.gz cd ./adwaita-icon-theme-3.37.2 ./autogen.sh ./configure --prefix=/usr make install p.s. Tested in Mate. I'll leave it here just in case...
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Can you test with latest adwaita-icon-theme again? Remove /usr/share/icons/Adwaita/*/mimetypes/application-x-generic.* icons, run 'gtk-update-icon-cache -f /usr/share/icons/Adwaita/', relogin to DE and see what happens.
Ок... 1. First, I installed the latest Mageia updates (glibc-2.32-3 ...) and reboot 2. Removed "adwaita-icon-theme" -3.37.2 and installed "adwaita-icon-theme"-3.38.0 ...mime type icons are white again 3. rm /usr/share/icons/Adwaita/*/mimetypes/application-x-generic.* rm: delete file '/usr/share/icons/Adwaita/16x16/mimetypes/application-x-generic.png'? y rm: delete file '/usr/share/icons/Adwaita/22x22/mimetypes/application-x-generic.png'? y rm: delete file '/usr/share/icons/Adwaita/24x24/mimetypes/application-x-generic.png'? y rm: delete file '/usr/share/icons/Adwaita/32x32/mimetypes/application-x-generic.png'? y rm: delete file '/usr/share/icons/Adwaita/48x48/mimetypes/application-x-generic.png'? y rm: delete file '/usr/share/icons/Adwaita/512x512/mimetypes/application-x-generic.png'? y 4. gtk-update-icon-cache -f /usr/share/icons/Adwaita/ 5. reboot Result: mime-type icons are displayed well, everything is fine (now I'm focusing on *.vdi, *.vbox, *.vmdk, since I have several VM's here). The result is positive. :)
Status of this please?
CC: (none) => ouaurelien
Hello, Aurelien Oudelet. Status = in progress. All proposed solutions are temporary. The MIME types icons from the 'adwaita-icon-theme' package overlap the MIME types icons from the lower hierarchy theme - 'hicolor', and it doesn't define itself. It is not possible to get newly registered MIME types without manual intervention.
Aurelien Oudelet, I forgot to add "status"... Following in the footsteps of Jani Välimaa, I temporarily collected an metapackage (patch) for myself adwaita-mime-patch-1-0.mrx8.noarch.rpm: https://cloud.mail.ru/public/4XHM/3AeR7XSSp ... with two pairs of scripts in events: --- %post rename -v \.png \.bak $(find /usr/share/icons/Adwaita/*/mimetypes/ -name 'application-x-generic.*') gtk-update-icon-cache -f /usr/share/icons/Adwaita/ %postun rename -v \.bak \.png $(find /usr/share/icons/Adwaita/*/mimetypes/ -name 'application-x-generic.*') gtk-update-icon-cache -f /usr/share/icons/Adwaita/ After installing this patch, the display of MIME-type icons works correctly. After deleting the package, everything returns to its original state. That is, to quickly roll back when the problem is resolved. p.s. Of course, it's a "crutch", but it temporarily simplifies my life... :)
Hello, Jani Välimaa. I decided to write about the problem with adwaita-icon-theme-3.38 directly on "gitlab". In the end, it must end with something. :) https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/108
Thanks all for your testing and search. Assigning. (Please set the status to 'assigned' if you are working on it) Meanwhile, this is an upstream issue.
Assignee: bugsquad => olavStatus: REOPENED => NEWURL: (none) => https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/108Source RPM: (none) => adwaita-icon-theme-3.38.0-1.mga8.src.rpmKeywords: (none) => UPSTREAM
Hi, Aurelien. After 3 months, Jakob Steiner (developer of adwaita-icon-theme) did not see the problem and closed my request. :) The updated adwaita-icon-theme (40.rc) contains the same defect: https://github.com/GNOME/adwaita-icon-theme/releases/tag/40.rc The solution seems to me in the complete removal of the "adwaita-icon-theme" or in the application of a previously created patch. I moved the patch address to my GitHub: https://github.com/AKotov-dev/adwaita-mime-patch It would probably be logical to close this error report as well. Аs the French say - "C’est la vie". :) Sincerely, Alex