Both methods get_conversation_for_date and search_log in the logger
module are related to the loading of conversations and both return a
list of messages from the log. Therefore, it makes sense that both of
them have the same return type.
Remove the named tuple type specific to search_log and convert the
method to return tuples of type Message instead. As a side effect of
this change, search_log now also returns values from the additional_data
column in the log database.
The get_conversation_for_date method in the logger module returns a
list of bare tuples. Knowledge of how to pack and unpack the many
individual components of the tuples is split between the caller and
the callee, making the method hard to maintain and ugly to use.
Therefore, convert the method to return named tuple instead.
The get_search_results_for_query method in the logger module returns a
list of bare tuples. Knowledge of how to pack and unpack the many
indidual components of the tuples is scattered across both the callers
and the callee, making the method hard to maintain and ugly to use.
Therefore, convert the method to return named tuples instead.
Currently, there are no enumerations using the enum module which reuse
values/need aliases. Add the @unique decorator to all enum classes as a
safety net for future modifications.
Currently, the additional_data column is not correctly loaded from the
log database in the logger module's methods get_last_conversation_lines
and get_conversation_for_date. While the JSON data in the column is
parsed, the parsed value is not saved, because the code assumes that
changes to a loop variable are reflected in the list that is iterated
over. Instead, the unparsed JSON string is returned. Fix this by building
a separate list with the JSON string replaced by the parsed JSON object.
Search results in the history window to are scrolled to and highlighted
once the user clicks on one of them. Messages are searched by text in
the log database, but then looked up in the history text buffer via a
visible or invisible timestamp obtained from the database record.
Timestamps in the history text buffer, depending on user configuration,
may only have a coarse granularity. Philipp Hörist discovered that this
may lead to the highlighting of the wrong line in the history text view
and proposed an alternative solution that is implemented in this patch.
Timestamps are abolished as a means of searching messages. Instead, add
a mark with the unique message id (log line id) at the start of every
message in the history text buffer when the conversation is loaded.
After fetching the search results from the database this id can be used
to unambiguously find the corresponding message in the history text
buffer.
The method get_search_results_for_query provides a means to search via a
passed in SQL query. This feature has been unused and dead since its initial
commit back in 2005 (commit e542fff69f), so just remove it.
It now orders all messages with the given timestamp
this also includes inserting messages at the correct
point
The timestamp precision for incoming and outgoing messages
was raised to include fractions of a second
Also added new property 'additional_data' to message event objects. Changes to this attribute (a dict) are passed on from event to event and are also written to the history db as json string (reading of those values isn't implemented yet).
André Apitzsch
Philipp Hörist
Markus Böhme
Emmanuel Gil Peyrot
tmolitor
Yann Leboulanger
Denis Fomin