If we're using GTK+ 2.21.8 (where gtk_dialog_set_has_separator() is
deprecated but the property is still present and defaults to TRUE), we
still need to set the property to FALSE. So instead use g_object_set()
up through GTK+ 2.90.6, after which the property itself is gone.
Unfortunately the default value for this property is TRUE (bzzt, WRONG!)
so we can't just remove the function outright until we require GTK+ 2.22.
It was deprecated in GTK+ 2.21.8.
EAttachmentHandler predates EExtension, so this is really just a code
cleanup to use the extension framework. But this also demonstrates that
extensions can target interfaces as well as instantiable types, since
EAttachmentView is an interface.
What's also nice is EAttachmentView no longer has to directly interact
with attachment handlers. Instead of EAttachmentView having to query
each attachment handler for drag-and-drop info, each handler now pushes
its own drag-and-drop info to its EAttachmentView during initialization.
Adds a boolean "dragging" property to the EAttachmentView interface,
which becomes TRUE when the user start a drag from the attachment view.
e_attachment_view_drag_motion() and e_attachment_view_drag_drop() both
return FALSE when this property is set.
Also, do not register the entire EMsgComposer window as a drag
destination. Just intercept drag signals from the GtkHTML widget.
Requires gtkhtml commit 344eb5e to fully work correctly.
e_preferences_window to take factory callbacks and store a reference
to the shell. - This makes start-up substantially faster, particularly
on Atom (eg.).
Remove a number of idle handlers used to create these UIs in the
first instance, cleaning the code.
The new height-for-width logic in GTK3 doesn't like my trick to center a
GtkExpander's label widget, so I have to disable it entirely for GTK3 or
else Evolution crashes when opening a composer window.
Bug #614049 has a GtkExpander patch that would let me do it properly.
Work around the issue of GnomeCanvasItem amending its own flags to
GtkObject::flags (which is sealed) by giving it its own flags field.
This breaks libgnomecanvas ABI and API, but I see no other way.
This commit didn't work the first time because gnome-pilot libraries
were still pulling in the system-wide libgnomecanvas, and that was
interfereing with our bundled version which has a different ABI.
But gnome-pilot integration was dropped in the previous commit, so
everything is now using the bundled libgnomecanvas.
It just doesn't belong in Evolution anymore. We don't support syncing
with more modern devices -- see Conduits or SyncEvolution for that -- so
it does not make sense for older model Palm Pilot PDAs to be the lone
exception.
I have repackaged the Evolution-Data-Server conduit modules to be
provided by gnome-pilot itself in bug #619315. This should provide
eqivalent Palm Pilot syncing functionality; it's just being moved to
gnome-pilot.
This completely severs our dependency on deprecated GNOME 2.x libraries
which were still being dragged in by way of gnome-pilot dependencies.
It was also interfereing with our bundling of libgnomecanvas.
This reverts commit fd8b55edaa.
Something in this commit seriously hosed ETable, making Evolution pretty
much unusable. Reverting this until I can track down the problem.
Work around the issue of GnomeCanvasItem amending its own flags to
GtkObject::flags (which is sealed) by giving it its own flags field.
This breaks libgnomecanvas ABI and API, but I see no other way.
Both of these modules are deprecated and going away in GNOME 3 but we
still rely heavily on them for GnomeCalendar and ETable. So, welcome
to the island of unwanted libraries...
Matthew Barnes