* Always define GEANY_FOO_H to 1 in the header guards
* Always put a G_BEGIN_DECLS/G_END_DECLS guard in every header for
consistency, even private ones where it doesn't matter.
* Always include either <glib.h>, <gtk/gtk.h> or some other header
that will provide G_BEGIN_DECLS before using it. In a lot of headers
that use glib.h and gtk/gtk.h stuff anyway, this resolves an implicit
dependency they had on them being included before that header.
* Always put a comment at the #endif part of the guard so it's
easier to see what it applies to.
* Always use an underscore between the header guard identifier's words
even though the filename doesn't have one.
On GTK 2.16 GTK_WIDGET_[UN]SET_FLAGS resolves to a do-while construct which
raises a syntax error when embedded into a ? operator.
Also gtk_widget_get_visible() is only available since GTK 2.18, so add a fallback to
the old variant.
Map the various horizontal and vertical deprecated constructors
to their GtkOrientation-based equivalents on GTK3 to prevent most
deprecation warnings.
Use the GtkComboBoxText API and the GtkComboBoxEntry replacement API
and map those to the old equivalents if not available.
This changes the type exposed by ui_combo_box_add_to_history() from
GtkComboBoxEntry to either GtkComboBox (under GTK2) or GtkComboBoxText
(under GTK3). This should not be too much of an issue since
GtkComboBoxEntry and GtkComboBoxtext are subclasses of GtkComboBox,
but this will still emit warnings when when the calling code passes
a GtkComboBoxEntry pointer to ui_combo_box_add_to_history().
However, this requires the calling code to use the same mapping as we
do (GtkComboBoxText = GtkComboBox on GTK2, even on 2.24), or things
will blow and it'll be hard to understand why. This wouldn't be an
issue if the calling code includes our gtkcompat.h header everywhere
it deals with combo boxes, which will be the case if it includes the
Geany headers everywhere but probably won't otherwise. Oh dear.
A possible kind of workaround may be for ui_combo_box_add_to_history()
to do type-checking on its argument and use the actually correct API
for that type.
GtkDialog separators sere deprecated on GTK 2.22 and remove on 3.0,
so define them to dummy values on GTK3.
We don't get rid of them altogether because GTK 2.16 we depend on
probably has separators enabled by default and we want to remove them.
