| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
GTK's file chooser dialog provides one-click access to recently used
documents now, so we can remove the redundancy from Evolution's mail
composer main menu and calendar component editor main menu and leave
it at "Insert -> Attachment".
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Prefer thread-safe G_DEFINE_TYPE and G_DEFINE_INTERFACE macros over
manual GType registration.
This is just a start... lots more to do.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
Based on EggTreeMultiDragSource in libegg.
|
| | |
|
| | |
|
|
|
Rewrite the attachment UI to better utilize GIO and also to migrate from
GnomeIconList to GtkIconView. This also introduces a "List View" option
similar to Nautilus, as well as the EAttachmentHandler framework for
extending attachment handling (may eventually replace EMFormatHook).
This commit also fixes a number of secondary attachment bugs:
Bug 311609 – new attachment bar should use regular gtk+ expander
Bug 314923 – Drag and Drop in attachment window is inconsistent and
requires additional click
Bug 338179 – attachment saving ...
Bug 350364 – Action to get info about attachments
Bug 383047 – Viewing mail attachments
Bug 427235 – Can't copy attachment mime type string
Bug 454091 – Cannot save multiple attachments who have the same name
Bug 494629 – Rethink composer's attachment UI
Bug 553970 – Evolution ignores umask when saving attachments
Bug 577375 – mailto: and attach doesn't URL un-escape
|
