[Request]: When writing a reply, allow reading messages I'm replying to

[Kekun]

Describe the request

I wanted to reply to a message, so I clicked the reply button which opened a dialog. Everything is fine except that I couldn't remember exactly what the message I'm replying to was saying and I needed to read it again to reply correctly. Problem: the dialog was covering the toot and I had to close the dialog to red it again, wich is annoying.

The messages I'm replying to are my context, and the thread is the state I'm altering by appending a message to it. While I don't like how Mastodon handles writing replies, in a left column disjointed from the thread, it has the advantage of letting me read the previous messages: it gives me access to the context. Tuba's dialog feels a bit less disjointed as it replaces the context's view, but it prevents me from reading it.

What I prefer is when the message editor is inlined in the thread, they give me the whole context of the message I'm writing, and they show me exactly how it will alter the thread by appending a message to it, they are very clear and leave me in control.

Maybe the message editor could be inlined in the thread? Of course this leaves the navigation bits of the window accessible, so anything that would leave the current view should warn it will quit editing the dialog, like the current message edition dialog does, with the extra benefit of not having a dialog in a dialog. And when writing a new message, that could open a new thread view with only the editor at the top and no message above. Alternatively maybe the previous messages could be made readable from the dialog somehow.

BTW thanks a lot for Tuba! 🤗

Implementation Details

• This follows the GNOME HIG.

[GeopJr]

Thanks for the suggestion!

The composer redesign is mostly tracked on #553. Tobias' design is here #553 (comment)

Showing the replying-to post on it has already been implemented in the (quite outdated) draft

Screencast.from.2024-02-12.02-40-41.webm

That does not show the whole thread however. Implementing the new composer is still in the very early stages as I'm trying to break it into as many smaller parts as possible, so any other ideas - however contradictory to the current proposed design, like an inline-composer - should be brought up in #553 so Tobias has a look at them!