I got a testing flatpak working in preparation for the 5.2.0 release, but the media previews don’t work. However, if I right-click an image in the Gallery tab of the person editor and select Edit, then the image appears correctly in the top Preview (but not in the Preview for Shared Information). Attached is a screenshot of a jpg.
The 5.1.6 flatpak displays media as expected. The change in this flatpak is the 5.2.0-beta1, the use of pip in the flatpak manifest to build Gramps, and an updated GraphViz dependency. So before I start more troubleshooting on the flatpak, has anyone else noticed the 5.2.0 beta1 (regardless of installation method) having trouble with the display of media files?
1 Like
At first blush, the bad images all seem to be small thumbnails while the larger is ok.
Are any small thumbnails showing instead of those generic document placeholders?
If it IS the small thumbnails, that opens a lot of possibilities… from file paths to changes in the thumbnail generation.
Thank you for the idea. No thumbnails work from what I saw in the 5.2.0-beta1 flatpak. The only way to make a jpg show is the method I mentioned in the first post, which apparently is the full size picture? So I guess that is the explanation for what is happening, that thumbnail generation is not working in the flatpak. Does the thumbnail problem happen for other 5.2.0-beta1 installations too?
I have a couple things to change back if this is flatpak specific (revert to home directory access instead of using xdg-utils, or revert to setup.py instead of pip). I wanted to know if this is flatpak specific or upstream Gramps because it is time consuming to troubleshoot flatpak problems due to the length of time it takes to compile each flatpak run on GitHub.
Thumbnails work for me using Arch Linux.
Thank you, I am doing a test compile at my GitHub to revert to home directory access now.
I noticed that Gnome Platform 44 from flathub has rsvg-convert 2.56.2. Would another svg library potentially need to be added perhaps?
We try to use the Gnome thumbnailers.
My earlier response was when I was out and away from the computer.
I just tried and had a weirdness where the example.gramps tree’s small thumbnail worked but the large did not. Using Media Verify to reset the paths (they were in a different location than the Examples.gramps specified after installing the beta) worked but it looked like a bad path persisted. Had to change people to force a refresh.
So … not the same but still weird.
Fedora 37 on Gnome 43.7 and Wayland windowing
GRAMPS: 5.2.0-beta2-da027eb63
Python: 3.11.4 (main, Jun 7 2023, 00:00:00) [GC…
BSDDB: 6.2.9 (5, 3, 28)
sqlite: 3.40.0 (2.6.0)
LANG: en_US.UTF-8
OS: Linux
Distribution: 6.4.7-100.fc37.x86_64
This issue is resolved in the 5.2.0-rc1 flatpak. I tested both Mate and Gnome Debian 12 desktops to make sure the thumbnail previews work now. Thank you.
1 Like
Where’s the Flatpak available? It isn’t listed in the RC1 Assets.
Short answer: I test them on my github fork before pushing to GitHub - gramps-project/flatpak: Manifest and data files required to make a Gramps Flatpak for at least a week’s review before submission to flathub. Here is a working test run from today at my fork of the Gramps flatpak, but I don’t know if other users can access the archive. gexiv2: use build options env from Shotwell flatpak · OzarkShepherd/flatpak@55f84db · GitHub
Explanation: An automated compiling at release of a flatpak with as many dependencies as Gramps is almost guaranteed to break the flatpak. I have to manually update and then troubleshoot the flatpak manifest separately after a Gramps release, due to the nature of flathub. I can not remember a Gramps release ever just working with problems when added to a flatpak manifest. Flathub takes submitted manifests at their github and compiles the flatpaks itself, for security reasons. However, every year upstream dependencies, as well as runtimes for flatpaks themselves, change. For example, just a url change at a single upstream dependency will cause the flatpak compiling to fail, or if I use a non-versioned dependency that is regularly maintained, then a single revision will alter the expected sha256 hash and cause the entire flatpak compiling to immediately halt and fail. Then all the changes need to be resolved and tested before submitting an updated manifest to flathub.
I have thought of setting up a manual workflow to put out a release available at the gramps-project/flatpak github based on Nick’s request at Create a Flatpak when a release is published · Issue #6 · gramps-project/flatpak · GitHub If it is manually run to upload an artifact after all the flatpak related bugs are worked out, then it should be reliable enough to make available to users. However, the user will still need to install flatpak itself from their own distro, and then (for most distros) manually set up the flathub repository for the required runtimes (especially Gnome Runtime) anyway. Due to my own lack of training, the research (and trial and error) required for me to get the github workflow to work that way will be very time consuming with hardly any little benefit. I say it is little benefit because once flathub removes old Runtimes from being available to download, the older flatpak versions will not work anyway. So making archives available of old Gramps flatpaks on the gramps-project github won’t even work unless the user can find old runtimes from less reputable sites than flathub, and then has the knowledge to install the deprecated runtimes into the right directory for the flatpak to use them.
1 Like
