the point of this pr is to get an overview
how and where DC_CONTACT_ID_DEVICE is used,
to prepare introducing a device-"chat".
i did not change the sql statements for now
as this would require some more refactoring
and has the potential to introduce bugs.
This more strongly types the ubiquitous message id type by no longer
making it an integer. It keeps the actual ID opaque. Only for the
generic job API the number keeps being used. Some locations also need
to create it from an integer and call MsgId::new().
Turns out that anyone that uses these either justs wants a file or
wants a blob. Consolidate those patterns into one place and simplify
all the callers.
This creates a specific type for blobs, with well defined conversions
at the borders. It also introduces a strong type for the Param::File
value since that param is often used used by the public API to set
filenames using absolute paths, but then core changes the param to a
blob before it gets to the database.
This eliminates a few more functions with very mallable C-like
arguments behaviour which combine a number of operations in one.
Because blob filenames are stored so often in arbitrary strings this
does add more code when receiving those, until the storage is fixed.
File name sanitisation is now deletated to the sanitize-filename crate
which should do a slightly better job at this.
if the past we had lots of crashes because of unexpected unwrap failures,
mostly related to string.
this commit avoids them eg. for string-conversions that may panic
eg. when encountering a null-byte or by logical programming errors
where an object is assumed to be set but is not under unexpected circumstances.
* add sticker type
this pr adds the message type 'sticker'.
stickers are handled as normal images
but tagged with the header `Chat-Content: sticker`
it's up to the ui to render these stickers appropriate.
* cargo fmt
core-c has truncated messages in the contact requests.
this is questionable in general, as
- all messages, including contact requests,
are already truncated, unquoted, simplified etc.
- the ui should be capable of showing the full text anyway
(when the contact request is accepted, the whole messase is shown)
- also, all current ui show the contact requests by name only in the
chatlist; the user often does not even come to the contact request view.
- if the ui wants to show the contact request is a special way,
it is probably better to leave this truncation up to the ui
Function `query_row` executes query and calls callback function to process
row returned. Function query_row_col() is special case, that provides
callback function, which returns value of one particular column of row,
ignoring others.
In all cases, that particular column was 0 (first and only column of
query result), since there is no point to select more than one column
with this function -- they are discarded anyway.
This commit removes that redundancy, removing column number argument of
query_row_col() function and adjusting call sites accordingly.
Adjust call sites as apporiate:
* src/dc_imex.rs(dc_continue_key_transfer): use if-let pattern
with dc_read_file_safe() and dc_msg_get_file()
* src/message.rs(dc_msg_get_setupcodebegin): ditto
* src/message.rs(dc_get_msg_info): simplify code to print information
about file inside a message.
* src/message.rs(dc_msg_get_file): simplify function using
dc_get_abs_path_safe()
* deltachat-ffi/src/lib.rs(dc_msg_get_file): convert PathBuf to `char *`
to preserve C API
The Message struct had a reference to the context which made a few
APIs a little easier. However it has surprising consequences a long
way down the line as shown in #335: it means any object which has such
a reference needs to keep open a lock if we want to do this refactor
of no longer having a "closed" Context struct on the Rust API (which
has many benefits which will simply that Context struct and is more
the Rust way - RAII etc).
By refactoring away the context reference on the rust API as done in
here however, we push this behaviour of how these references are
handled back to the C-API pointer behaviour: that is unsafe but just
works in a C-like way. The resulting complexity in the FFI layer is
also notably less than in the #335 alternative.
As a consequence all APIs which require the context, now explicitly
need to get the context passed in as an argument. It looks like this
is certainly no downside and maybe even beneficial for further API
refactors.
For this strategy to work out the same should be done to
dc_chatlist_t, dc_chat_t and dc_contact_t. But this working for
dc_msg_t give a reasonable confidence that this is a good approach.
Previously, logging macros (info! warn! error!) accepted integer
argument (data1), that was passed to callback function verbatim. In all
call sites this argument was 0.
With this change, that data1 argument is no longer part of macro
interface, 0 is always passed to callback in internals of these macros.
