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

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

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

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

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.

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

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.

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.

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

(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).

(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.

>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?

(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.

This implements the unused -moz-appearance: dualbutton-dropdown by making it draw just a native arrow pointing down.

Why does it make sense to use "DUAL" here?

(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?

Rename the properties.

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.

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

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.

(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.

-1 from me, removing usability from default theme

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.

No longer relevant with Photon theme.