572484 - [Linux] New toolbar button style

Status: RESOLVED WONTFIX

(Firefox :: Theme, enhancement)

Description

[Stephen Horlander [:shorlander]]

Attachment: Linux Toolbar Button Style

Implement new toolbar style for Linux. Using gradients and system color to mesh with the system theme.

Comment 1

[Stephen Horlander [:shorlander]]

Attachment: CSS/SVG Example

This is sort of what I had in mind. If you are on Linux and change the theme this changes color to adapt. The glyphs aren't centered and it has some issues with dark themes.

Comment 2

[Michael Monreal [:micmon]]

Just tested this and mostly got great results. I also like this concept for other toolbar icons (bookmarks icon, as seen on the first attachment).

The only themes were it seems to cause problems are the a11y ones (LargePrint) but maybe those should have special handling anyway (toolbars should be larger etc)

Comment 3

[tymerkaev]

Attachment: patch (draft)

Things in this patch:

1. I've removed both toolbar.png and toolbar-small.png and used gtk-save, tab-new and window-new instead. Remaining items (bookmarks and history) were moved to their right place (/places).

2. New toolbar button style won't apply to mode Icons + Text.

3. Icons scaled to 16x16 px for now.

4. I haven't tested it, and it may looks wrong somewhere.

Comment 4

[Michael Monreal [:micmon]]

I have yet to test the patch but:

>> 1. I've removed both toolbar.png and toolbar-small.png and 
>> used gtk-save, tab-new and window-new instead.

You don't want to do this
gtk-save: you want to use this for the downloads button, right? It is not meant for this.
tab-new and window-new: these only exist in freedesktop themes. Firefox does not depend on a freedesktop theme, so it can only use GTK stock icons

Comment 5

[Michael Monreal [:micmon]]

BTW the patch didn't apply cleanly when I tried it. I think you should drop the part listed as "1"... if my information is correct we will have new SVG based icons for all the toolbar stuff anyway.

Thanks for working on this btw, I'll be happy to test new versions of the patch as they become available.

Comment 6

[tymerkaev]

Attachment: patch

Comment 7

[Michael Monreal [:micmon]]

Attachment: Screenshot with patch 472593

Ok here's a screenshot of the current patch applied.

- hover states looks a bit weird
- buttons are too high (they should have the same high as awesome/search bars)
- alltabs and tabcandy buttons are not supposed to have button look I think?
- a lot of the "good look" depends on the adaptive color glyphs used instead of real icons

Big toolbar mode:
- forward button too big and not attached to back

Comment 8

[tymerkaev]

(In reply to comment #7)
> - hover states looks a bit weird

Screenshot?
> - buttons are too high (they should have the same high as awesome/search bars)

Will be fixed.
> - alltabs and tabcandy buttons are not supposed to have button look I think?

yes
> - a lot of the "good look" depends on the adaptive color glyphs used instead of real icons

It's bug 572485.
> Big toolbar mode:
> - forward button too big and not attached to back

Will be fixed.

Comment 9

[Michael Monreal [:micmon]]

Attachment: Button states with patch 472593

Here's a screenshot of the normal/hover/pressed states of the large and small nav buttons. Is there a mockup on how this is supposed to look like? Right now it looks like as if the button comes out a bit on hover. Maybe it only looks weird because the current icons don't reflect this and stay in place (should be better with the glyps).

Take a look at the large back button in pressed state, you can see a white half-circle there which doesn't look nice.

Additionally there seems to be a bug with the pressed state (which could be a toolkit bug): press a button, keep it pressed and move the mouse away, then release (so the button is not actually pressed). Move the mouse back to a button: the hover state now looks like pressed state.

Comment 10

[Michael Monreal [:micmon]]

Attachment: Line between small back/forward

I think there should be only a single line between the back/forward buttons in small size. Right now the right button is drawn with corners which looks weird (screenshot).

Comment 11

[tymerkaev]

Comment on attachment 472593 [details] [diff] [review]
patch

I'll post new version of patch tomorrow.

Comment 12

[tymerkaev]

Attachment: patch v2

Comment 13

[Michael Monreal [:micmon]]

Attachment: Screenshot patch v2

Good work!

general:
- button outline is "fat" now, should be one pixel I think (looks a bit like off-grid vector rendering?)
- buttons are still to high but that may very well be due to the previous problem?
- no hover effect anymore?

large:
- back is no longer a circle and draws out of the toolbar
- forward needs to reach a bit more "below" the back button (could be related to the non-circle thing)

small:
- prev/next separator has strange pixels to the right side of either end
- prev/next separator is darker than the outline (should be same color?)

Comment 14

[tymerkaev]

Attachment: patch v3

Comment 15

[Michael Monreal [:micmon]]

The large back button has the corrent size/shape again but all other comments for patch v2 listed above are still valid.

Comment 16

[Michael Monreal [:micmon]]

Attachment: Screenshots with and w/o patch v3

Remember the tab sizing issue andreasn and me were talking about the other day? Turns out your patch fixes the issue - kind of.

Please have a look at the collection of screenshots. The left shows current tip without any patch, the right has v3 applied. As you can see, the app tabs look fine on the top right but look bad again when opening the toolbar editor. This seems to be because the buttons on the right get button look and enlarge the tab bar. Normal tabs just grow from 24 to 27 pixels, but app tabs don't do the same for some reason.

Can we make tabs look always good and not have the tab bar resize when opening the editor?

Comment 17

[tymerkaev]

Attachment: patch v4

Comment 18

[tymerkaev]

Attachment: patch with changed dropmarker

Default dropmarkers on Linux have different size and may broke width and height of toolbar buttons. Own dropmarker will fix this issue.

Comment 19

[tymerkaev]

Comment on attachment 475579 [details] [diff] [review]
patch with changed dropmarker

Sorry, forget about jar.mn changes.

Comment 20

[tymerkaev]

Attachment: patch v5

Fixed all previous comments.

Comment 21

[tymerkaev]

Attachment: patch v5

Fixed hover state.

Comment 22

[Michael Monreal [:micmon]]

No hover and pressed state for me anymore using the latest patch.

Comment 23

[Michael Monreal [:micmon]]

Attachment: Screenshot v5

Also, back/forward in big toolbar mode is still broken and the arrow inside the url entry (right side) doesn't look right (=> Screenshot v5)

Comment 24

[Michael Monreal [:micmon]]

This seems to be stalled... where is the problem, what remains to be done?

Comment 25

[Zio_Fede]

Will we see the new buttons for firefox 4.0? Or is this bug dead...

Comment 26

[tymerkaev]

Attachment: patch v6

Comment 27

[tymerkaev]

Attachment: patch v6

Forgot to update some rules.

Comment 28

[Andreas Nilsson (:andreasn)]

this patch needs a small fix in jar.nm to say   
skin/classic/browser/dropdown-arrow.svg

instead of
skin/classic/browser/dropdown-arrow.png

Comment 29

[tymerkaev]

(In reply to comment #28)
> this patch needs a small fix in jar.nm to say   
> skin/classic/browser/dropdown-arrow.svg
> 
> instead of
> skin/classic/browser/dropdown-arrow.png

Ooops! Yes, thanks for checking.

Comment 30

[tymerkaev]

Attachment: patch v7

Comment 31

[tymerkaev]

Attachment: patch v8

Comment 32

[Nick]

These new Toolbar Buttons look great! I'm so happy to see these for Linux.

Hopefully these will also address the size issues that currently exist in the GTK Toolbars on Linux: the Large buttons are way too big; the Small buttons are too small. 

The size of the Toolbar buttons on Microsoft Windows Firefox are perfect. Hopefully these new buttons for Linux will be the same size as the ones on Windows.

Comment 33

[Nick]

How much longer before these new Toolbar Buttons are implemented?

Comment 34

[Brandon Cheng]

Applying patch v8 produces a failure in some areas.

Comment 35

[Paul Rouget [:paul]]

Can I get some more details about what this bug is exactly about?
- gradient around the buttons
- using SVG icons that will be provided in bug 572485

Do we have some more specs about what the buttons should look like?
What about :hover/:active/[checked]/[disabled]?

What about the round back button?

Azat, do you still want to work on that? I can try to take over if you want.

Comment 36

[Dão Gottwald [:dao]]

Some things to consider:

- Stephen appears to be going back and forth on permanent borders vs. borders on hover in his mockups for Windows. I tend to think that transient borders make the navigation toolbar visually simpler and are preferable for providing larger hit regions. They're also more common on Linux. To justify a switch, I think we'd need a bunch of pretty strong reasons.

- We're currently using stock icons for close OS integration. We can't really get more integrated than that. However, stock icons and the proposed button style don't really work together.

- The round back button lost most of its value since the back button is the only button over there. No need to make it more pronounced.

Based on these points, I don't think this bug should be pushed further at this time.

Comment 37

[Paul Rouget [:paul]]

(In reply to Dão Gottwald [:dao] from comment #36)
> Some things to consider:
> 
> - We're currently using stock icons for close OS integration. We can't
> really get more integrated than that. However, stock icons and the proposed
> button style don't really work together.

Maybe we should be a little less integrated to be a little more pretty?

> - The round back button lost most of its value since the back button is the
> only button over there. No need to make it more pronounced.

The round back button will make Firefox look more like Firefox.

Not sure this is the best place to talk about this. I started a thread on d-a-f:
https://groups.google.com/d/msg/mozilla.dev.apps.firefox/BZEvBh9pxYk/pn7Nmlz1erUJ

Comment 38

[Dão Gottwald [:dao]]

Define pretty? Why should pretty and integrated be opposites? On Ubuntu, the most prominent icon, that of the back button, is a straightforward orange arrow that appears to be done by a graphics designer. Looks pretty to me.

Comment 39

[Paul Rouget [:paul]]

(In reply to Dão Gottwald [:dao] from comment #38)
> Define pretty?

I think our designers express what is pretty by creating mockups. In all of the linux mockup I saw so far, we never get the stock icon, but the round icon.

> Why should pretty and integrated be opposites? On Ubuntu, the
> most prominent icon, that of the back button, is a straightforward orange
> arrow that appears to be done by a graphics designer. Looks pretty to me.

Here we are comparing a generic back icon to a button that has been specifically designed for Firefox.

The Ubuntu designers have to create icons that work everywhere in any condition. We have something more specific that has been build especially for Firefox. We have built a recognizable button for Firefox that is designed to work well with the conditional forward button and the URL bar.

Also, you get something decent on Ubuntu with the right theme. Switch to another Window Manager, another GTK theme or another distro, you'll get something different.

With the stock icon, we can't make sure that the user will get something solid and slick.

Comment 40

[Dão Gottwald [:dao]]

In the past, Ubuntu designers have in fact optimized the back/forward/stop/reload/home icons with Firefox in mind, as it's obviously an important application for them.

I realize there are many themes out there that any reasonable designer would consider ugly. But then nobody is forced to use those. Tastes differ. If people are happy with their themes, I don't see this as a problem.

Comment 41

[Paul Rouget [:paul]]

(In reply to Dão Gottwald [:dao] from comment #40)
> In the past, Ubuntu designers have in fact optimized the
> back/forward/stop/reload/home icons with Firefox in mind, as it's obviously
> an important application for them.

But they have to make it work for other applications too.
They are limited. We are not.

> I realize there are many themes out there that any reasonable designer would
> consider ugly. But then nobody is forced to use those. Tastes differ. If
> people are happy with their themes, I don't see this as a problem.

How do you know they will be happy with the Firefox back button?

As a Linux user, I don't choose my theme based on the look of the Firefox back button, but on how look my whole system. I am happy with the overall look, but not with some part of Firefox (back button, close button and add-tab button).

From my personal experience (and I'd be happy to gather some more serious data about this): I hear a lot of people complaining about the look of Firefox on Linux compared to Windows and Mac - and I believe that Linux users (and me first!) would prefer to have our Firefox-specific icons rather than the generic ones, whatever their theme is.

I will talk to the Ubuntu folks and see what they think.
They probably know better than me what's good for their users :)

Comment 42

[Andreas Nilsson (:andreasn)]

(In reply to Paul Rouget [:paul] from comment #39)
> (In reply to Dão Gottwald [:dao] from comment #38)
> > Define pretty?
> 
> I think our designers express what is pretty by creating mockups. In all of
> the linux mockup I saw so far, we never get the stock icon, but the round
> icon.
> 
> > Why should pretty and integrated be opposites? On Ubuntu, the
> > most prominent icon, that of the back button, is a straightforward orange
> > arrow that appears to be done by a graphics designer. Looks pretty to me.
> 
> Here we are comparing a generic back icon to a button that has been
> specifically designed for Firefox.
> 
> The Ubuntu designers have to create icons that work everywhere in any
> condition. We have something more specific that has been build especially
> for Firefox. We have built a recognizable button for Firefox that is
> designed to work well with the conditional forward button and the URL bar.

After discussions with Ubuntu designer John Lea we decided to go with simple monochrome icons for Thunderbird on Ubuntu (and for the icons in the message header in TB trunk, but that was mainly because I was unable to use -moz-image-region on svg's and would have ended up with a million files, see bug #665871). GNOME is also using more and more symbolic icons, and can provide an icon after being called [gtk-stock-name]-symbolic, that I think will fallback to non-symbolic icon, if the system is unable to provide that. I also think that is a GTK3 thing, so blocking on bug #627699

Comment 43

[Paul Rouget [:paul]]

(In reply to Andreas Nilsson (:andreasn) from comment #42)
> After discussions with Ubuntu designer John Lea we decided to go with simple
> monochrome icons for Thunderbird on Ubuntu (and for the icons in the message
> header in TB trunk, but that was mainly because I was unable to use
> -moz-image-region on svg's and would have ended up with a million files, see
> bug #665871).

Are these monochrome icons built-in? Are they used by other Ubuntu applications?

Comment 44

[Andreas Nilsson (:andreasn)]

(In reply to Paul Rouget [:paul] from comment #43)
> Are these monochrome icons built-in? Are they used by other Ubuntu
> applications?

No, they are specific to thunderbird. The symbolic icons that are possible with GTK3 are though (according to jimmac they should work in GTK2 apps too, but will miss out on the recoloring).
http://www.hadess.net/2010/04/symbolic-icons-support-in-gtk.html

Comment 45

[Francisco]

(In reply to Paul Rouget [:paul] from comment #41)

> From my personal experience (and I'd be happy to gather some more serious
> data about this): I hear a lot of people complaining about the look of
> Firefox on Linux compared to Windows and Mac[...]

And I'm one of them :D.

Just to add somthing: for KDE we have an extension called "Oxygen KDE" (http://kde-look.org/content/show.php?content=117962&forumpage=62) which not only fairly integrates a bit FF with Oxygen theme, but also lets you define the icons you want for back/forward: FF4 style, native style, etc.

Maybe implementing something similar won't be too difficult. Just a humble suggestion.

Comment 46

[Dão Gottwald [:dao]]

Stephen's latest mockups dropped the permanently visible button shapes.

A separate bug should be filed on the back button.