Created attachment 244747 [details] patch This enables HEIF in XFCE apps.
Interesting why PR didn't move to xfce@ automatically...
Hi, Thanks for pointing this out. I did not notice this was something supported. Although I have a problem adding this as an option, since there is no actual knob to enable/disable it in the port. The knob would simply add a dependency, changing nothing in the build. This is not the real idea behind dependencies and options. Also I see no reference to this library in xfce4-thumbnailer. Are we sure this dependency would not belong to some other part that tumbler depends on? On the other hand if this is something that tumbler loads at runtime of available, I'm not sure adding a dependency and an option is the correct solution in this case. Maybe adding a note in the pkg-message? The fast it is an option does not fix excess dependency, it would not help binary packages users. I'm looking into this, but adding an optional dependency for something detected at runtime does not look correct, user can simply be directed to pkg install the required part if interested.
(In reply to Anton Saietskii from comment #1) Don't know, fixing it manually.
(In reply to Guido Falsi from comment #2) libheif just adds module and thumbnailer to gdk-pixbuf, so whatever latter supports — that will automatically work in Tumbler. Actually situation is very similar to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273496 Reason for run depends: this will make it work by default without requirement for end user to do anything additionally. One will type "pkg install ristretto" (or "... thunar") and voila: it will pull deskutils/tumbler, which in turn will pull graphics/libheif, and everything will just work. Reason for depends in Tumbler and not in Ristretto: it will make HEIF available in Thunar as well. Additionally, Tumbler already depends on gdk-pixbuf, so adding one more module to latter should not do harm.
(In reply to Anton Saietskii from comment #4) As you say, if libheif interacts directly with gdk-pixbuf then the dependency should be there. It is a little different than the thunar/ristretto issue. tumbler is an XFCE component and clearly made to work with those. Here it is a library detected at runtime. I'm not sure adding a dependency on tumbler is correct. especially if the interaction is in another library. If libheif is detected at runtime by gdkpixbuf, then the dependency should really be put there.
I'm googling around. Looks like you do have a point. Give me time to do my own research.
(In reply to Guido Falsi from comment #5) Unfortunately, libheif already depends on gdk-pixbuf, so we can't make that to avoid circular dependency... Let's imagine a following situation: 1. One installs xfce4-goodies 2. They got Ristretto installed (and of course, =>tumbler=>gdk-pixbuf by depends) 3. HEIF doesn't work 'cause libheif not installed I may be wrong, but thought adding one more dependency would be a right way to fix #3 (though a better origin for doing that may exist). LMK if there will be additional questions on this issue or anything else, like Phabricator review will be required — I'll be happy to help since I actually use everything mentioned above and of course, example situation was something that I encountered.
(In reply to Anton Saietskii from comment #7) I don't want to be difficult and this bug report is enough. While you have a point about heif support, being something detected at runtime, depending on a common standard installing thumbnailer descriptions in ${LOCALBASE}/share/thumbnailers what makes heiv special to require a dependency and other foprmats, that also dynamically put thuumbnailer descriptions there? For example here I see: > ls -1 /usr/local/share/thumbnailers/ ffmpegthumbnailer.thumbnailer gdk-pixbuf-thumbnailer.thumbnailer gsf-office.thumbnailer heif.thumbnailer jxl.thumbnailer librsvg.thumbnailer heif happens to be there by chance, in my case most of these are depended upon by tumbler, due to other dependencies (not checked all of them), but looking in the ports tree there are many others. What makes heif special? Or, to put it another way, if tomorrow someone asks for another runtime dependency for a custom thumbnailer how could I not add it? we would end up with hundred of dependencies, some even heavy and unreasonable ones. With this finding I'd rather simply add a note to pkg-message stating that thumbnailers for custom formats are installed by other ports.
I mean, it's a plugin system. If one wants an extra plugin he obviously has to install it himself. It works like this in all software. We can't and should not depend on every possible plugin just in case someone needs it.
(In reply to Guido Falsi from comment #8) Just to clarify: looks like ffmpeg, gdk-pixbuf, and gsf-office are internal Tumbler thumbnailers (at least I see their configure options in Makefile). Other 3 appear to be external. Regarding HEIF specifically: I, personally, spent a few days trying to figure out how to enable HEIF. Googling indicated that I need to add heif-thumbnailer to gdk-pixbuf plugins, but searching that term in ports tree produces 0 results. Didn't even suppose libheif contains that (thought it only provides shlib), and suddenly discovered that HEIF thumbnails started to work after completely unrelated port pulled libheif. So, at least mentioning libexif in pkg-message can be considered as solution. And what's so special about HEIF (_purely_ personal thoughts, I don't insist counting following as an argument related to PR): it provides roughly 30 to 50 percent size reduction of photos compared to JPEG, so I switched all my devices with cameras already. I believe sooner or later everybody will want HEIF support by default just as everybody wanted JPEG support before (and, actually, wants now).
(In reply to Anton Saietskii from comment #10) > at least mentioning libexif s/ex/he/
(In reply to Anton Saietskii from comment #10) I'm sorry you had to do so much research on this. On the other hand dependencies are not a tool for simple convenience. As I said one thing is having a run dependency on another port that is a part of the same project and specifically created to serve that purpose and work together with some other software. In this case we are talking about unrelated software providing functionality through a common plugin system. I understand it would be convenient for you to have a direct dependency with libheif to get the plugin installed. But if I accepted this logic I should also add a dependency on multimedia/totem, graphics/mypaint or cad/freecad (or one of the few other ports already in the tree, or any new port, happening to provide a .thumnailer file). The properties of the heif file format are non consequential to this, and I cannot risk adding the dependency, forcing that on a lot of users, one of which could complain (it has happened, FreeBSD users are very conservative about dependencies usually) [1] I'll propose a new patch shortly updating pkg-message, with details about this plugin mechanism so the fact is at least documented somewhere in the project. Actual upstream documentation is already available at [2], although it does not talk specifically about heif format, which is just one in many to them, I guess. [1] I agree my question on what makes it special missed the point, which is not "what makes it good", but "what makes it so important, in relation to xfce4-tumbler, as a dependency to be necessary to force other users to install it as a dependency all of a sudden" [2] https://docs.xfce.org/xfce/tumbler/available_plugins
Created attachment 244757 [details] patch v1 Here is a patch adding an informative message about thumbnailers to pkg-message. While writing it I noticed the URL that is here is outdated, so I updated that. Please review this, if wording and grammar looks all correct to you (I'm not a native English speaker, so review is appreciated also to avoid any kind of language errors, grammar or whatever)
Created attachment 244758 [details] patch v2 Some wording changes.
(In reply to Guido Falsi from comment #13) Actually I'm non-native speaker too. Looks like just whitespace is missing in line 4 after "Plugins". Apart from that, proposed message appears to be clear enough on topic to remind me (and, likely, inform others potentially interested). Molte grazie!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=c9cb2f0d1fbd1d1c62f5a69078e763788a80bd94 commit c9cb2f0d1fbd1d1c62f5a69078e763788a80bd94 Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2023-09-11 13:34:46 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2023-09-11 13:34:46 +0000 deskutils/xfce4-tumbler: Update pkg-message - Add note about thubmnailer plugins - Update referenced URL for further information PR: 273697 Reviewed by: Anton Saietskii <vsasjason@gmail.com> MFH: 2023Q3 deskutils/xfce4-tumbler/files/pkg-message.in | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
A commit in branch 2023Q3 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=7b273897e7437dd23a42dd2383cdf4907148c174 commit 7b273897e7437dd23a42dd2383cdf4907148c174 Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2023-09-11 13:34:46 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2023-09-11 13:36:36 +0000 deskutils/xfce4-tumbler: Update pkg-message - Add note about thubmnailer plugins - Update referenced URL for further information PR: 273697 Reviewed by: Anton Saietskii <vsasjason@gmail.com> MFH: 2023Q3 (cherry picked from commit c9cb2f0d1fbd1d1c62f5a69078e763788a80bd94) deskutils/xfce4-tumbler/files/pkg-message.in | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-)
Patch committed. Thank you!