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...
The GtkhtmlEditor HTML toolbar uses some legacy stock icons:
stock_insert-rule
stock_insert-table
stock_text-monospaced
Technically these belong in the GtkHtml package. Couple reasons why I'm
not doing that.
1) Evolution should be the only consumer of GtkhtmlEditor at this point,
and when we finally dump GtkHtml for WebKit I expect the composer UI
to stay basically the same. So GtkhtmlEditor will have to be gutted,
renamed, and moved into Evolution, along with the legacy icons. So
they're going to end up here in the long run anyway.
2) GtkHtml doesn't ship any of its own icons currently, so I'd have to
reconstruct all the autotools scripts for icons already in Evolution,
figure out a sensible install path, make sure GtkIconTheme knows to
look for icons there, etc. Just not worth the hassle.
Convert the "startup-wizard" EPlugin to an EExtension, and fix up the
importing UI a bit (but it still needs a lot more love). Importing
progress is now shown directly in the GtkAssistant window.
Define a new EConfigItem type (E_CONFIG_PAGE_PROGRESS) for creating
progress pages in a GtkAssistant.
Also, change EMAccountEditor semantics slightly: you now have to call
e_config_create_window() manually after creating a new EMAccountEditor
instance. This allows extra EConfigItems (specifications for the window
content) to be added manually before the window is created.
