Use gdk_device_grab() and gdk_device_ungrab() instead.
In some cases this requires stashing the grabbed device so it can be
ungrabbed outside of an GdkEvent handler.
Prefer dealing with GdkEvent pointers and using accessor functions like
gdk_event_get_button().
This is complicated by the fact that some GtkWidget method declarations
still use GdkEventButton pointers, and synthesizing button events pretty
much requires direct GdkEventButton access. But GDK seems to be nudging
itself toward sealing the GdkEvent union. Likely to happen in GDK4.
Mainly clean up signal handlers and leave method overrides alone for now.
table-header: use gtk_widget_create_pango_context() for header buttons
Since we temporarily set custom style classes for the header button on
the table's style context, we cannot rely on the PangoContext used by
gtk_widget_create_pango_layout(), since the font values it will use are
cached by GtkWidget.
By creating a new PangoContext and using that to create our Pango
layout, the text we render will correctly support the properties
specified by the theme (such as bold column-header buttons as specified
by Adwaita).
These libraries are bound for E-D-S so they live at the lowest layer of
Evolution for now -- even libeutil can link to them (but please don't).
This is the first step toward moving mail handing to a D-Bus service.
We have a confusing array of nearly-identical CFLAGS/LIBS definitions in
configure.ac. Time to simplify. Instead let's just have one definition
that includes all the libraries provided by Evolution-Data-Server (incl.
Camel). That, in combination with GNOME_PLATFORM, gives us most of what
we need for compliation and linking, and we can sprinkle definitions for
additional library dependencies in Makefile.am's as needed.
The code in ETable that draws the button headers is outdated, and uses
deprecated gtk_paint_* functions mixed with cairo.
Port the code to use the GtkStyleContext API, which allows themes to
give the header the same appearance of a regular GtkTreeView header.
