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.
Evolution's Google account module was setting the ECollectionSource's
"identity" property to the account's email address before submitting the
account to E-D-S. Meanwhile, the Google module in E-D-S was syncing the
account user name to the ECollectionSource's "identity" property.
This mismatch resulted in an explicitly specified GMail user name being
overwritten when the account information is submitted. Evolution should
instead set the "identity" property to the account's user name.
EMailConfigWebView is an extension that configures EWebView instances.
This used to cover both the email formatter and the email composer, but
with the email formatter now using WebKit/GTK+ and the email composer
still using GtkHtml, the composer was left unconfigured.
Add an EMailConfigWebViewGtkHTML extension that targets EWebViewGtkHTML
instances and applies the relevant settings, and remove all the GtkHTML
contortions from EMailConfigWebView.
Word-wrapped GtkLabels and GtkTables just don't seem to get along.
The vertical allocation for the GtkLabel was way too big. Replace
the GtkTable with a GtkGrid.
EMailConfigFormatHTML listens for "changed" signals from a GSettings
instance, passing itself as the 'user_data' to the signal handler. But
the signal handler was left connected after EMailConfigFormatHTML was
finalized, resulting in the signal handler receiving a dangling pointer.
Not using g_signal_connect_object() here because of the unresolved
reference leak issue in GObject. The GSettings instance is likely
cached internally and lives well beyond the EMailConfigFormatHTML.
