Always returning NULL (no match) from gtk_rc_get_style_by_paths()
means that looking up colors and style properties based on the
GtkStyle will give default values instead of themed values. We can
do better by returning a GtkStyle based on a GtkWidgetPath that we
figure out from the values passed in to get_style_by_paths().
https://bugzilla.gnome.org/show_bug.cgi?id=637520
We want to have different window types for different displays, so we can
write code like this:
#if GDK_WINDOWING_X11
if (GDK_IS_X11_WINDOW (window))
{
/* do x11 stuff */
}
else
#endif
#if GDK_WINDOWING_WAYLAND
if (GDK_IS_WAYLAND_WINDOW (window))
{
/* do wayland stuff */
}
else
#endif
{
/* do stuff for unsupported system */
}
This requires different GdkWindow types and we currently don't have
that, as only the GdkWindowImpl differs. With this method, every backend
defines a custom type that's just a simple subclass of GdkWindow. This
way GdkWindow behaves like all the other types (visuals, screens,
displays) and we can write code like the above.
This is for compatibility reasons. We want to change APIs that operate
on X11 objects to take the X11 objects as arguments. However, this would
break a lot of APIs and we'd like to avoid this, so we play this little
trick (we will use the same trick for the other X11 objects). Also,
gobject-introspection and other bindings can correctly attach the
functions to the correct types as it is the same scheme that GDK2 used
for pixmaps, windows and drawables.
For GTK 4, we will remove this trick, so apps should properly cast their
objects right now.
Unfortunately, I don't think there is a way to use
GDK_DISABLE_DEPRECATED or similar macros to check for proper type casts
while compiling ensure compatibility with future GDK versions. I'm free
to consider them though.
