This is intentional and a design choice.  We wanted to keep the inline composer's chrome to a minimum, otherwise it will fill too much of the main window.

However, that design choice was made when the inline composer was still in its infancy.  Robert's made some nice improvements to how it sizes itself inline.  Perhaps it's time to revisit the question.

The rationale is somewhat understandable. It causes confusion though. Maybe clicking in the destination address to expand it should detach the composer directly?

I had an idea about this, but I don't think I ever made a bug for it.  So I'll just post it here.

In the detached composer, the subject is duplicated in the header and the subject entry.  So why not move the subject entry to the header?  My idea is that it'd be a label until you click it, at which point it becomes an entry.  (We'd want some trickery to ensure that you can still drag the window; I don't know how hard this would be.)

And if we're doing that in the detached composer, it'd be natural to make it happen in the inline composer as well.  It wouldn't take up any more space than it currently does, but it'd use the middle of the headerbar, which is currently blank.

The inline-compact mode (the one with the recipients listed) would remain unchanged.  Perhaps we should add the subject to the tooltip.

I'm not sure what to do about the inline-new mode.  We could do it there as well, but that'd disrupt the recipients-subject-body sequence that everyone's used to.  (Although, we could set the tab order that way.)  But since space is not so restricted there, and because the subject has to be set, keeping a separate entry may be the way to go.

What about using an expander for the extra fields? This way the space could be easily reclaimed. It could also work with a popover shown when the destination is clicked.

IMHO, I don't think repeating the subject in the detached composer is a big issue. Maybe the header could show the conversation title (empty for new message), instead of the subject?

P.S.: I'm just trying to contribute some ideas. I'm sorry for being intrusive! Please, feel free to ignore anything I say and to tell me to shut up anytime!

(In reply to comment #4)
> What about using an expander for the extra fields? This way the space could be
> easily reclaimed. It could also work with a popover shown when the destination
> is clicked.

I'm don't think I understand.  Where would this expander go?  Perhaps you could make a mock-up.

> P.S.: I'm just trying to contribute some ideas. I'm sorry for being intrusive!

Not at all.  There's not a whole lot of presidence for how conversation-focused mail clients should work, so we're groping around a bit.  The more ideas that get thrown out, the higher the chance that we stumble on the right one.

(In reply to comment #5)
> 
> I'm don't think I understand.  Where would this expander go?  Perhaps you could
> make a mock-up.
> 

Let me try some ascii "art".

First, let me draw the current layout so you can maybe understand my notation. Initially, when clicking the reply button, you have this inline composer (more or less):

-----------------------------------------------------------------------------
[attach] destination (unrelieved button)              [send] | detach discard
-----------------------------------------------------------------------------
                                  (rich text tools)
-----------------------------------------------------------------------------
                                    (message area)
-----------------------------------------------------------------------------

when you click the destination button, it leaves the header and three rows with to: cc: and cco: entries are added below:

-----------------------------------------------------------------------------
[attach]                                              [send] | detach discard
-----------------------------------------------------------------------------
to: [                                                                       ]
cc: [                                                                       ]
cco:[                                                                       ]
                                  (rich text tools)
-----------------------------------------------------------------------------
                                    (message area)
-----------------------------------------------------------------------------

Now, my idea is to have an initial composer slightly different, using an expander instead of a button:

-----------------------------------------------------------------------------
[attach] > (expander button) destination              [send] | detach discard
-----------------------------------------------------------------------------
                                  (rich text tools)
-----------------------------------------------------------------------------
                                    (message area)
-----------------------------------------------------------------------------

when you click the expander button, the extra entries are shown:

-----------------------------------------------------------------------------
[attach] v (expanded expander button)                 [send] | detach discard
-----------------------------------------------------------------------------
to: [                                                                       ]
cc: [                                                                       ]
cco:[                                                                       ]
sub:[                                                                       ]
                                  (rich text tools)
-----------------------------------------------------------------------------
                                    (message area)
-----------------------------------------------------------------------------

it is possible then to edit the entries. If you need more space for the message, though, you can collapse the expander again and go back to the previous ui state. You can always check the entries again by expanding and collapsing.

Note: I do not know if this is even possible to do with the ui toolkit.


> 
> Not at all.  There's not a whole lot of presidence for how conversation-focused
> mail clients should work, so we're groping around a bit.  The more ideas that
> get thrown out, the higher the chance that we stumble on the right one.

Glad to hear it. I hope I can help then.

What you're suggesting could be done with GtkRevealer.  Or, we could simply punt and add Subject to the inline composer, displayed when the user clicks on the Recipients' button when collapsed.  I feel better about doing this now with the scrollbar work Robert got in before we shipped, because the composer is now much more intelligent about how it uses space.

One proviso to your suggestion, Davi, is that when the fields are revealed, they need to stay revealed.  We encountered this issue when working on the inline composer.  If the user begins editing those fields, allowing them to collapse/hide them opens up a can of worms UI-wise.

I agree with Davi that the Subject field should be editable also in inline mode, when the user clicks on the recipient label (exiting the compact mode).

By the way, I see that the inline composer, even in compact mode, always shows the Cc field even if it's empty. This is a waste of space.

Closing in favour of https://gitlab.gnome.org/GNOME/geary/issues/471