GNOME Bugzilla – Bug 731537
Use HeaderBar for composers
Last modified: 2014-07-18 18:52:10 UTC
We could use a HeaderBar for composers, both when they're inline and popped out. This would increase the consistency of their appearance, at least on systems with client-side decorations. My rough idea would be to move the button bar at the bottom to be a HeaderBar. The close button would be come an X (which would remove duplication when its detached) and we may be able to find a symbolic icon for Detach. For the compact inline view, we could have the recipients and the @ button in the HeaderBar as well. I don't know where the attachments button should go. It could go into the HeaderBar, but that'd be a bit tight if we're also using it for the recipients list. We could add it to the Toolbar, but it'd be a bit out of place there. We could get rid of it completely and rely only on drag-and-drop, though we'd probably want the editor to be a drop target as well. I'm ambivalent about the client-side decoration in general, but given what I know about Wayland, I suspect it's the future whether I like it or not. So I'm suggesting this more out of resignation than out of excitement.
My hesitation here is whether it will "look" right in the inline composer. It certainly might look good or even great, but I have a feeling it will give the top of the composer a cluttered look due to all the buttons in the header bar followed immediately by the editor toolbar. Presumably the recipients list would be the centered text (note that header bar has "title" and "subtitle" fields, which Geary uses today) and the buttons would hang to the left and the right of that text. (Getting the "@" button right might be a trick, although I believe you can configure header bar to use whatever widgets you want in the center.) I would push hard for keeping the Attach File button. DnD is fine, but if every time I want to attach a file I have to invoke Nautilus, it becomes a pain. All this said, I can completely see GtkHeaderBar working for the detached composer. However, that now introduces another fork in the code patch for the cmoposer, which I know we're trying to avoid.
Created attachment 278638 [details] Mockup -- compact composer Here's a few mockups of what it might look like. Having centered recipients in the compact view struck me as odd, so I left-aligned them. I put the attachment button in the header, but not in the compact view. But it might work better in the editor toolbar.
Created attachment 278639 [details] Mockup -- inline composer
Created attachment 278640 [details] Mockup -- detached composer
Created attachment 278647 [details] Mockup -- Adwaita theme The Ambiance theme helps distinguish the header bar from the toolbar. The Adwaita theme doesn't look as good with this, but I think it's passable.
(In reply to comment #5) > Created an attachment (id=278647) [details] > Mockup -- Adwaita theme > > The Ambiance theme helps distinguish the header bar from the toolbar. The > Adwaita theme doesn't look as good with this, but I think it's passable. You can to try to add to the send button the 'suggested-action' style class? See here how it look: https://wiki.gnome.org/HowDoI/Buttons
Jim, any thoughts on the mockups? Yosef, that's a good suggestion. There's plenty that could be improved here. The detach and attachment buttons could probably be changed to icons, for example. But we need to decide if this is a good idea or not before we attack those things.
I think this looks promising and goes a good way toward making the compact inline composer even more compact. I agree, the attach button could be turned into an icon and added to the editor toolbar -- I vote for the paperclip icon we use in the conversation viewer to indicate attachments. Perhaps the paperclip with a slashed-circle over it for detach? And if we're going to do this, I agree we should use the suggested-action style class for the Send button. (We should probably do that even if we don't use GtkHeaderBar.) Regarding Ambiance and Adwaita, this is one place where Ambiance + GtkHeaderBar actually looks better than Adwaita. Funny that is. But we can live with it, I don't think the Adwaita version is unusable at all. And, yes, the recipients in the center don't look right at all. I would say move forward on this if you're so inclined! This adds some nice detail work to the inline composer, which has become one of those "how did I live without this?" feature for me.
(In reply to comment #7) > Jim, any thoughts on the mockups? > > Yosef, that's a good suggestion. There's plenty that could be improved here. > The detach and attachment buttons could probably be changed to icons, for > example. But we need to decide if this is a good idea or not before we attack > those things. I think it really a good idea to replace the detach button with the view-fullscreen-symbolic icon[1]. [1] https://git.gnome.org/browse/adwaita-icon-theme/plain/Adwaita/scalable/actions/view-fullscreen-symbolic.svg
Whoops, I thought Robert was talking about detaching (removing) attachments from the message. Yes, the composer-detach button should be something else. I don't know if I would use Fullscreen for it though. We might need a custom icon here.
Created attachment 280321 [details] [review] WIP - HeaderBars for composers Here's a work-in-progress patch on this. I'd been working on the scrolling issue, but I realized that some issues of sizing may depend on this, so I figured I should attack this first, rather than doing it all at once. Things should mostly work with this. There's still a bar at the bottom of the composer that needs to be removed. It's just holding the draft save status label, which was something my mockups didn't think to address. I still don't know where this should go. For inline composers, I guess it could go to the main window status bar, though it could get confusing if several try to write to it. It could go to the same overlay we use for the URLs. We could add a label to the Headerbar or to the toolbar, or we could make a little icon for one of those places. Or we could just remove it completely. Drag and drop in the compact inline state is sorta silly, but I'm not going to worry about that right now. The various buttons in the Headerbar all have associated actions now. I didn't know which thing did once, so they all have labels, short_labels, and tooltips right now. Some of these could be removed. I used the window-maximize-symbolic icon for the "Detach" button, since that seemed closest in name. But the icon is just a square, so its action isn't immediately obvious. I didn't really see a better option, but reversing the arrow on view-restore-symbolic might give us something. For the "Include Original Attachments" button, I used edit-copy-symbolic, with the hope that, given its proximity to the attachment icon, it indicates a copying of attachments. This is a rather complicated concept to get across in icon form, though, so I don't know if we can do any better.
Review of attachment 280321 [details] [review]: Wow, I think this looks really good. I like the postage-stamp icon in the Send button, that's a nice touch. GtkHeaderBar really does clean up the interface. Things I'm seeing right now, small and large: * On my icon set, the attachments button is a paperclip. The "expand recipients" button is an at-sign. Unfortunately these two symbols look very similar, and compounding the issue is that they're placed in the same location but not at the same time (depending on the composer's mode). I know it was my suggestion to use the paperclip icon for attachments; I'm now concerned this is going to trip people up. (It tripped me up just testing this patch.) Any suggestions? * As for the Saving/Saved state, I do like that as it gives me that tiny bit of assurance that my work is, of course, saved. I like the overlay idea, but does that mean we would persist the overlay (i.e. "Saved" is constantly displayed)? That might be a bit cluttery. How about moving the indicator to the editor toolbar, to the left of the right-most dropdown menu button? Not perfect, but anything to get rid of the bottom bar. * I don't have a suggestion for an Include Original Attachments icon; I remember an internal discussion where we knocked around icon ideas and finally had to punt and use plain text, leading to a rather lengthy button label. A larger question for me is whether or not it should be displayed in compact mode, that is, should the user have to press the "edit recipients" button to see it. My vote is that it should always be present (at least, until it's pressed). I know that in the past, the presence of the button reminded me to include the attachments. * For the "include original attachments" & "detach" icons, I'm okay with what you have today but agree there may be improvement. I don't want to hold up this patch over icon questions, so we can file tickets to improve them. Hopefully someone out there will have a better suggestion or, potentially, provide us with custom ones. * Another place to look for symbolic icons is http://thenounproject.com/. If you find ones that work, be sure they're licensed appropriately. Here's a detach icon that's not quite right but opens up some ideas: http://thenounproject.com/term/detach/28818/ Here's an include icon that might work too: http://thenounproject.com/term/import/50957/ I'm not sold on both, but it's an example of what you can find on the site with a little searching. * Code-wise, no complaints save one small one: composer-widget.vala:185, I prefer if instance variables are grouped public/protected/private (and properties grouped likewise separately). We've not been perfect about holding to this, but anything to contain the chaos is important. In other words, please move this line to composer-widget.vala:160. If the variable needs to be available externally but is never to be set externally (which I suspect it is but didn't check thoroughly), then I would say make this a property with { get; private set; } modifiers.
Created attachment 280534 [details] [review] Use HeaderBars for composers The reason for not showing the attachment buttons in the compact mode was that they took up a lot of room. But that's not true now that they're reduced to icons, so I think there's no reason not to show the all of the time. I didn't like the look of the @ button next to them, so I just got rid of it completely. Instead, the address listing is now a button, but like the close and detach buttons, it's not raised until the user hovers over it, to reduce visual clutter. I like this approach, but I worry it's not very discoverable. That said, the user only had to figure it out once; it should be pretty memorable. We could add a line to the tooltip about clicking to edit the recipients, but I think it's unnecessary. I've moved the draft save label into the toolbar. It's not a perfect solution, but I think it's good enough for now. We could consider replacing the text with an icon or a colored symbol. This is hooked up with a entirely over-engineered solution, with the goal of making it easy to move again in the future, if we decide there's a better place. I'm aware of a few issues: - I haven't done anything with the icons yet. - The close and detach buttons are hard-coded to appear on the right, instead of adapting to the user's theme. - The compact inline composer is a bit jumpy when you drag-and-drop an attachment onto it. - The top corners of the inline composer look funny when you use a theme that gives HeaderBars rounded top corners. None of these are huge, and I'd be willing to land this in the current state and get the these issues later.
Review of attachment 280534 [details] [review]: ::: src/client/composer/composer-headerbar.vala @@ +71,3 @@ +#if GTK_3_12 + add_end(send_button); +#endif Something here is wrong. The X ם buttons in the inline-headerbar looks without any spaces between them.
Yosef, can you give us a screenshot of what you're seeing? Otherwise, I'm for landing this now. In fact, Robert, please commit. Yosef, if you still see the issue, please file a new ticket. Robert, if you can file tickets for the issues you last listed (that are worth filing), that would help me out a lot. I'm ok with the Include Original Attachments icon (esp. w/ it pressed up against the Add Attachment icon) but do think the Detach icon can use some work. I'm unsure if the rounded corners problem is that monumental. The jumpiness of the composer didn't bother me much.
Jim, right now I can't take a screenshot, see bug #733341.
Yosef's issue may be that there's no padding between the detach button and the separator. The default close button has a bit of space there. We ought to set the same amount of padding, but I couldn't find where it's done, so I don't know how much it is. It may also be theme-dependent. It can be another bug. Attachment 280534 [details] pushed as 221d8f7 - Use HeaderBars for composers
The detach icon is bug #733370. The button alignment issue is #733372. The DND issue is #733373. The corners are bug #733374.
Thanks, Robert, I appreciate the help.