1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
//! Which formats *this build* can decode.
//!
//! Asked of `image` rather than kept as a list here, because the answer
//! is decided by cargo features in the workspace root and a second list
//! would be a second opinion — right until someone switched a feature on
//! and forgot this file.
//!
//! What it is for: a viewer needs to know whether a file is worth opening
//! before it opens it (for the filmstrip, which meets a folder of mixed
//! things), and the `.desktop` file must claim exactly the MIME types the
//! binary can actually open. A `.desktop` that claims `image/webp` while
//! the decoder is absent is a file association that opens a window and
//! shows an error.
//!
//! # The trap in `reading_enabled`
//!
//! `image`'s own `ImageFormat::reading_enabled()` answers `cfg!(feature =
//! "avif")` for AVIF — but that feature is the *encoder* (ravif).
//! Decoding AVIF needs `avif-native` and the system libdav1d. So if
//! anyone ever enables `avif` to write one, this module would start
//! claiming AVIF is readable and the viewer would advertise a MIME type
//! it cannot open. [`decodable_formats`] filters that case out by hand,
//! and `tests::avif_is_never_reported_as_decodable` fails if the
//! situation changes.
use Path;
/// Every format this build can actually decode.
/// Every MIME type this build can decode, sorted, for the `.desktop`
/// file's `MimeType=` line and for matching against a shared-MIME lookup.
/// Whether this path *looks* like a picture this build can open.
///
/// By extension, and deliberately: this is asked once per entry while
/// building a filmstrip for a folder, and opening every file in a
/// directory to read a magic number turns listing it into as many opens
/// as there are files — the same reasoning
/// `hyprforge_listing::types::EntryKind::classify` gives for classifying
/// by name.
///
/// So it can be wrong, in one direction that matters: a file this says
/// yes to may still fail to decode, and the caller has to be ready for
/// that. It is never the *only* check.