| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
EMailPart is reference-counted, subclassed, and allows a custom
finalize function. There's no excuse for it not to use GObject.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Might be the final change for this bug, the two previous commits
were not using the right approach, causing regression in rendering
of text/* parts which were not named in the list of excluded content
types for a 'raw' formatting.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Exposing data members in the public struct is unwise, especially when
EMailPartList is used from multiple threads. Instead keep the members
private and provide a set of thread-safe functions to manipulate them.
|
|
|
|
|
| |
Replace the individual components of an EMailPartList with a reference
on the EMailPartList itself in EMailFormatContext. Easier to manage.
|
|
|
|
|
|
| |
This reverts commit 7050a12868252cf6254620cd27dcb6832851040d.
Incomplete solution, renders Bugzilla mails unreadable.
|
|
|
|
|
|
|
|
| |
It's for cases when message UID contains letters which are supposed
to be encoded, like "<>" in NNTP message UIDs. Without the decode
the message preview is left empty and only console shows a runtime
critical warning:
handle_mail_request: assertion `part_list != NULL' failed
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds 'Format as' submenu to the preview pane context menu.
The submenu is available only for text/plain parts or parts
with a source code (we support about 40 various types). Using
the 'highlight' utility, the formatter processes the part and
highlights the source code it contains.
(discussion in bug #680026)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
All mail-parsing and formatting code has been moved to em-format.
Parsing is handeled by EMailParser class, formatting by EMailFormatter.
Both classes have registry which hold extensions - simple classes
that do actual parsing and formatting. Each supported mime-type
has it's own parser and formatter extension class.
|
| |
|
| |
|
|
|
|
| |
Always call it immediately after g_simple_async_result_new().
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
Make sure the EMFormat* lives until EMailRequest is finished.
|
| |
|
| |
|
|
|
|
| |
This is why I hate URIs...
|
| |
|
| |
|
| |
|
|
|