This splits the giant EMailRequest to individual EFileRequest, EStockRequest, EHTTPRequest and EMailRequest,
making the first two available globally from e-utils, the othe two are loaded only with mailer,
since no other component uses them.
These libraries are bound for E-D-S so they live at the lowest layer of
Evolution for now -- even libeutil can link to them (but please don't).
This is the first step toward moving mail handing to a D-Bus service.
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.
The EModule, EExtensible and EExtension classes as well as the
e_type_traverse() function have been moved to Evolution-Data-Server's
libebackend library to replace e-data-server-module.c.
Now Evolution-Data-Server modules use the same framework as Evolution.
Don't use pattern rules like %-enumtypes.h anymore because it matches
installed header files like camel-enumtypes.h, so you get very strange
things happening during the build like:
.../camel/camel-enumtypes.h: e-util-enums.h
glib-mkenums ... $^ > $@
when e-util-enums.h has a newer timestamp than camel-enumtypes.h.
Instead, we'll use another variable name -- glib_enum_output -- to
replace the %-enumtypes pattern rules like so:
$(glib_enum_output).h: $(glib_enum_headers)
glib-mkenums ... $^ > $@
$(glib_enum_output).c: $(glib_enum_headers)
glib-mkenums ... $^ > $@
Also use $(AM_V_GEN) to get cleaner looking output while building.
This plugin was for developers, but no one uses it anymore. Plus the
only profiling hooks left in Evolution were in the MessageList widget,
which performs fine. There's better ways to collect profiling data
these days anyway (sysprof, systemtap, etc.).
With unintrusive error dialogs gone, we can cut some unnecessary bits
out of EActivity.
I'm also adding a new enum property called "state", which is one of:
E_ACTIVITY_RUNNING
E_ACTIVITY_WAITING
E_ACTIVITY_CANCELLED
E_ACTIVITY_COMPLETED
The state of an activity must be explicitly changed. In particular,
when the user cancels an activity the state should be set only after
confirming the operation has been cancelled and not when cancellation
is requested (e.g. after receiving a G_IO_ERROR_CANCELLED, not when
the GCancellable emits "cancelled"). EActivityBar and EActivityProxy
widgets have been updated to make this distinction clearer in the UI.
E_ACTIVITY_WAITING will be used when activities have to be queued and
dispatched in sequence, which I haven't written yet.
This marks the end of unintrusive error dialogs, which were too
unintrusive. We now show errors directly in the main window using
the EAlert / EAlertSink framework.
Trying out a new interface called EAlertSink. The idea is to centralize
how errors are shown to the user. A GtkWindow subclass would implement
the EAlertSink interface, which consists of a single method:
void (*submit_alert) (EAlertSink *alert_sink, EAlert *alert);
The subclass has complete control over what to do with the EAlert,
although I imagine we'll wind up implementing various alert-handling
policies as standalone widgets such as EAlertDialog. I'd like to try
an EAlertInfoBar.
Code that would otherwise display an error dialog itself would instead
pass the EAlert to an appropriate EAlertSink and be done with it.
Nothing is final yet. Still hacking on EAlert trying to find an API
that feels right for these use cases.
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.
There's too much ancient, crufty code there that we can't realistically
support anymore. A workaround for those poor users still on 1.x is to
upgrade to some 2.x release first, then upgrade again to 3.x. An error
dialog explaining this will be shown at startup.
This introduces a simple means of extending Evolution objects.
Any GObject subclass wishing to be extensible need only call
g_type_add_interface_static (type, E_TYPE_EXTENSIBLE, NULL);
when registering its GType, and then at some point during initialization
call e_extensible_load_extensions() to load extensions for that subclass.
Extensions are implemented by subclassing EExtension, setting the GType
being extended in EExtensionClass, and making sure its own GType gets
registered at startup. This usually done while loading a GTypeModule.
e_extension_get_extensible() provides extensions access to the object
being extended.
Replace the EVO_EXPRESS environment variable with an --express command
line option. (Note, this adds a new translatable string for --help.)
Add an EUIManager class with an "express-mode" property and custom load
functions that use our new "express" preprocessor. This replaces the UI
manager functions in e-utils.c.
(Also going to see if I can get GTK+ to add an "add_ui_from_string"
method to GtkUIManagerClass that we can override. Then we could just
call gtk_ui_manager_add_ui_from_string() and the preprocessor would
automatically do its thing and chain up.)
Add an "express-mode" read-only GObject property to EShell.
Add e_shell_configure_ui_manager() to e-shell-utils.c. For now this
just creates a one-way property binding:
EShell:express-mode -> EUIManager:express-mode
Call this immediately after e_ui_manager_new(). (EUIManager can't do
this itself because it lives too low in the dependency hierarchy and
doesn't know about EShell.)
The EError mechanism is used both for error dialogs as well as basic alerts or
user prompts, so we should give it a more general name which matches this use.
This patch also cleans up a few includes of e-alert.h (formerly e-error.h) that
were not actually being used.
https://bugzilla.gnome.org/show_bug.cgi?id=602963
Rename e-fsutils to e-file-utils. This is where we'll add asynchronous
functions for common file I/O operations with EActivity integration.
Start with e_file_replace_contents_async() (and corresponding finish()
function). This is a simple wrapper for g_file_replace_contents_async()
which also returns an EActivity. It replaces e_write_file_uri().
Also redesign EIOActivity to -contain- a GAsyncResult rather than
implement the interface for itself. This is easier for now but I may
change my mind again when I figure out how to tie centralized error
reporting into the EActivity framework.
EIOActivity implements the GAsyncResult interface, and the idea is to
use this instead of GSimpleAsyncResult. In addition to the features
offered by EActivity, it also contains GAsyncReadyCallback information
and a GCancellable.
- Calling e_activity_cancel() triggers the GCancellable.
- Calling e_activity_complete() triggers the GAsyncReadyCallback.
Functions that follow GIO's asynchronous pattern should return an
EIOActivity (cast as an EActivity) instead of 'void', so it can be
handed to an EShellBackend or whatever else dispatches activities.
This is not yet feature-complete. It's missing API for storing result
values and GErrors. I don't have a complete picture of the final API in
my head yet, so I'll copy things over from GSimpleAsyncResult as needed.
Wrote a new widget (ECharsetComboBox) to replace e-charset-picker.c.
The widget provides a "charset" string property that allows us to bind
to GConf keys (via EShellSettings). Moved e_charset_add_radio_actions()
to e-util/e-charset.c. Updated Glade files, #include lines, etc.
