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.
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.
camel_stream_printf() is next on the chopping block.
Use g_strdup_printf() or a GString to construct a formatted string in
memory, pass it to camel_stream_write() in one go, and then check for
errors (unless it's a memory stream).
EMFormatHTML now holds a sealed EWebView instead of a public GtkHTML,
accessible through em_format_html_get_web_view().
Rename e_mail_reader_get_html_display() to e_mail_reader_get_formatter()
and have it return an EMFormatHTML instead of an EMFormatHTMLDisplay,
since that's usually the type you want (or else an EMFormat, but never
an EMFormatHTMLDisplay).
Marks them as "system plugins" so they're not shown in Plugin Manager.
This is a temporary fix until I can rework EMFormat to use GTypeModule
extensions instead of EPlugins.
