[MacPorts] #54962: adwaita-icon-theme 3.26.0 +quartz: Fails to install because gtk-encode-symbolic-svg cannot identify svg file type (gdk-pixbuf2 / glib2 problem)

[MacPorts]

#54962: adwaita-icon-theme 3.26.0 +quartz: Fails to install because gtk-encode-
symbolic-svg cannot identify svg file type (gdk-pixbuf2 / glib2 problem)
-------------------------+-------------------------------------------------
 Reporter:  fredowski    |      Owner:
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.4.1
 Keywords:               |       Port:  adwaita-icon-theme glib2 gtk3 gdk-
                         |  pixbuf2
-------------------------+-------------------------------------------------
 Hi,

 i noticed a fundamental problem under quartz variant with gdk-pixbuf2 and
 glib2 when trying to install adwaita-icon-theme. adwaita-icon-theme fails
 to install because gtk-encode-symbolic-svg from the gtk3 package is
 called. This tool reads svg files to produces the png files in different
 sizes. To reproduce the problem in a simple manner, you can just call

 {{{
 gtk-encode-symbolic-svg <some-svg-file> 32x32
 }}}

 which will yield an error message that the file type is unknown. I traced
 down the problem which is specific to the quartz variant to quartz
 specific changes in the gio library. gtk-encode-symbolic-svg calls
 gdk_pixbuf_new_from_stream such that gdk-pixbuf needs to identify the file
 type from the file content. This results in calling
 _gdk_pixbuf_get_module:

 https://github.com/GNOME/gdk-
 pixbuf/blob/09ddf12378f34179c3e5c0e8db869f975a8ea139/gdk-pixbuf/gdk-
 pixbuf-io.c#L864

 There the function g_content_type_guess is called which will be taken from
 gosxcontenttype.c for the quartz build. See:

 https://github.com/GNOME/glib/blob/d4a21e001a118c904ec6b57aee2838eb67e34311/gio/gosxcontenttype.c#L361

 versus the X11/Unix version based on xdgmime support:

 https://github.com/GNOME/glib/blob/d4a21e001a118c904ec6b57aee2838eb67e34311/gio/gcontenttype.c#L686

 Without a file name this more or less reduces to choosing "public.text"
 type for data only guessing. I guess this is a fundamental difference to
 the x11 build where the xdg system is used to identify the content type. I
 did some short research without finding a MacOS equivalent to identify the
 content type from pure data as it is done in this application. From my
 perspective the way to go would be

 a) More or less code the whole xdg mime functionality again to have the
 possibility to figure out the content type from analyzing the content.

 b) Include xdgmime also in the Quartz version. This would require some
 changes in the gio library. This leaves the mime to uti conversion but at
 least there seems to be some MacOS support for this:

 https://developer.apple.com/documentation/coreservices/1448939-uttypecreatepreferredidentifierf

 Is there any specific reason not to use the xdg functionality in the
 Quartz build?

--
Ticket URL: <https://trac.macports.org/ticket/54962>
MacPorts <https://www.macports.org/>
Ports system for macOS