-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: improve docstrings #6496
docs: improve docstrings #6496
Conversation
Follow-up to #6072.
Replicate the docstrings from `src/events/payload.rs`.
80f6383
to
c82fcfb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay for better documentation!
I have some comments, but I approved already because it's nothing big, so if you think you adequately addressed them you are free to directly merge. Otherwise, I'll look at it again.
In general, it's good to request somebody's review on core PRs so that they don't get forgotten; if in doubt, @link2xt and me is always good, and also GitHub usually suggests some reviewers.
IncomingMsg { | ||
/// ID of the chat where the message is assigned. | ||
chat_id: u32, | ||
|
||
/// ID of the message. | ||
msg_id: u32, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about these two new comments, at least when I am reading the code they don't add any new information. Like, when i see a field chat_id
, then it's clear to me that this is the ID of the chat where something is happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought so as well, but I kept it because they're in payload.rs
, I wanted them to be in sync.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No let's keep it as-is to keep things in sync, I'll do a follow-up PR.
/// ID of the chat which the message belongs to. | ||
chat_id: u32, | ||
|
||
/// ID of the message that was successfully sent. | ||
msg_id: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, at least to me these comments don't add any new information. Same for the comments below.
MsgDeleted { chat_id: u32, msg_id: u32 }, | ||
MsgDeleted { | ||
/// ID of the chat where the message was prior to deletion. | ||
/// Never 0 or trash chat. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trash chat is just an internal implementation detail of core, to the UIs a trashed message doesn't exist, so I don't think it's not necessary to mention it here.
Also, mentioning here that the chat_id is never 0 sounds like the other similar events (MsgRead
etc.) sometimes are sometimes emitted with chat_id=0 or msg_id=0?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are sometimes emitted with chat_id=0 or msg_id=0?
Judging from DC Desktop code, this can be the case for at least ReactionsChanged
and MsgsChanged
. See the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, at least MsgsChanged
does sometimes have chat_id=0 also in practice. But the events around a message state change (MsgRead
, MsgFailed
, MsgDelivered
, MsgsNoticed
) do not IIRC.
But anyways, as you said, you just copied it, I'll make a follow-up PR that fixes these things in both locations.
#[serde(rename_all = "camelCase")] | ||
LocationChanged { contact_id: Option<u32> }, | ||
LocationChanged { | ||
/// contact_id of the contact for which the location has changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// contact_id of the contact for which the location has changed. | |
/// The contact for which the location has changed. |
It's clear now that it's a contact_id, I think this can be removed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it can be removed. Feel free to apply suggestion, though keep in mind about the point of "keeping files in sync".
/// Message ID. | ||
msg_id: u32, | ||
|
||
/// Status update ID. | ||
status_update_serial: u32, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here, a comment Message ID
on a field msg_id
and Status update ID
on status_update_serial
doesn't add any new information, at least when I'm reading it.
/// Message ID. | ||
msg_id: u32, | ||
|
||
/// Realtime data. | ||
data: Vec<u8>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
|
||
/// Inform that a message containing a webxdc instance has been deleted | ||
#[serde(rename_all = "camelCase")] | ||
WebxdcInstanceDeleted { msg_id: u32 }, | ||
WebxdcInstanceDeleted { | ||
/// ID of the deleted message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// ID of the deleted message. | |
/// Message ID of the deleted webxdc instance. |
in order to keep consistent wording
ChatlistItemChanged { | ||
/// ID of the changed chat | ||
chat_id: Option<u32>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also here, not necessary to say comment ID of the changed chat
when the event is called ChatlistItemChanged
and the field chat_id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I said in the replies, I, for the most part, simply copied the docs from payload.rs
, making the docs synced.
If you think it's fine to make some adjustments, feel free to commit / implement the suggestions, I have no objections in this regard.
IncomingMsg { | ||
/// ID of the chat where the message is assigned. | ||
chat_id: u32, | ||
|
||
/// ID of the message. | ||
msg_id: u32, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought so as well, but I kept it because they're in payload.rs
, I wanted them to be in sync.
MsgDeleted { chat_id: u32, msg_id: u32 }, | ||
MsgDeleted { | ||
/// ID of the chat where the message was prior to deletion. | ||
/// Never 0 or trash chat. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are sometimes emitted with chat_id=0 or msg_id=0?
Judging from DC Desktop code, this can be the case for at least ReactionsChanged
and MsgsChanged
. See the code.
#[serde(rename_all = "camelCase")] | ||
LocationChanged { contact_id: Option<u32> }, | ||
LocationChanged { | ||
/// contact_id of the contact for which the location has changed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, it can be removed. Feel free to apply suggestion, though keep in mind about the point of "keeping files in sync".
Or just let me know if I should go ahead, and I'll clean this up myself |
So, do we merge as is? |
Co-authored-by: WofWca <[email protected]>
Yes 👍 |
The first commit is a follow-up to #6072.
For the second commit I did not read through the docstrings thorougly, I simply copied them from
payload.rs
and moved around slightly.