every time I want to open those filetypes from other apps or system-dialogues SFOS asks me if I want to open it in gallery. That is annoying because gallery is not able to open these files.
Is there a way to stop that behaviour?
In jolla-gallery.desktop, replace the image/* wildcard with just/all the mime types you want Gallery to open:
MimeType=image/*;x-scheme-handler/rtsp;video/*;
3 Likes
I haven’t run into this problem, but I would prefer the gallery to properly display those files (at least the ones which are not suffering from patent issues).
hm, in my /usr/share/applications/jolla-gallery.desktop there is no MimeType=image/;
so I changed in /usr/share/applications/jolla-gallery-openfile.desktop
[Desktop Entry]
Type=Application
NoDisplay=true
Name=Gallery
X-MeeGo-Logical-Id=gallery-ap-name
X-MeeGo-Translation-Catalog=gallery
Icon=icon-launcher-gallery
Comment=Sailfish MimeType Handler for Gallery
MimeType=image/;
X-Maemo-Service=com.jolla.gallery
X-Maemo-Object-Path=/com/jolla/gallery/ui
X-Maemo-Method=com.jolla.gallery.ui.showimage
X-Desktop-File-Install-Version=0.23
MimeType=image/*; to MimeType=image/jpeg;image/png;image/jp2;image/webp;
and I see two effects:
I now get a open-with-dialogue even with jpeg files (with two duplicated jolla-gallery entries)
and jolla-gallery won’t open any file anymore. It just opens the x-Pictures/y-Videos/z-Screenshots overview
when opening via fingerterm it says:
[nemo@Sailfish Pictures]$ jolla-gallery Jolla_01.jpg
…
SailfishKeyProvider_ini_read: unable to open file
SailfishKeyProvider_storedKey(): error: no scheme or key found for provider/service
…
and a lot of “Service xyz with data type “Images” will be inactive” messages [xyz=onedrive,dropbox,…]
I am still able to open videos, because internally that seems to happen via jolla-gallery-playvideostrem.desktop
okay, the .desktop file was not changed correctly:
X-Maemo-Method=com.jolla.gallery.ui.showimage has to be X-Maemo-Method=com.jolla.gallery.ui.showImages
now, jolla-gallery opens files again, but still open-with-dialogues and duplicated entries…
Have you tried:
MimeType=image/jpeg;image/jpg;image/png;image/jp2;image/webp;
2 Likes
hm, filetype image/jpg doesn’t exist, does it?
adding a non-existant filetype here shouldn’t work at all
the command xdg-open in fingerterm behaves correctly:
xdg-open Jolla_01.jpg opens the file via jolla-gallery without open-with-dialogue
xdg-open Jolla_01.jxl opens the file via imageSDLview without open-with-dialogue
and if I change /usr/share/applications/jolla-gallery-openfile.desktop MimeType=… this behaviour changes as it should
but when using GUI-apps (jolla-settings/transmissions or filebrowser/open) the open-with-dialogue from SFOS doesn’t change anymore no matter what value /usr/share/applications/jolla-gallery-openfile.desktop MimeType has:
png/jpeg/jp2/ … supported-jolla-gallery-images show open-with-dialogue with duplicated jolla-gallery entries
jxl/heic/avif non-supported-jolla-gallery-images show open-with-dialogue with one imageSDLview and one jolla-gallery entry
It’s possible that you have to run something like that after changing the .desktop files:
update-desktop-database $HOME/.local/share/applications/
devel-su update-desktop-database /usr/share/applications/
1 Like
yes and after running update-desktop-database the behaviour of xdg-open changes depending on MimeType value in .desktop file as expected
but GUI apps use the SFOS-open-with-dialogue that doesn’t change anymore (before I changed the desktop file the first time, there wasn’t a open-with-dialogue with jpg/png/jp2/webp files, that’s all that changed (first image) and I somehow cannot change it back - the open-with-dialogue in second image didn’t change)
Indeed the image/* on gallery has been a bit too much. Changed that to more limited set of actually supported formats.
5 Likes
On the topic of wildcard mime association, please also have a look at the AppSupport side of things which depending on which apps users have installed can be quite annoying.
1 Like
the double entries problem finally was finally solved by updating xdg packages to xdg-user-dirs-0.17+git2-1.6.2.jolla.armv7hl.rpm and xdg-utils-1.1.3+git1-1.8.2.jolla.noarch.rpm
now (SFOS4.6.0.11), it’s a bit too restrictive:
qt5-qtimageformats-plugin-jp2 | OpenRepos.net — Community Repository System adds JPEG2000 support to SFOS, so image/jp2 should be added to MimeType in .desktop file
I’m not sure i buy the argument that the gallery should pre-advertise formats that can be enabled with third-party plugins for the off chance someone installs it.
1 Like
well, I think a JPEG2000 Pic even could be displayed by the jolla-gallery/video_part out of the box because Jolla enabled libgstopenjpeg.so in gst-plugins-bad
so it is always true to state that gallery could open it
and someone who doesn’t use jpeg2000 won’t notice a change here, and people who do are able to use gallery for it again like before SFOS4.6 (putting a script inside https://openrepos.net/sites/default/files/packages/7598/qt5-qtimageformats-plugin-jp2-5.6.3git2-2.armv7hl.rpm that adds image/jp2 to jolla-gallery.desktop wouldn’t be an elegant way too)
Doesn’t seem to work for me - though said library is installed. The much better solution is to make this work and then declare it (also for inclusion in the gallery browser).
That’s not the point. Preemptively declaring mime type support on a case-by-case basis seems like wasted effort.
1 Like
hm, that’s a bug, not a feature: harbour-videoPlayer is able to open it via gstreamer
it’s not a third party plugin. It’s from qt officially and part of https://releases.sailfishos.org/sources/4.0.1.48/sailfish-4.0.1.48-oss.tar.bz2 (Jolla SFOS source: qt5-qtimageformats-5.6.3+git2)
Please report, with a proper motivation.
If i have to install a package from a third-party packager from a third-part package repository - it is third-party. Heck, i don’t even consider the argument valid if i had to install it manually from official repos. Why not just lobby Jolla for official (default) inclusion instead of this workaround?