W32 GContentType support is inadequate
@ruslanizhb
Submitted by LRN Link to original bug (#735696)
Description
For two reasons:
- content type on W32 is ".ext" (file extension), not MIME/type. As such, MIME/type matching and subclassig can't be applied to it.
- implementation relies only on the information found in Windows registry. That information is optional in many cases, which means that the implementation is often incapable of making the deductions that the clients are expecting of it.
My solution is to keep using file extensions for content types (for backward compatibility with existing glib W32 code; i would have preferred to ditch them completely, but that seems very unlikely), but convert them to MIME/types under the hood, then re-use the same xdgmime-based gcontenttype implementation that the other OSes use (with some extra W32 wrapping to fall back to reading the Windows registry in case xdgmime does not deliver; also, with some W32-only heuristics).
That requires xdgmime to be ported to W32, which turned out to be easy enough (as long as xdgmime is allowed to link to glib, which is not a problem by itself, although it does make it more difficult to sync xdgmime with upstream).