Hide the message input bar in rooms where the user is not permitted to send messages

[tyreseluo]

Continuous user subscription to room status does not seem to be realized.When a user's power level in a room changes, it may not be updated in time.

[Demolemon11]

Thanks for your encouragement, I'll be more serious and work harder!

[kevinaboos]

Thanks for your encouragement, I'll be more serious and work harder!

All good! It's just part of the learning process; I see improvements already on your side :)

[Demolemon11]

231

I have move the logic from draw_walk to handle_event while reusing the runtime in sliding_sync. I'll keep on staying the course if it still needs to be improved:)

[Demolemon11]

You mean that I am supposed to call func Room:can_user_send_message() here, right?: https://github.com/project-robius/robrix/blob/75f101b921c9303133884b7707e9d5b615830961/src/sliding_sync.rs#L408 And give MatrixRequest::FetchRoomMembers a boolean value?

Then handle the notice here, right?: https://github.com/project-robius/robrix/blob/75f101b921c9303133884b7707e9d5b615830961/src/home/room_screen.rs#L1530

[kevinaboos]

No, not quite. I meant that you need to create a new variant within the MatrixRequest enum, which will be used for your new "can a user send messages in a given room" function. You should imitate the code structure of how the FetchRoomMembers features is implemented; in other words, use that as an example to show you how to correctly design your code structure.

Similarly, you need to create a new variant in the TimelineUpdate enum, which will then be sent back to the timeline from the code block that handles your new "can a user send messages in a given room" function (within sliding_sync.rs). And then, yes, you will handle that new TimelineUpdate variant within the room screen event handler.

[Demolemon11]

When you put it like that, it makes perfect sense to me. My English is not good, sorry for bothering.

[kevinaboos]

no problem! glad you understand the general idea now.