Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
This is quite gross, but it looks like the whole content-type code on
Windows is similar. Pass test_subtype.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
gio/gcontenttype-win32.c: In function 'get_registry_classes_key':
gio/gcontenttype-win32.c:66:78: warning: comparison of integer expressions of different signedness: 'DWORD' {aka 'long unsigned int'} and 'int'
if (ExpandEnvironmentStringsW (wc_temp, wc_temp_expanded, len) == len)
^~
These are here to prevent linker errors, since `gcontenttype.[ch]`
aren’t compiled on Windows or macOS.
The implementations are stubs to be filled out by someone who knows each
platform, at some point in the future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1791
This is a hack for GLocalFileInfo to correctly get icons for directories.
Without this change content type for any W32 directory is NULL
(because there's no registry entry for "inode/directory" by default,
and in any way there's no file extension that means "directory" to put there),
and GLocalFileInfo uses content type to grab icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748727
The code here was returning gtk-directory and similar names as
fallback, with a comment claiming that these are 'builtin gtk'.
But they aren't, anymore, so just return the standard names.
