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.
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.
Defaults" dialogue and use quoted string instead of short path, since
this is how the "Hotmail" e-mail provider is doing it (unlike what
documentation says)
Defaults" dialogue and use quoted string instead of short path, since
this is how the "Hotmail" e-mail provider is doing it (unlike what
documentation says)
Exclude print settings that should not persist. This topic has a lot of
grey areas and GTK+ offers no help, so we'll do this by popular demand.
For starters, I'm excluding settings that have messed -me- up in the past:
GTK_PRINT_SETTINGS_N_COPIES
GTK_PRINT_SETTINGS_PAGE_RANGES
GTK_PRINT_SETTINGS_PAGE_SET
GTK_PRINT_SETTINGS_PRINT_PAGES
Exclude print settings that should not persist. This topic has a lot of
grey areas and GTK+ offers no help, so we'll do this by popular demand.
For starters, I'm excluding settings that have messed -me- up in the past:
GTK_PRINT_SETTINGS_N_COPIES
GTK_PRINT_SETTINGS_PAGE_RANGES
GTK_PRINT_SETTINGS_PAGE_SET
GTK_PRINT_SETTINGS_PRINT_PAGES
The EConfig code that creates widgets based on .eplug descriptions will
already hide sections that end up containing no child widgets.
Here we also make that code hide sections that end up containing
only invisible child widgets. We will use this from the actual
plugins, so that if they decide not to show any widgets in Express
mode, then the corresponding configuration sections will not
show up in the preferences dialog.
EConfig types 'section' and 'section-table' have an internal factory function,
which doesn't return the actual GtkFrame that they create. Instead, they return
a GtkContainer which is the actual vbox or table used to insert child widgets.
Here we modify the internal factory function to also return the actual GtkFrame
that it creates, so that the calling code can hide *that* frame properly.
Signed-off-by: Federico Mena Quintero <federico@novell.com>
Still remaining:
GtkAccessible::widget
GtkAssistant::forward
GtkAssistant::back
GtkObject::flags
GtkTreeStore::stamp
The GtkAssistant fields are related to bug #596428. We don't
need accessor functions so much as the enhancement described
there implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=615613
Note that express2 got some documentation for EExtensible and friends,
and that documentation is not in gnome-2-30 yet. We need to cherry-pick
those commits into gnome-2-30 and elsewhere.
