| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also add an evolution-mail-composer documentation module.
|
| |
|
|
|
|
| |
To make Evolution's shared libraries more consistent.
Also rename the documentation module to evolution-util.
|
| |
|
|
|
|
|
|
|
|
| |
This dialog is all kinds of lame, not to mention ugly. It tends to pop
up when evolution-alarm-notify starts and often steals input focus from
the normal reminder dialog that pops up overtop of it.
Let's not apologize for features not implemented. Instead of alerting
the user that we'll show a normal reminder dialog in lieu of sending an
email reminder, just show a normal reminder dialog.
|
| | |
|
| |
|
|
| |
Instead of e_client_utils_open_new() or e_cal_client_new().
|
| |
|
|
|
| |
For compliance with:
https://live.gnome.org/GnomeGoals/NotificationSource
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Move the supporting widgets for the contact maps feature alongside
EABContactDisplay. Removing them from libeutil helps isolate our usage
of libchamplain so it's not imposed on the entire application, and even
3rd party software. That libchamplain is an optional dependency only
further complicates the matter.
Ideally I'd like to somehow isolate this feature in an extension module,
but we currently lack sufficient hooks for such an extension. So this
arrangement will have to suffice for now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Evolution consists of entirely too many small utility libraries, which
increases linking and loading time, places a burden on higher layers of
the application (e.g. modules) which has to remember to link to all the
small in-tree utility libraries, and makes it difficult to generate API
documentation for these utility libraries in one Gtk-Doc module.
Merge the following utility libraries under the umbrella of libeutil,
and enforce a single-include policy on libeutil so we can reorganize
the files as desired without disrupting its pseudo-public API.
libemail-utils/libemail-utils.la
libevolution-utils/libevolution-utils.la
filter/libfilter.la
widgets/e-timezone-dialog/libetimezonedialog.la
widgets/menus/libmenus.la
widgets/misc/libemiscwidgets.la
widgets/table/libetable.la
widgets/text/libetext.la
This also merges libedataserverui from the Evolution-Data-Server module,
since Evolution is its only consumer nowadays, and I'd like to make some
improvements to those APIs without concern for backward-compatibility.
And finally, start a Gtk-Doc module for libeutil. It's going to be a
project just getting all the symbols _listed_ much less _documented_.
But the skeletal structure is in place and I'm off to a good start.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thus they persist between alarm notify process runs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
GNOME has included libnotify 0.7.x since GNOME 3.0. It's still an
optional dependency for Evolution, but if you're gonna use it you'll
need a GNOME3-era release.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Replace 8-space indentation with tab characters, and various other
automated cleanups.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
