Add option for non-modal compose windows (New post or Quote post)

[sivy]

Describe the request

I think there is a good case to be made for providing a non-modal compose window for New post or Quote posts.

The current modal secondary window implementation leads to a very narrow compose experience. No matter the Tuba window width, the compose UI is very small:

As more servers allow longer posts (my current server supports 2000-character posts) this UI is very confining. Allowing for a non-modal compose window would allow the user to resize the window when useful.

There have been multiple times where I start composing but then need to go find a link to another post, or copy some text to include, but the modal secondary window doesn't allow me to do so. I don't know if I'm an edge case or not, but some of us could really use a UI where we can have more than 1 in-progress post up and visible while still being able to do something else in the app.

This isn't a simple change, but I'd like to start a conversation about how this could work. Thanks!

Checks

• This follows the GNOME HIG.

[GeopJr]

Thanks for the report!

secondary window

Allowing for a non-modal compose window would allow the user to resize the window when useful.

On a technical level, these libadwaita dialogs (not only in Tuba), are not exactly Windows (though the most of the HIG on secondary windows apply to them too).

They have two modes, either host or window (don't think that's the actual names, but I'll call them like that for this comment). Host is the default and window is only used in some special cases. The app (e.g. tuba) can't choose which one is used, though I have done some hacks in the past on Turntable to force it to use the window mode (by making the primary window non-resizable before showing the dialog).[1]

In window mode, it acts as a typical separate modal window, like they always did in the past. In host mode however, the dialog is rendered inside the app, it's not a separate window. Its size can only be as big as the primary window because its rendered by it. This allows them to have a bottom drawer style (see https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/class.Dialog.html) when the window gets narrow enough.

With that said, I'll quote a part from the doc

AdwDialog is not resizable. Use the AdwDialog:content-width and AdwDialog:content-height properties to set its size, or set AdwDialog:follows-content-size to TRUE to make the dialog track the content’s size as it changes. AdwDialog can never be larger than its parent window.

There have been multiple times where I start composing but then need to go find a link to another post, or copy some text to include, but the modal secondary window doesn't allow me to do so. I don't know if I'm an edge case or not, but some of us could really use a UI where we can have more than 1 in-progress post up and visible while still being able to do something else in the app.

I'm not opposed to it, I think it would actually be useful. But, the composer is very complex and decoupling it from AdwDialog would require quite a bit of effort. Plus it would require maintaining two different branches for when it's inside an AdwDialog vs when it's inside a Window. So personally, I'd like to maybe try to work with upstream to allow setting the resizable property for when the dialog is in window mode? Otherwise, to avoid maintaining two different branches, I could make the composer's width change based on the primary window's instead of being static. Neither of these however would allow you to have multiple composers open at the same time though...

[1]: though there's on going progress to have it follow the system's "attach dialogs to windows" setting, see https://gitlab.gnome.org/GNOME/libadwaita/-/issues/801

(FWIW, the composer's height will follow the content's, so my personal take is that the character limit doesn't matter much here:)