7 Commits

Author SHA1 Message Date
Enrico Tröger
9d412702e8 Make the compat_widget_set_flag macro more robust 2013-03-19 14:43:12 +01:00
Enrico Tröger
d9c7f59b41 Improve GTK compatibility macros for GTK 2.16
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.
2013-03-19 14:17:25 +01:00
Colomban Wendling
3e649dddef Prevent most GTK3 deprecation warnings that can't be fixed on GTK2
Map the various horizontal and vertical deprecated constructors
to their GtkOrientation-based equivalents on GTK3 to prevent most
deprecation warnings.
2012-10-08 20:08:07 +02:00
Colomban Wendling
6409840d4a Get rid of GtkComboBoxEntry API and use GtkComboBoxText API
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.
2012-10-08 20:08:06 +02:00
Colomban Wendling
5ec0eb477d Guard removed dialog separators on GTK3
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.
2012-10-08 20:08:06 +02:00
Colomban Wendling
c54639c0e1 Include keysyms compatibility header on GTK3 2012-10-08 20:08:06 +02:00
Colomban Wendling
a763e307f7 Don't access GtkWidget fields directly
Since many accessor are new in GTK versions we don't depend on, add
a header that defines them to the direct access if they aren't
available.
2012-10-08 20:08:06 +02:00