mirror of https://github.com/GNOME/gimp.git
231ca0c505
This is not the main reason for the specific output in #9994. These ones are more probably because of similar usage in GTK (which updated its own calls to g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely also update the various calls we have to use the generic g_file_info_get_attribute_*() variants. To be fair, it is unclear to me when we can be sure that an attribute is set. For instance, when we call g_file_enumerate_children() or g_file_query_info() with specific attributes, docs say that it is still possible for these attributes to not be set. So I assume it means we should never use direct accessor functions. The only exception is that I didn't remove usage of g_file_info_get_name(), since its docs says: > * Gets a display name for a file. This is guaranteed to always be set. Even though it also says just after: > * It is an error to call this if the #GFileInfo does not contain > * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME. Which is very contradictory. But assuming that this error warning was over-zealous documentation, I kept the direct accessors since they are supposed to be slightly more optimized (still according to in-code documentation) so let's priorize them when we know they are set for sure. |
||
|---|---|---|
| .. | ||
| Makefile.gi | ||
| gimpadaptivesupersample.c | ||
| gimpadaptivesupersample.h | ||
| gimpbilinear.c | ||
| gimpbilinear.h | ||
| gimpcairo.c | ||
| gimpcairo.h | ||
| gimpcmyk.c | ||
| gimpcmyk.h | ||
| gimpcolor.def | ||
| gimpcolor.h | ||
| gimpcolormanaged.c | ||
| gimpcolormanaged.h | ||
| gimpcolorprofile.c | ||
| gimpcolorprofile.h | ||
| gimpcolorspace.c | ||
| gimpcolorspace.h | ||
| gimpcolortransform.c | ||
| gimpcolortransform.h | ||
| gimpcolortypes.h | ||
| gimphsl.c | ||
| gimphsl.h | ||
| gimphsv.c | ||
| gimphsv.h | ||
| gimppixbuf.c | ||
| gimppixbuf.h | ||
| gimprgb-parse.c | ||
| gimprgb.c | ||
| gimprgb.h | ||
| meson.build | ||
| test-color-parser.c | ||