Skip to content
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

Merged
merged 4 commits into from
Feb 14, 2025
Merged

docs: improve docstrings #6496

merged 4 commits into from
Feb 14, 2025

Conversation

WofWca
Copy link
Collaborator

@WofWca WofWca commented Feb 1, 2025

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.

Replicate the docstrings from `src/events/payload.rs`.
@WofWca WofWca force-pushed the wofwca/event-docs branch from 80f6383 to c82fcfb Compare February 1, 2025 17:43
@WofWca WofWca marked this pull request as ready for review February 1, 2025 17:44
@Hocuri Hocuri requested review from link2xt and Hocuri February 4, 2025 18:40
Copy link
Collaborator

@Hocuri Hocuri left a 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.

Comment on lines +152 to +158
IncomingMsg {
/// ID of the chat where the message is assigned.
chat_id: u32,

/// ID of the message.
msg_id: u32,
},
Copy link
Collaborator

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.

Comment on lines +175 to +179
/// ID of the chat which the message belongs to.
chat_id: u32,

/// ID of the message that was successfully sent.
msg_id: u32,
Copy link
Collaborator

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.
Copy link
Collaborator

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?

Copy link
Collaborator Author

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.

Copy link
Collaborator

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// 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

Copy link
Collaborator Author

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".

Comment on lines +346 to 350
/// Message ID.
msg_id: u32,

/// Status update ID.
status_update_serial: u32,
Copy link
Collaborator

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.

Comment on lines +356 to +360
/// Message ID.
msg_id: u32,

/// Realtime data.
data: Vec<u8>,
Copy link
Collaborator

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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
/// ID of the deleted message.
/// Message ID of the deleted webxdc instance.

in order to keep consistent wording

Comment on lines +392 to +394
ChatlistItemChanged {
/// ID of the changed chat
chat_id: Option<u32>,
Copy link
Collaborator

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

Copy link
Collaborator Author

@WofWca WofWca left a 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.

Comment on lines +152 to +158
IncomingMsg {
/// ID of the chat where the message is assigned.
chat_id: u32,

/// ID of the message.
msg_id: u32,
},
Copy link
Collaborator Author

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.
Copy link
Collaborator Author

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.
Copy link
Collaborator Author

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".

@WofWca
Copy link
Collaborator Author

WofWca commented Feb 4, 2025

If you think it's fine to make some adjustments, feel free to commit

Or just let me know if I should go ahead, and I'll clean this up myself

@WofWca
Copy link
Collaborator Author

WofWca commented Feb 6, 2025

So, do we merge as is?

@Hocuri
Copy link
Collaborator

Hocuri commented Feb 6, 2025

Yes 👍

@WofWca WofWca enabled auto-merge (squash) February 10, 2025 09:40
@link2xt link2xt disabled auto-merge February 14, 2025 23:10
@link2xt link2xt merged commit 5c3d1e7 into main Feb 14, 2025
37 checks passed
@link2xt link2xt deleted the wofwca/event-docs branch February 14, 2025 23:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants