Bookmark folders in Personal Toolbar

RESOLVED INCOMPLETE

Status

()

Core
Widget: Gtk
RESOLVED INCOMPLETE
10 years ago
13 days ago

People

(Reporter: micmon, Assigned: Michael Ventnor)

Tracking

Trunk
mozilla1.9beta3
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007112105 Minefield/3.0b2pre

Firefox 3 on Linux currently displays folders in the personal toolbar like this:

[FolderIcon] BookmarkFolderName

Other browsers like GNOME's Epiphany, Apple's Safari and also Firefox 3 on the Mac it seems¹ don't display the folder icon and just add a small arrow behind the name of the folder. This is great, because it removes clutter from the main interface.

I have prototyped this approach in CSS and it mostly works. Only two problems:

## The dropmark arrow is not drawn using the native GTK style, which makes it look a bit strange. I guess this would be rather easy to fix, as the list view (Preferences->Applications) already draws such a toolkit arrow natively (-moz-appearance: treeheadersortarrow)

## There is something wrong with the way the button is drawn. First it looks ok, mouse-over is still ok. But when you press on it, it doesn't get pressed state but does not draw the button border at all. Now move the mouse a bit (one pixel) while still holding the mouse button and the button is drawn correctly.

## Also, the button should stay in "pressed" state diring the time the menu is open, even if the mouse is released. This does currently not work.

[1] https://bugzilla.mozilla.org/attachment.cgi?id=283998


Reproducible: Always
(Reporter)

Comment 1

10 years ago
Created attachment 289702 [details]
Screenshot

Screenshot of Epiphany's toolbar look and current FF3 with my CSS hack.
(Reporter)

Comment 2

10 years ago
Created attachment 289704 [details]
CSS Hack

This is my current try. You can test the hover/press problems with this.
(Reporter)

Comment 3

10 years ago
Created attachment 289706 [details]
Arrows in Back/Forward 

This is another place were those native icons are needed: besides the back/forward icons. So implementing this will be worth the work.
(Assignee)

Comment 4

10 years ago
I think we should keep this because Firefox users do associate a folder icon on a button with a dropdown. While native theming is of course a big priority to me, I also received concerns from people at MoFo about reaching a balance between nativeness and a cross-platform identity. I think a folder icon is one of those things that can contribute to a cross-platform identity.
(Reporter)

Comment 5

10 years ago
I completely understand the concern, Michael. But here is our reaoning: In fact, we first just replaced the icon by a new one, which was modelled after the default GNOME folder icon. This looked ok, but did not reflect any theme changes. Then we tried using the themed gtk-directory icon. The problem with this is that we don't have a way to draw an "open" state of this (gtk-open is useless here, because of the way it looks in most themes and GTK does not ship the "drag-accept" version of the folder). While testing we found that we don't need the open folder image for Places (the GNOME file manager Nautilus does not even display opened folders in trees) but on the Toolbar just having the closed folder looked weird.

Then we also found a screenshot¹ of the new Firefox 3 Mac OS theme, which does not use any icons on the personal toolbar. So with this, we also removed the icons (keeping just favicons, as those are unique and helpful) and made it match both native applications (Epiphany etc) and Firefox 3 on the Mac.

So, sure there is reason to have folder icons to help the cross platform identity, but if Mac Firefox also doesn't use this approach, I don't see a reason why Firefox on Linux should. Doesn't Vista also use these bars with just text and a "\/" in some places like its preferences manager?

[1] https://bugzilla.mozilla.org/attachment.cgi?id=283998
(Reporter)

Comment 6

10 years ago
Finally coming back to this one...

Issues 2 and 3 in the original report have been fixed in the meantime. This leaves the native look for the arrow to be implemented. As far as I can see, the toolbar and personal toolbar are the only places where the arrows are not using native look yet.

I have also seen a new screenshot of Firefox3 on the Mac¹, which shows the look of livemarks. The same look was already present in the addon Tango theme for FF2 and it worked great, so I think we should go for this, too.

To sum up:

[Folder icon][Container name] => [Container name][Droparrow]
[Livemark icon][Live-Container name] => [Live-Container name][Livemark icon]

Also, let's not add placeholder icons (currently: paper sheets) to bookmarks that do not have a favicon. The favicon is very useful to qucikly find a bookmark, but the placeholder icon kind of makes it harder again. 

These changes bring FF3/Linux closer to FF3/Mac and help making the interface look cleaner.

[1] https://bugzilla.mozilla.org/attachment.cgi?id=292516
I tend to agree that arrows instead of folders in the personal toolbar make the interface look cleaner. it also makes it clear that it's a dropdown, like the one in the right corner of the window for listing all open tabs.
There are also dropdown arrows in Places organizer (+ some icons that are clearly just noise though).
[comment #5]
>So with this, we also removed the
>icons (keeping just favicons, as those are unique and helpful) and made it
>match both native applications (Epiphany etc) and Firefox 3 on the Mac.

So just to clarify, we are talking about removing the folder icon, adding a native drop down arrow, and keeping favicons for the other bookmarks?  If so, I'm in favor of all of those changes.

I don't think this type of change effects overall product identity (which is more about things like the application icon, and having an iconic form for the navigation controls).  If this helps Firefox feel more native on linux, then I am all for it.
(Reporter)

Comment 9

10 years ago
I already replied to the email, but I want to explain it again here so that everyone is able to follow.

For folders, you summed it up correctly. It is the way apps like Epiphany show container elements on the toolbar, so yes, it improves the native look. It also helps the user not to mistake the folder icon for a favicon, so without much effort, it is clear that an element is a container.

For favicons, I think we should keep them for those bookmarks that actually have one. What we should drop is the usage of the placeholder icon for those pages that do not have a favicon. A real favicon can help the user find the correct bookmark, while the default image just adds complexity to the overall image the user sees, which is not helpful.

To better understand what this is all about, I have a screenshot which I will attach, showing the current look at the bottom, and the modified version (I have some CSS to "emulate" this look, so this is a real screenshot, too). Note that because containers and bookmarks have button look on linux, mouse-over even gives a very nice visual feedback.
(Reporter)

Comment 10

10 years ago
Created attachment 296713 [details]
Screenshot current (bottom) and proposed (top)
I'm in favor of the change, except for removing default favicons on bookmarks that don't have specialized favicons.  The reason I don't think removing the default favicons is a good idea is that I don't want to give the user the impression that there are three types of things in the toolbar, when in reality there are only two types of things.

To reduce the visual clutter of the default favicons, you could use a lighter and crisper image for the page (which would also match the tango style more). For instance, the icons Unstarred and Ask are very light and crisp:

http://andreasn.se/diverse/temp/firefox3/16x16/starPage.png
http://nemus.se/tango/fx3/im-16x16.png
(Reporter)

Comment 12

10 years ago
(In reply to comment #11)
> I'm in favor of the change, except for removing default favicons on bookmarks
> that don't have specialized favicons.  The reason I don't think removing the
> default favicons is a good idea is that I don't want to give the user the
> impression that there are three types of things in the toolbar, when 
> in reality there are only two types of things.

Ok, then let's try it this way. My current implementation of the dropdown arrows involves bitmaps though, so someone will need to code support for native look arrows first. Those are the same used in the menu etc, so the base code should be in place already. In the screenshot above you also see such arrows used for the dropdowns behind back and next and also the search engine selector.

The default favicon is not yet done in tango style, perhaps we can make it semi-transparent to make sure that it does not stick out much? Anyway, this can be replaced after the rest of the changes are in place.
>In the screenshot above you also see such arrows
>used for the dropdowns behind back and next and also the search engine
>selector.

Do you think we should use a different set of smaller drop down arrows for back and forward, but in the same style?  The big ones tend to overwhelm the navigation controls, and these drop down arrows aren't to commonly used. The large arrow also looks pretty heavy on the search engine selector (and I think we will want to add one to the site button as well).
(Reporter)

Comment 14

10 years ago
(In reply to comment #13)
> Do you think we should use a different set of smaller drop down arrows for back
> and forward, but in the same style?  The big ones tend to overwhelm the
> navigation controls, and these drop down arrows aren't to commonly used. The
> large arrow also looks pretty heavy on the search engine selector (and I think
> we will want to add one to the site button as well).

The style should be (gtk-engine) theme-specific. We currently have the implementation to fetch those for the arrows drawn for submenus. The size is actually scalable, so making them smaller is possible. 

In terms of GTK-likeness, the size and look is about 100% correct: it really looks like this in native apps. I'll attach a screenshot of the nautilus toolbar for you to compare.

(Reporter)

Comment 15

10 years ago
Created attachment 296835 [details]
Nautilus
>it really looks like this in native apps.

Yeah, I previously said I would err on the side of platform integration, so even though I don't really agree with the gtk-engine theme, let's go for it.

However for the search engine button and the site button (if it gets a drop down), since these controls are already unusual for the platform, I think we should use a scaled down version of the down arrow.

For completeness, can we use a native down arrow for the location bar drop down?  
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 17

10 years ago
(In reply to comment #16)
> However for the search engine button and the site button (if it gets a drop
> down), since these controls are already unusual for the platform, I think we
> should use a scaled down version of the down arrow.
Search engines work nice without the arrow IMHO. The only thing where it is really needed right now is for showing a new search engine, and I think that could be handled much better. See bug 405443, I still think this would make much more sense.

> For completeness, can we use a native down arrow for the location 
> bar drop down?  
There's more than just that coming for the location bar, see bug 405210.
(Assignee)

Comment 18

10 years ago
Created attachment 297451 [details] [diff] [review]
Patch

This implements the unused -moz-appearance: dualbutton-dropdown by making it draw just a native arrow pointing down.
Assignee: nobody → ventnor.bugzilla
Status: NEW → ASSIGNED
Attachment #297451 - Flags: superreview?(roc)
Attachment #297451 - Flags: review?(roc)
Why does it make sense to use "DUAL" here?
(Assignee)

Comment 20

10 years ago
(In reply to comment #19)
> Why does it make sense to use "DUAL" here?


a) Because it already existed
b) Because it relates to the back and forward buttons plus their menus (hence the dual) but we can still use it in other places since all we need is an arrow.

Should we rename NS_THEME_TOOLBAR_DUAL_BUTTON_DROPDOWN to NS_THEME_TOOLBAR_BUTTON_DROPDOWN_ARROW?
(Assignee)

Comment 22

10 years ago
Created attachment 297482 [details] [diff] [review]
Patch 2

Rename the properties.
Attachment #297451 - Attachment is obsolete: true
Attachment #297482 - Flags: superreview?(roc)
Attachment #297482 - Flags: review?(roc)
Attachment #297451 - Flags: superreview?(roc)
Attachment #297451 - Flags: review?(roc)
Attachment #297482 - Flags: superreview?(roc)
Attachment #297482 - Flags: superreview+
Attachment #297482 - Flags: review?(roc)
Attachment #297482 - Flags: review+
Component: OS Integration → Widget: Gtk
Product: Firefox → Core
QA Contact: os.integration → gtk
Version: unspecified → Trunk
(Assignee)

Comment 23

10 years ago
Comment on attachment 297482 [details] [diff] [review]
Patch 2

Drivers, you know the song and dance. This is another quite small patch to significantly improve our goal of Linux nativeness.
Attachment #297482 - Flags: approval1.9?

Updated

10 years ago
Attachment #297482 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
Checking in widget/src/gtk2/gtk2drawing.c;
/cvsroot/mozilla/widget/src/gtk2/gtk2drawing.c,v  <--  gtk2drawing.c
new revision: 1.69; previous revision: 1.68
done
Checking in widget/src/gtk2/gtkdrawing.h;
/cvsroot/mozilla/widget/src/gtk2/gtkdrawing.h,v  <--  gtkdrawing.h
new revision: 1.51; previous revision: 1.50
done
Checking in widget/src/gtk2/nsNativeThemeGTK.cpp;
/cvsroot/mozilla/widget/src/gtk2/nsNativeThemeGTK.cpp,v  <--  nsNativeThemeGTK.cpp
new revision: 1.138; previous revision: 1.137
done
Checking in browser/themes/gnomestripe/browser/browser.css;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v  <--  browser.css
new revision: 1.153; previous revision: 1.152
done
Checking in gfx/public/nsThemeConstants.h;
/cvsroot/mozilla/gfx/public/nsThemeConstants.h,v  <--  nsThemeConstants.h
new revision: 1.24; previous revision: 1.23
done
Checking in layout/style/nsCSSKeywordList.h;
/cvsroot/mozilla/layout/style/nsCSSKeywordList.h,v  <--  nsCSSKeywordList.h
new revision: 3.98; previous revision: 3.97
done
Checking in layout/style/nsCSSProps.cpp;
/cvsroot/mozilla/layout/style/nsCSSProps.cpp,v  <--  nsCSSProps.cpp
new revision: 3.158; previous revision: 3.157
done
Checking in toolkit/themes/gnomestripe/global/toolbarbutton.css;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/toolbarbutton.css,v  <--  toolbarbutton.css
new revision: 1.16; previous revision: 1.15
done
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9 M11

Comment 25

10 years ago
I'm all for Desktop integration but I don't like that particular change.
My bookmarks toolbar is composed almost exclusively of folders and it now looks like some 15 years old UI.

Folders within those top level folders still have their icon so it makes the bar look even weirder.

The only Gnome app (that I know of) doing that is indeed Epiphany. I don't consider that's enough to be a widely spread style. As for to be closer to Mac, I thought all this OS integration work during the last few months was exactly the opposite, i.e. stop trying to have a common look between platforms.

Please, consider bringing the folder icons back. 
(Reporter)

Comment 26

10 years ago
(In reply to comment #25)
> I'm all for Desktop integration but I don't like that particular change.
I agree that the change takes some getting used to, but...

> My bookmarks toolbar is composed almost exclusively of folders and it 
> now looks like some 15 years old UI.
...this would be the best example where the new style is an improvement, because it takes away complexity from the UI and makes it look cleaner.

> The only Gnome app (that I know of) doing that is indeed Epiphany. I don't
> consider that's enough to be a widely spread style. 
The droparrow in toolbars in THE commonly used symbol for drop menus, it's certainly not something just epiphany came up with...

> As for to be closer to Mac, I thought all this OS integration work 
> during the last few months was exactly the opposite
Sure, the change was not made to look like Mac, but the fact that the Mac
builds already don't use a given look means that it makes no sense to keep
it on Linux for the sake of cross-platform identity.
Depends on: 413294
-1 from me, removing usability from default theme
Depends on: 414151
Depends on: 414156
In bug 417210 comment #11 Michael Monreal writes:

>Just to sum up the previous discussion about this:
>
>- FF2 had "folder icon + label"
>- we (GTK/Tango) didn't like this and requested "label + droparrow" instead
>- IIRC we had this for a while, then someone requested to re-add the folder
>icons
>
>IMHO folder "folder icon + label" is still the worst choice because this way a
>bookmark folder looks exactly like a bookmark.

I agree that label + drop down is the best way to go, so reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 29

13 days ago
No longer relevant with Photon theme.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago13 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.