Composer redesign

[GeopJr]

The composer is a bit complex. We can divide it into 3 sections: Text, Media and Polls

• Each section has its own set of actions
• There can be either Media or Polls
• Media can be published on their own but polls require some Text
• Text character counter includes the Content Warning
• Text character counter replaces urls with a set amount of characters (not done in tuba yet, depends on instance's info, ex. https://geopjr.dev is 18 characters but will be counted as 7, the regex should match mastodon's so we match them 1:1 even if it has its quirks)

Below I've attached screenshots from other apps' composers. It's important to notice how the pages and actions interact with each other. Megalodon and Mastodon web make the inactive actions insensitive (the media attach button is no longer sensitive when polls are active), Elk replaces them (the media attach button gets replaced by the poll's actions) and tuba has a pages system

App	Text	Media	Polls
Tuba
Megalodon
Elk
Mastodon Web
Phanpy

[LukaszH77]

Phanpy's editor. I like the way media handling is done here.

[GeopJr]

Nice! Added to the OP

[bertob]

I started a comprehensive redesign a while back, but haven't gotten around to finishing it yet. I'll hopefully get to the missing stuff soonish, but here's the current state if you already want to try some of it:

[astrosticks]

Please keep reordering media in mind as a use case! Preferably drag-and-drop

[nanopone]

in favour of abandoning the pages system entirely. i'm very used to typing a post and then instantly pressing ctrl+v to paste a screenshot or dragging a photo/video directly into the composer to upload it. that's how it works on almost every fedi web front end, as well as twitter and messenger apps like discord and signal, meaning i've been doing this for about 10 years, maybe more. having to rewire my brain to click on the media tab first is a small ask, but gets very frustrating

[GeopJr]

I'm kind-of stuck on some behavior decisions:

In the context of Adw.ToolbarView, the bottom bar holds the buttons as the third dialog on the first screenshot indicates.

Is the title ("New Post", "Reply to {mention}") part of the top bar or the content? If it's part of the top bar, is the post, when available, also part of it? The difference is the scroll behavior, if it's part of the top bar then it will always be visible, if it's not, then you can scroll down and it will hide.

And lastly, what's the desired behavior of the textview (input)? Should the scroll position follow the cursor or should the scroll position be static?

The answers to the above will decide how everything will be implemented as they have different requirements. Keep in mind that we are limited on space when items are "always visible"

[bertob]

Is the title ("New Post", "Reply to {mention}") part of the top bar or the content?

I was imagining the title would be fixed (primarily to avoid overlapping the close button), the post you're replying to would scroll, but now that you mention it maybe it'd be better to try having it all in the scrollview 🤔

what's the desired behavior of the textview (input)? Should the scroll position follow the cursor or should the scroll position be static?

I'd guess follow the cursor, like any other textview? Not sure I totally follow, do you have an example from another app?

[GeopJr]

I was imagining the title would be fixed (primarily to avoid overlapping the close button), the post you're replying to would scroll, but now that you mention it maybe it'd be better to try having it all in the scrollview 🤔

Not sure how much stuff can stay outside the scrolledwindow :/ space is very limited

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

Maybe let the title be on the topbar but the reply-to post be already scrolled out of view? So if you need to see the post you must scroll up? (I believe the mobile app does it that way)

I'd guess follow the cursor, like any other textview? Not sure I totally follow, do you have an example from another app?

It does so when it's a direct child of a scrolledwindow. When there are other layers it doesn't do it automatically, so depending on how everything else will work, will change the way we implement it. This is what it looks like without manually implementing it on ScrolledWindow -> Viewport -> Box -> Box

Screencast.from.2024-02-12.02-39-13.webm

[bertob]

Can we dynamically grow the dialog height depending on the content? If so, I'd grow it up to a certain max height to fit the content of your post / the quoted post. Given that some instances have super long maximum post lengths I guess we'll need some kind of max height for the quoted post anyway though no?

It does so when it's a direct child of a scrolledwindow. When there are other layers it doesn't do it automatically, so depending on how everything else will work, will change the way we implement it. This is what it looks like without manually implementing it on ScrolledWindow -> Viewport -> Box -> Box

Yeah, this example doesn't look right, the focus should follow where the cursor currently is.

[GeopJr]

Would using a TabOverview for threads be too much? Maybe behind a setting for advanced users?

(demo image from libadwaita)

Each page will be a different post and when the user clicks publish they will all get posted as a reply to the previous one

[bertob]

I'm not sure a two-dimensional grid is a great fit for a one-dimensional list, how do other apps handle authoring threads?

[GeopJr]

They don't. As far as I know (only Web, Android, Linux), no app does it at all. Glitch-soc has a 'threaded-mode' but it just sets the composer to reply to the previous published post - rather than publishing multiple at the same time

Re-ordering and distinguishing between them should be considered. Not sure about tabs as it would get pretty cramped quickly