The old code did mimetype checks everywhere when type compatibility has
since been moved to the GtkDropTarget::accept signal.
So the code can now just assume a compatible mime type exists.
It doesn't really make sense to treat double clicks here different than
single clicks (and is bad UX), and it also breaks switching months by
quickly trying to single-click the last/first days in the calendar.
This is an unused feature that's way too complicated for a default
calendar widget and complicates the implementation a lot. Since we want
to eventually replace this with actual widgets, remove the details
support now.
These now render the paintable to a cairo surface and convert that
to a texture. This is sort of a hack, but its only used in two
special cases internally and in two hacky test apps.
If icon lookup fails or if loading it fails later, just always
fall back to the built in image-missing icon. Nobody is handling
missing icons in a sane way anyway.
If you *truly* need to handle missing icons, you need to manually
use gtk_icon_theme_has_icon().
While changing the loading code I also fixed an issue where it
was always passing "png" to pixbuf, now it also handles "xpm" if
that is the filename suffix.
Instead, rely on people passing fallbacks explicitly.
Alternatively, GThemedIcon provides the functionality to create
fallbacks, which is what GtkImage and the testsuite now use.
That method is slightly better, too, so the expected test results
have been updated accordingly.
There is no way to query contexts or do anything useful with them.
So don't keep track of them and don't make them an argument in public
APIs with the docs saying "I don't know what to use here, maybe read
some spec somewhere".
Those functions are unused and the documentation says "Returns some
random number that the icon theme creator chose" which does not seem at
all useful and an implementation detail.
So get rid of it.
Most users were just forgetting to set the proper flags.
And flags aren't the right way to set this anyway, it was just
acceptable as a workaround during GTK3 to not break API.
The API encouraged wrong usage - most of the users were indeed wrong.
Use the correct version instead:
gtk_icon_theme_get_for_display (gtk_widget_get_display ())
We only have implementations of this on X11 and Win32,
so make it available as backend api there.
Update all callers to use either the backend api, or
just monitor 0.
