Closed Bug 381206 Opened 17 years ago Closed 16 years ago

Tango Style theme for better Linux UI integration

Categories

(Firefox :: Theme, enhancement)

All
Linux
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 3

People

(Reporter: sgarrity, Assigned: andreasn)

References

(Depends on 1 open bug, )

Details

Attachments

(9 files, 4 obsolete files)

I would like to propose a move to the Tango [1] icon style for the Linux 
version of Firefox 3.

The Tango project exists to help create a consistent graphical user 
interface experience for free and Open Source software."

Many people think of the Tango project (http://tango.freedesktop.org/) 
as an icon set. However, Tango is much broader than this. Rather than a 
single icons set, Tango is a set of visual guidelines to help anyone 
create a set of icons that can work well together.

Projects that have recently adopted the Tango style include the Gimp 
(upcoming version 2.4), Pidgin (aka Gaim), and Scribus. Work is under 
way for Inkscape, OpenOffice.org, Blender, and plenty of other projects.

Perhaps most significantly, the Gnome desktop, including the significant 
Gtk-stock icon set has recently moved to the Tango style. Here's a 
sample: http://www.andreasn.se/blog/?p=45

You can try out Tango in Firefox using the Tango theme: 
https://addons.mozilla.org/en-US/firefox/addon/1565

Keep in mind, though, that we are not limited to that exact icon set. We 
could develop a new set of icons that match the metaphors of the 
Winstripe/Pinstripe themes, but redrawn to better tie in with the Tango 
style (and hence the rest of the Linux desktop).

While most of the integration work I have seen for Firefox on the Linux 
desktop has focused on Gnome, it is worth noting that the visual style 
of Tango was also designed to fit in relatively well in the KDE environment.

Andreas Nilssen, one of the primary icon designers/illustrators with the 
Tango project has expressed a keen interest in helping out with Tango in 
Firefox 3. He's willing to redraw icons, and offer them in whatever 
license is necessary for inclusion upstream in Firefox.

Also note that everything I have said here also applies to Thunderbird.

I'm looking for some direction on who in particular I should speak to 
about this - who is driving the visual style of the UI for Firefox 3, 
and who is driving the Linux aspect in particular.
Flags: blocking-firefox3?
Severity: normal → enhancement
Target Milestone: Firefox 3 alpha1 → Firefox 3
This isn't a blocker, but will be seriously considered as we look at theme refresh for Firefox 3 (I appear, once again, to be on the hook for that, as I'm a big ol' sucker)
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
Attached image Tango Toolbar.png (obsolete) —
This is a full toolbar palette using tweaked and mix-and-matched Tango icons. It can simply replace the Toolbar.png in browser/themes/winstripe/browser so you can try it out immediately.

Tango icons are licensed under the Creative Commons Attribution-Share Alike 2.5 Generic license
http://creativecommons.org/licenses/by-sa/2.5/
which I think is OK... isn't it the same license used for those FAMFAMFAM icons?

Beltzner and Faaborg, I'd like your feedback.
Attachment #284546 - Flags: ui-review?(beltzner)
Attached image Tango Options.png (obsolete) —
This is for the pref window.

Another thing I should mention, Tango icons typically go for the plastic-rather-than-shiny route, so this would also be very suitable for the Windows XP theme as well as Linux.
Attachment #284548 - Flags: ui-review?(beltzner)
Attached image Tango pageInfo.png (obsolete) —
Beltzner, since you blogged about this I really, really want your feedback and suggestions.
Attachment #284569 - Flags: ui-review?(beltzner)
Blocks: 399398
Michael: unsure if we can use these cc-by-sa licensed icons in the install, plus they could use some pixel-hinting, currently look a bit blurry. 
Steven: what license are we going for, gpl-mpl-lgpl?
It would be a shame if we couldn't use that license. I'm no good at all at making icons from scratch so the work will have to go to someone else. I'm a coder, not a graphics designer.

(To tell you the truth, I have so much more on my plate already that is a higher priority than this, so someone else may have to pick this bug up anyway :( )
Beltzner, can you let us know what license the artwork needs to have to get committed?
Note that the disabled states should only be needed for Back, Forward, Stop, Copy, Paste and Cut. The rest can be left blank, I think.
(In reply to comment #7)
> Michael: unsure if we can use these cc-by-sa licensed icons in the install,
> plus they could use some pixel-hinting, currently look a bit blurry. 
> Steven: what license are we going for, gpl-mpl-lgpl?
gpl-mpl-lgpl is always a safe bet with our codebase.
Right, that means all icons must be drawn from scratch then.
Should be pretty easy as we have most of the metaphors ready though.
Gerv, please comment on whether Firefox's default theme has to be tri-licensed or whether we can use icons under the "Creative Commons Attribution-Share Alike 2.5 Generic" license (http://creativecommons.org/licenses/by-sa/2.5/).
Stuff we ship has to be tri-licensed, or under some license compatible with all three parts (e.g. a BSD-like licence). Or, of course, it could be quad-licensed - MPL/LGPL/GPL/CC-BY-SA, or any more complicated licensing scheme you like which includes our three.

Note that CC-BY-SA is incompatible with the GPL. I haven't read the whole bug, but if some of the Tango icons are CC-BY-SA, then GPL(-only) apps won't be able to use them. Which would rather defeat the point. I wonder if they are aware of that?

Gerv
(In reply to comment #12)
> Right, that means all icons must be drawn from scratch then.

Not necessarily.  Firefox uses only a small subset of the Tango icons, and these can be re-licensed easily.

It is easy to find out who is the author (copyright owner) of each of these icons (probably you or jimmac).  If the authors agree to allow Firefox to use these icons with the tri-license, then the problem is solved and there is no need to redraw anything.  And then Firefox 3 could include this theme immediately for all Linux users (and Solaris, and whatever other platform uses GTK+).
(In reply to comment #14)
> Note that CC-BY-SA is incompatible with the GPL. I haven't read the whole bug,
> but if some of the Tango icons are CC-BY-SA, then GPL(-only) apps won't be able
> to use them. Which would rather defeat the point. I wonder if they are aware of
> that?

This is a bit off-topic for this bug report so I'll try to keep this short: CC-BY-SA is only incompatible with the GPL if both are somehow linked to each other.  This is not the case here and this is not a problem for almost all GPL applications using the CC-BY-SA icons, because they are independent of each other: the application can use other icons, and the icons can be used in other applications.  The simple fact of bundling a GPL application with icons or other contents covered by a different license does not make the other stuff subject to the GPL.  Bundling is explicitly allowed by the GPL.
IMHO we don't really need a theme that provides yet another set of tango icons, but instead we should use the icons already provided in the desktop icon themes. Firefox3 has 99% of the needed infrastructure in place. For example:

toolbar[iconsize="small"] #back-button .toolbarbutton-icon {
  list-style-image: url(moz-icon://stock/go-previous?size=menu) !important;
  -moz-image-region: rect(0px 16px 16px 0px);
}

Sure, this could be even easier by providing a "theme-image" property which would load a single icon instead an icon list (and thus wouldn't require -moz-image-region).

The only problem I ran into was the disabled states of icons on buttons: right now there is no way to simulate that with Mozilla, but the need to provide grayed versions of the icon theme icons would defeat the purpose.

So, what about adding this functionality to Firefox3 and use icons from the active GNOME/Xfce/KDE4/... icon theme. We would still need to fix a lot of CSS for nice "native" look (tabs etc) but at least we wouldn't net yet another set of icons and Firefox would look totally native for free.
(In reply to comment #17)
> IMHO we don't really need a theme that provides yet another set of tango icons,
> but instead we should use the icons already provided in the desktop icon
> themes. Firefox3 has 99% of the needed infrastructure in place. For example:

Please move this suggestion to a separate bug report.  Let's keep this one focused on providing a standard Firefox theme based on Tango icons.

The idea of using the icons provided by the freedesktop specs makes a lot of sense and has been suggested by several people, but this should really by handled in a separate bug report because several problems need to be addressed:
- how to refer to the appropriate icons?
- how to provide grayed out versions of these icons?
- what happens if no suitable icons can be found?
The last point is the most important one: we cannot be sure that the Linux desktop in which Firefox is running will have anything that follows the icon naming spec.  Even if almost all modern distros follow the freedesktop standards, this is not something that you can really rely on for all deployments of Firefox.  So in any case, it would be necessary to provide a set of icons as fallback (shipped with Firefox) and the set of Tango icons proposed here seems to be the best solution.
(In reply to comment #16)
> This is a bit off-topic for this bug report so I'll try to keep this short:
> CC-BY-SA is only incompatible with the GPL if both are somehow linked to each
> other.  This is not the case here and this is not a problem for almost all GPL
> applications using the CC-BY-SA icons, because they are independent of each
> other: the application can use other icons, and the icons can be used in other
> applications.  The simple fact of bundling a GPL application with icons or
> other contents covered by a different license does not make the other stuff
> subject to the GPL.  Bundling is explicitly allowed by the GPL.

GPLv2 allows aggregation (the word "bundling" does not appear):

"In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License."

It is far from clear that this applies to icons shipped inside the Firefox binary installer. If anything which could be replaced (e.g. icons) is "merely aggregated", then the GPL would be the same as the LGPL. Does the Tango project have a legal opinion from a lawyer on this matter?

Gerv
My idea was to draw another set, as relicensing icons from tango-icon-theme is not possible and quad-license sounds even worse than tri-license. Plus, it's the style guidelines that matter, not the icon set.
Therefore I agree with Raphael. Although any patches for picking up icons from the selected would be cool (and it would make HighContrast work, yay!) I will first and foremost focus on drawing the icons.
gnome-icon-theme contains many of the same icons, licensed under GPL.
Michael have a nice idea regarding picking up more stuff from gtk stock: https://bugzilla.mozilla.org/show_bug.cgi?id=397373
Thanks for linking the other bug Andreas ;)

Well, Raphael is right about the problems. But let's see:

- how to refer to the appropriate icons?
This is possible now using the syntax I showed in comment #17 but I am sure that improving this would not be to hard.

- how to provide grayed out versions of these icons?
This would be the hard part, code wise. But again I don't think it would be much of a problem. We mostly only need this for 3 or 4 buttons and transforming a 16x16 or 24x24 icon to have less saturation should not be a big CPU hit at all.

- what happens if no suitable icons can be found?
Well, what does FF3 do on FTP listings currently, if it doesn't find any external icons (FTP listings pull a lot of icons from the icon theme: go-up, folder, mimetype icons...). I haven't checked this, but I suppose it will use it's own set of icons from the theme as a fallback? IMHO we should do the same for the rest of the interface icons: check for desktop theme icon, and fall back to the firefox theme's version in case the desktop doesn't provide a matching icon.

We could then have two themes for FF3 on linux: one using all the "fallback" icons, e.g. the new set of icons Andreas has proposed to do. The second would be the same CSS wise, but use desktop icons if from the current theme if available.
Bug 397373 has been fixed so use of GTK stock icons is now feasible. There is now but one problem we have left: there aren't enough stock icons for every function in the toolbar, let alone any of the "graphical tabs" on the preferences window, page info or addons mgr.

When I have time I'll do what I can as a preliminary (if anyone else wants to though that would be even better) but unless someone experienced with creating icons can fill in the gaps and give them to Mozilla Co with an acceptable license (which is what is stopping us from borrowing the CC-SA'd Tango) we'll have a horribly inconsistent icon theme.

Surely someone here is good at making icons?
(In reply to comment #24)
> Surely someone here is good at making icons?

See comment 0:
> Andreas Nilssen, one of the primary icon designers/illustrators with the 
> Tango project has expressed a keen interest in helping out with Tango in 
> Firefox 3. He's willing to redraw icons, and offer them in whatever 
> license is necessary for inclusion upstream in Firefox.

Andreas has already commented in this bug, see e.g. comment 20.
And instead of recreating icons from scratch, he can simply relicense those icons he made himself for Tango, or ask one of the other authors (like jimmac) to do that, see comment 15.
I don't think re-licensing will be an option, but that's not really a problem. Andreas is working on a complete set of icons for Firefox 3, which can then be licensed for use of Mozilla (tri-license or whatever).

Michael is right in saying that the freedesktop spec (and icon themes based on that) don't cover all the icons (like "feeds" or "extensions") but most of the notable icons are available in every icon theme (navigation icons, home, etc).

We just need to agree here... do we want to support the use of desktop icon themes, at least optionally? If yes, should we implement it as a second default theme (one using all of Andreas' new icons, one using themed icons and falling back on Andreas' icons for the missing ones) or can we provide some sort of preferences switch, like "[x] Use icons from the desktop theme" and just override the active Firefox theme's icons with the ones from the desktop theme?
Cool. BTW this is taking me a much shorter time than I expected, I've pretty much exhausted our use of stock icons in my own tree.

Andreas, I really appreciate you doing this. The icons that are covered by GTK's stock API are: back, forward, refresh, stop, home, print, cut, copy, paste (so I don't need images for those). The rest need images that can just "fit in". I don't know if that's possible, but I'm not the expert around here :-)
This will give some of the buttons stock icons as defined by your GTK theme. While I want to wait for Andreas to finish his images before I ask for any reviews, I'll just post what I have here for now. Feedback welcome.
Attachment #284546 - Attachment is obsolete: true
Attachment #284548 - Attachment is obsolete: true
Attachment #284569 - Attachment is obsolete: true
Attachment #284546 - Flags: ui-review?(beltzner)
Attachment #284548 - Flags: ui-review?(beltzner)
Attachment #284569 - Flags: ui-review?(beltzner)
Attached image Screenshot
A screenshot of the patch in action. I'm a KDE user so the screenshot isn't a very good demo, but it will adjust to your theme.
Michael, I've done something similar (using overrides in userChrome.css). You can also use non-gtk icons form the spec (things like tab-new or window-new).

This leads me to the question, how does FF3 look for these icons? Is there a special case for icons shipped with GTK? For example, you are using "gtk-go-back", I currently use the spec name "go-previous". Will "gtk-go-back" work even without any icon theme and pull the compiled in icons from GTK? I'm not sure about this.

And finally: is the current plan to use this form of theming in the default theme, with no option to just use the fallback (Andreas') icons?
(In reply to comment #29)
> Created an attachment (id=284834) [details]
> 
> I'm a KDE user so the screenshot isn't a very good demo

It actually looks great. The main question is how it would work together with custom icons that Firefox would ship with.
Michi, currently we don't have a dependency on gnome-icon-theme so I'm trying to avoid using non-gtk icons where possible (I don't have a say on what Moz's dependencies are).

>And finally: is the current plan to use this form of theming in the default
>theme, with no option to just use the fallback (Andreas') icons?

That was my original intention, yes, if stock icons were available for a particular button. But since themes are always different and there aren't enough stock icons for everything, there could be major inconsistency between the UI if I went with that option.

Maybe it would indeed be best if we just used Andreas' icons for everything...
(In reply to comment #27)
>The icons that are covered by
> GTK's stock API are: back, forward, refresh, stop, home, print, cut, copy,
> paste (so I don't need images for those).

Andreas, forget I said that. I'd love to see your proposals for those icons just in case use of stock doesn't work out.

Michael: Well, FF3 is already using non-GTK icons from desktop themes, for example the audio/video, archive or picture mime icons in FTP listings (can also be seen in the preferences dialog -> Applications). I guess Firefox uses fallbacks from it's own theme in case those icons are not available in the theme. My question was more a general one: can firefox find an icon named "gtk-go-back" if there is no such icon in any theme? Your screenshot shows the icons from the default GNOME theme, not GTK ones...

IMHO the default should be Andreas' new icons only, but perhaps an option could activate another CSS sheet which uses themed icons? Would that be possible to implement?
(In reply to comment #34)
> Michael: Well, FF3 is already using non-GTK icons from desktop themes, for
> example the audio/video, archive or picture mime icons in FTP listings (can
> also be seen in the preferences dialog -> Applications). I guess Firefox uses
> fallbacks from it's own theme in case those icons are not available in the
> theme. My question was more a general one: can firefox find an icon named
> "gtk-go-back" if there is no such icon in any theme? Your screenshot shows the
> icons from the default GNOME theme, not GTK ones...

Yeah, I uninstalled gnome-icon-theme and now I have more rough icons. Also, the arrows are now green. But at least its not nothing at all so this does mean that GTK has fallback icons.

> IMHO the default should be Andreas' new icons only, but perhaps an option could
> activate another CSS sheet which uses themed icons? Would that be possible to
> implement?

I wouldn't know how to do that, and its more work than I'd like to take on...
Wouldn't it be better to just have a third-party theme which used stock icons?
Ok, glad that it even works without the theme.

IMHO getting the native icon theming right doesn't fit into the timeframe for FF3 anymore, so I would go for Andreas' icons and fix the CSS stuff to better fit Linux. We could then experiment with the native icon stuff in a 3rd party theme and see how it works and perhaps put it into Firefox 3.5 or whatever will be the next release.

Did the state=disabled patch make it into the latest nightly btw?
(In reply to comment #36)
> Did the state=disabled patch make it into the latest nightly btw?

It should have, yes. It was checked in on Oct 13th.

I haven't been commenting here because other people can and have been answering questions faster than I can find the answers, but I'm cheering from the sidelines!
Ok I can confirm that the disabled state works in the latest daily build now. Awesome stuff.

Anyone feeling like stepping up for the CSS hacking we will need to make FF3 look more native on linux? Tabs need fixing (should use the GTK style), also it would be great to have the URL entry finally look like a GTK entry, as focus rings are now supported.
Bug 353785 is for a native tab bar. I almost have a patch for that which I'll attach soon.
>IMHO getting the native icon theming right doesn't fit into the timeframe for
>FF3 anymore...perhaps put it into Firefox 3.5 or whatever will
>be the next release.

I understand that there is no time to implement native icons fetching for FF3.
If this is true there is no sense (from my point of view) to waste a time working on Tango icons. 

First, because icons theme is just a top of the iceberg (the main problems are far more deep). Tango icon theme does not feet KDE at all. KDE4 will have oxygen icons as default icon theme. Please check 
http://www.oxygen-icons.org/
As you can see this is something absolutely different from the Tango icon theme.
If you want to have more "native" icons you need to use really native icons from both Gmome and KDE.

Second, just adding some different icons will not make FF look more native. For example, if you use KDE you can make your menu bar to be MAC OSX like. I mean to have it on the top of the desktop window and separate from the actual application. You need to have native menu bar for different platforms. You need to have other native controls.

When I say "native" I mean really native windows or qt4 or gtk+ or any other widgets. Something similar to what the openoffice 2.x has. You need to remember that despite of all the ubuntu + gnome noise Linux is not limited to this. KDE 4 currently is under active development and it brings a lot of new and amazing apps and technologies Gnome can't even dream about (in it's current state I mean). And you need to make FF more Linux friendly (for both KDE and Gnome) but not just more friendly to some specific Gnome theme.

Thanks.
Firefox uses GTK widgets on Linux, as does Gnome.  It does not use QT widgets as KDE does.  Without doing this (and this wouldn't happen for Firefox 3 due to the lateness in the release cycle, even if someone stepped up to do it -- patches would and have been welcome in the past to implement this, but nobody's stepped up to really own and maintain the code), KDE-style icons are lipstick on a pig, to be blunt.  Someone needs to really want to see a KDE-style Firefox, with the will to actively maintain QT widget code and follow up on style deviations for it to make sense to make one step which would (from all appearances) quickly bitrot after landing.

That said, if someone really made the effort and created a patch for a new KDE-style theme, selectable at build time, I don't think the patch would be refused.  It's entirely out of scope for this bug.  (Note "Tango Style theme".)

<rant followup="outside-bug">
Linux's inability to get consistency on just about anything, including graphical styles, is a big part of the reason it's not been hugely successful, in my opinion.
</rant>
Andreas/Raphael(?)/any other Linux icon designers:

If I have specific comments on the icons proposed in attachments or patches here, where is the best place to post those comments so that the icon designers can read them and be able to take them into consideration?  This bug's chatty enough that it's probably not a great place, given that you'd have to wade through so many comments to find them (and also given that it's more targeted at integrating the icons than at designing them, particularly as they're already designed).  Would the mozilla.dev.platforms.linux newsgroup be a place people would be comfortable using?
Serhiy: judging from oxygen svn [1] I think oxygen-style and tango-style actually don't differ that much, but yes, all of our stupid micro-branding is crap for ISV's.
Our alternative to these tango icons are the Vista icons, do you suggest we use those instead?

1. http://people.freedesktop.org/~jimmac/icons/#oxygen
Jeff: yeah, mozilla.dev.platforms.linux sounds good to me. Any good irc channels we can use? A bunch of us hang out in #tango on irc.freenode.net
We've set up a progress status page at http://tango.freedesktop.org/Firefox
Andreas, please remove the padding from the Go arrow, as in attachment 282934 [details].
Assignee: nobody → nisses.mail
Status: NEW → ASSIGNED
Attached image go-arrow, fixed
Dão: Fixed. What is the order here? [normal][hover][disabled][hit] ?
(In reply to comment #47)
> What is the order here? [normal][hover][disabled][hit] ?

Yes, although 'disabled' is not needed. We should remove it as a follow-up.
Lets get some activity here.

Now that Gnomestripe has basically been forked, its easy to make the toolbar use stock icons when GTK provides them. I can't go further with the use of stock icons though, because we cannot guarantee that the user's theme implements all of Freedesktop's spec.

But we do have a dependency on GTK+ and not only can GTK+ read the GNOME icon theme, but it provides a built-in failsafe one in case the user doesn't have one installed. This patch uses as many GTK+ icons as it can.

mconnor is likely already overloaded so if anyone can suggest a reviewer with more time on his hands that would be excellent.

Those Tango icons are looking nice, BTW.
Attachment #284833 - Attachment is obsolete: true
Attachment #287984 - Flags: review?(mconnor)
So I guess gnomestripe will be "freed" in a day or two and after that Michael Ventnor's patch can go in. But how do we work from there? Do you aim to keep gnomestripe mostly unchanged and just replace the current image maps with new (tango) ones? Or are we going to reorganize things a bit? Can we assume that custom themes will stop being cross-platform or do we need to keep a common scheme?

Also, once these things are clarified, how will we get the Tango artwork in? Does this have to be handled using bugzilla for every new image map?
A few suggestions on various platform-specific changes that can happen in gnomestripe:

  * Icons for important icons in the menus (almost only icons in the toolbar + a few special other ones)
  * Menu spacing
  * Drop the frames in the grouping of widgets and make the header labels bold, both mimicking GTK+
  * Tweak the treeviews so that the expader widget looks like the GTK+ triangle (if that hasn't been adjusted to pull in the native one already)
  * Make sure the tabs not only look native, but have native-like padding
  * Make the statusbar look like status bars in GTK+ applications (without the inset boxes)
  * Adjust the < Previous Next > in the search back to look more like other GTK+ applications.
  * Change the spacing for various other widgets to be more consistent with the platform

These were a few of the CSS changes I made previously (along with Nico Kaiser, Stephen Garrity, Andreas Nilsson, etc.) in the various desktop integration themes for Firefox (Tango, Industrial, GNOME, and Tangerine).  There were more little tweaks; these were just the ones I could remember of the top of my head this evening.
Whiteboard: [wanted-firefox3] → [wanted-firefox3][has patch][needs review mconnor]
Garrett, 

I think this is all very reasonable... a few tweaks that can make a big difference in terms of platform integration. A few comments:

- treeviews expaders are being worked on still (#118312)
- I already filed a bug for tab size (what else is wrong with those?) (#402952)
- I also filed a bug to swap the order of next and previous in the find bar... having the native gtk "<" and ">" signs would be great, too. 

Also, how should we work on this, file separate bugs for each one or just fix the CSS and commit the changes at some point?
Comment on attachment 287984 [details] [diff] [review]
[checked in] Native GTK icons on toolbar

r=me, NPTOB, should just land
Attachment #287984 - Flags: review?(mconnor) → review+
Keywords: checkin-needed
Whiteboard: [wanted-firefox3][has patch][needs review mconnor] → [wanted-firefox3][has patch][has review]
Version: unspecified → Trunk
Just to note that this patch only partly fixes this bug so don't mark this bug fixed when its checked in.
(In reply to comment #49)
> Created an attachment (id=287984) [details]
> Native GTK icons on toolbar
> 
> Lets get some activity here.
> 
> Now that Gnomestripe has basically been forked, its easy to make the toolbar
> use stock icons when GTK provides them. I can't go further with the use of
> stock icons though, because we cannot guarantee that the user's theme
> implements all of Freedesktop's spec.
> 
> But we do have a dependency on GTK+ and not only can GTK+ read the GNOME icon
> theme, but it provides a built-in failsafe one in case the user doesn't have
> one installed. This patch uses as many GTK+ icons as it can.
> 
> mconnor is likely already overloaded so if anyone can suggest a reviewer with
> more time on his hands that would be excellent.
> 
> Those Tango icons are looking nice, BTW.
> 

I'm sorry to bother, but how do I actually use the patch? And what version of FF does it work in?
(In reply to comment #55)
> I'm sorry to bother, but how do I actually use the patch? And what version of
> FF does it work in?
> 

It won't work yet because Gnomestripe (the name for the Firefox 3 Linux theme) is still disabled on the mainstream. You'll need to wait until Gnomestripe is enabled, which will happen when everyone thinks the theme is good enough for beta use.

This will happen for Firefox 3.
Attachment #287984 - Flags: approval1.9+
Comment on attachment 287984 [details] [diff] [review]
[checked in] Native GTK icons on toolbar

mozilla/browser/themes/gnomestripe/browser/browser.css 1.134
Attachment #287984 - Attachment is obsolete: true
Keywords: checkin-needed
Whiteboard: [wanted-firefox3][has patch][has review] → [wanted-firefox3]
Attachment #287984 - Attachment description: Native GTK icons on toolbar → [checked in] Native GTK icons on toolbar
Attachment #287984 - Attachment is obsolete: false
This is around a ~3% Txul hit (probably due to having to load separate images) but it's more than offset by the other gnomestripe improvements, so I think we're probably okay on that front. :)
To Thomas Osborn: Gnomestripe is enabled now. And since this patch has been merged, you don't need to apply it manually - you just have to update from CVS.
Uuh, nice. My Minefield now looks nicely compact when small icons are enabled. The stock icons from my GTK theme are used, now I've got to look for a theme with the Tango icons, I like them a bit better.

The only minor nitpick is that the close buttons of the tabs don't get highlighted when you mouse over them. They stay the same dark gray (which looks somewhat between inactive and active). I'm not sure whether that icon comes from GTK/Gnome or from Minefield.
Right... can the close icon on tabs have the default button style on mouse-over? This is how native GTK apps display this...
Attached image Screenshot
I just built minefield from the newly gnomestripe-enabled CVS trunk: icons are no longer displayed in the navigation toolbar (see enclosed screenshot). 

Trying to access an icon manually via the address bar, I discovered that, according to my build, "the protocol (moz-icon) isn't associated with any program", although the icon decoder interface in libpr0n seems to have been compiled-in.

My configuration is extremely plain (--enable-application=browser, --disable-airbag, --prefix=$HOME/mozilla, that's it), and my box is a pretty standard Linux x86_64 gtk2+ box. what did I do wrong? Can you shed any light on this?
(In reply to comment #62)
> I just built minefield from the newly gnomestripe-enabled CVS trunk: icons are
> no longer displayed in the navigation toolbar (see enclosed screenshot). 

That's bug 402742.
You have to build with --enable-gnomeui to have the icons.
(In reply to comment #64)
> You have to build with --enable-gnomeui to have the icons.
> 

Can you give me step by step instructions on how to install with that option / where to get the source?
The new theming depends on gnomeui's gnome_icon_(,theme_)lookup(): would it be possible to provide a graceful fallback to the former interface for those using a gtk2+/cairo build without having gnome installed, either at runtime or compilation time?

I am not debating the choice you guys made to depend on libgnomeui (bug 402742 is likely a better place for this), but right now the navigation bars appears seriously broken for everyone without libgnomeui.
The new theming doesn't use gnome_icon_lookup, it uses gtk_widget_render_icon. I'm not sure why not using libgnomeui doesn't work, when I was using KDE and didn't have an icon theme installed this would just use very old-looking fallback icons. Maybe Kubuntu 7.04 had libgnomeui installed anyway...?
(In reply to comment #67)
> The new theming doesn't use gnome_icon_lookup, it uses gtk_widget_render_icon.

Mmh... I am not very familiar with mozilla internals, but looking at libpr0n/decoders/icon/gtk/nsIconChannel.cpp, it does look like the moz-icon protocol (which my build did not to support, see comment #62) does require the gnome_icon_*_lookup() calls from libgnomeui: as soon as I don't have it, I end up with no handler for moz-icon:// URI, and missing icons in the navigation bar.

I can confirm that once you install the gnome libs, the problem goes away.
Why not just add relevant Tango icons to the source and we can kick just another useless dependency.
(In reply to comment #68)
> (In reply to comment #67)
> > The new theming doesn't use gnome_icon_lookup, it uses gtk_widget_render_icon.
> 
> Mmh... I am not very familiar with mozilla internals, but looking at
> libpr0n/decoders/icon/gtk/nsIconChannel.cpp, it does look like the moz-icon
> protocol (which my build did not to support, see comment #62) does require the
> gnome_icon_*_lookup() calls from libgnomeui: as soon as I don't have it, I end
> up with no handler for moz-icon:// URI, and missing icons in the navigation
> bar.
> 
> I can confirm that once you install the gnome libs, the problem goes away.
> 

Only for file type icons. But when a stock icon is requested it uses the GTK function rather than a GNOME function. Why on earth it doesn't work I have no idea, I had no problems using this on KDE without a GNOME icon theme installed.

Note that Help and the Places Organizer are still using the old icons.
(In reply to comment #70)
> > [...]it does look like the moz-icon protocol does require the 
> > gnome_icon_*_lookup() calls from libgnomeui[...]
> 
> Only for file type icons. But when a stock icon is requested it uses the GTK
> function rather than a GNOME function. Why on earth it doesn't work I have no
> idea, I had no problems using this on KDE without a GNOME icon theme
> installed.

Thanks for the rectification. Looking at the makefile, the "gtk-specific" code from libpr0n icon decoder is only compiled in when gnomeui is present. The nsIconChannel code is already pretty much decoupled internally, so it shouldn't be too difficult to fix.
Please have a look at bug 404530, which lists a few more places where we can use GTK icons. I also just filed bug 405163, which has the first tango icons that are ready to include (small and large toolbar).

As a reference, the following bugs are more or less related to making our integration work a success: 404974, 404880, 404617, 404829, 404825, 404816, 404771, 404751, 404614, 404514, 404512, 404508, 404498, 404398, 404352, 404254, 403028, 402952, 404495, 404493, 399545.
Depends on: 405163
Also of interest is bug 405165: menu icons.
Attached image Assembled Options.png
This is the browser/themes/gnomestripe/browser/preferences/Options.png file. It has a mask now as the Privacy icon instead of the door tag, but I think it would be quite nice and traditional to keep the Firefox globe as the Content icon instead of the tango style one.

The tango globe can definitely be used as the language pack icon under Addons, though.
Created bug 405619 for non-Gnome build breakage.
@Michael: Those option icons are still undergoing some changes, some of them are not final yet.

I don't think we should use a globe icon at all. Not for "Content", not for "General" and not for "Language". It doesn't really reflect either. We already proposed alternative metaphors (to be used for all platforms).
>We already proposed alternative metaphors (to be used for all platforms).

I owe you a response on the full list of proposed metaphors.  Overall I think they are great, but let me run them past beltzner and mconnor to get their feedback as well.
There seems to be an issue with the "Always check to see if Firefox is the default browser" confirmation window. The ? icon looks like it was taken from a size or two too small and then scaled up. 

See: http://img503.imageshack.us/img503/4748/minimal84yf8.png

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b2pre) Gecko/2007113004 Minefield/3.0b2pre
(In reply to comment #80)
> There seems to be an issue with the "Always check to see if Firefox is the
> default browser" confirmation window. The ? icon looks like it was taken from a
> size or two too small and then scaled up. 
> 
> See: http://img503.imageshack.us/img503/4748/minimal84yf8.png

Can you please file a bug on that?
Sure. I didn't know if I should or not. 
Never mind that bit, it's not your bug, it's seems as if it's the style I'm using's bug. It takes icons from KDE and (somehow, in an awkward manner) makes the names work in GNOME, so sorry about that. 

*Leaves all sullen and shame-faced*

Thank you for your time, do keep up the hardwork, love the new native *everything*!
No problem Zak. Adding relnote keywords. Having a short explanation about the theme changes under Linux in the release notes should help people pin down occurring problems.
Keywords: relnote
I don't know if anyone was aware of the problem, but I filed bug 407775 for some cosmetic problems with the way the window frame is rendered while tabs are open. 
Depends on: 406672
I'm not sure if this should be just a comment here or if I should file a new bug, but the new theme in Minefield has the forward and back buttons reversed. (Notice how they are pointing towards rather than away from each other.)
(In reply to comment #87)
> I'm not sure if this should be just a comment here or if I should file a new
> bug, but the new theme in Minefield has the forward and back buttons reversed.
> (Notice how they are pointing towards rather than away from each other.)

If you are running the latest nightly (2007121404) and are seeing this, please file a new bug.
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
Depends on: 409287, 409288, 413471
https://bugzilla.mozilla.org/attachment.cgi?id=265313
That icons should appear in icon theme (yes, it's an offtopic wish).
(In reply to comment #89)
> https://bugzilla.mozilla.org/attachment.cgi?id=265313
> That icons should appear in icon theme (yes, it's an offtopic wish).
> 

You just need to pack those icons into a FDO theme with gtk legacy links, make that theme inherit "gnome" and use the new theme.
I need more sizes ;) .
No longer depends on: 409288
Depends on: 414606
Depends on: 414834
Component: OS Integration → Theme
QA Contact: os.integration → theme
Depends on: 413239
Depends on: 418868
The current Larry on Linux doesn't look very Tangoey. At the moment, Larry himself is white, in a coloured square; that's surrounded by a think white border, which itself has a thin grey border; there's also a subtle grey shadow.

I know that changes were made to better match the other OSes' appearance, and I'm not suggesting changing back to the previous Tango look ( http://www.uni-koblenz.de/~monreal/abc/ff3/m2-status.png ), but I think Larry could still look Tangoier without sacrificing consistency with other OSes.

I propose that instead of having Larry himself coloured, on no background (like the previous Tango appearance); Larry should be white, inside a coloured Tangoified square (without the superfluous white and grey borders).
>Larry should be white, inside a coloured
>Tangoified square (without the superfluous white and grey borders).

Here are the new OS X icons as another point of reference: http://mxr.mozilla.org/seamonkey/source/browser/themes/pinstripe/browser/identity.png
Wow, those are indeed nice... Alex, should the tango ones be redone in the same style (no white border, no inner shadow, dark figure on unknown)?
>Alex, should the tango ones be redone in the same style

Sure, but I should also add that for identity unknown we want to go for a grey/ghosted appearance, to convey a lack of information instead of a warning.  The yellow identity unknown icons we currently have will probably be used on SSL content area error message though, since we have them.
So to sum up:

- one white guy on green
- one white guy on blue
- one darkgray guy on yellow
- one transparent ghosty white guy on yellow
- one white guy (with sign) on red => can you please link the mac image for this?

Btw, will the monitor.png and monitor_16-10.png images be cut or are they too missing from the inventory?
Just to clarify:

Identity contextual dialog:
- white customs official glyph on green background
- white customs official glyph on blue background
- white customs official glyph on grey background, more of a wireframe/ghosted feel for this icon

SSL error page:
- black customs official glyph on yellow background to match the yellow warning icon (previous identity unknown icon)

Malware detection page:
- white customs official glyph (with sign) on red => can you please link the mac image for
this?

They don't have one yet, but this is the icon it will replace:
http://mxr.mozilla.org/seamonkey/source/toolkit/themes/pinstripe/global/icons/blacklist_large.png

I will also send out an email to the linux themers with all of this information.
I don't consider the white outline to go against the guidelines myself, but due to popular demand, here goes (hopefully the last) incarnation:

- white customs official glyph on green background
  http://jimmac.musichall.cz/wipicons/firefox3/64x64/identity-EV-nostroke.png

- white customs official glyph on blue background
  http://jimmac.musichall.cz/wipicons/firefox3/64x64/identity-SSL-nostroke.png

- white customs official glyph on grey background, more of a wireframe/ghosted
feel for this icon
  http://jimmac.musichall.cz/wipicons/firefox3/64x64/identity-unknown-nostroke.png

- black customs official glyph on yellow background to match the yellow warning
icon (previous identity unknown icon)
  http://jimmac.musichall.cz/wipicons/firefox3/64x64/identity-SSL-broken-nostroke.png

- white customs official glyph (with sign) on red
  http://jimmac.musichall.cz/wipicons/firefox3/64x64/identity-malware-nostroke.png

The last icons look terrific! Great job
jimmac: those icons look great!  Thanks for doing one more iteration.
The new identity icons from above packed ready to commit.
Attachment #307083 - Attachment description: Identitly icons, final :-) → Identity icons, final :-)
Attachment #307083 - Flags: approval1.9?
Comment on attachment 307083 [details]
Identity icons, final :-)

a1.9=beltzner
Attachment #307083 - Flags: approval1.9? → approval1.9+
Keywords: checkin-needed
(In reply to comment #84)
> No problem Zak. Adding relnote keywords. Having a short explanation about the
> theme changes under Linux in the release notes should help people pin down
> occurring problems.

There's no real need for a specific release note here. We already talk about the new theme in the releasenotes, and if people are finding bugs they should file them in the normal ways.

Checking in browser/themes/gnomestripe/browser/identity.png;
/cvsroot/mozilla/browser/themes/gnomestripe/browser/identity.png,v  <--  identity.png
new revision: 1.5; previous revision: 1.4
done
Checking in toolkit/themes/gnomestripe/global/icons/blacklist_large.png;
/cvsroot/mozilla/toolkit/themes/gnomestripe/global/icons/blacklist_large.png,v  <--  blacklist_large.png
new revision: 1.3; previous revision: 1.2
done
Keywords: checkin-needed
Please add bug 415664, bug 421089 and bug 421423 as dependencies.
Depends on: 415664, 421089, 421423
Please add bug 424363 as a dependency.
Depends on: 424363
I suggest there should be two varieties of the default theme. One based on Tango for Gnome users, and one based on Oxygen for KDE users. Would this be difficult? If a new project is needed for KDE integration, how do I apply to help? I've made a couple of themes before so I have a basic idea how theming works.
Bamm, first Firefox would need to compile with Qt4 support and run without problems.

Then think about icons...

> Would this be difficult?

Tango artists helped Mozilla with default theme. They were interested very much.

I think, if only Oxygen theme is interested and they have all the icons needed, and the theme ready, they can submit it... to the addons site.

> I've made a couple of themes before so I have a basic idea how theming
works.

Get icons from Oxygen project and try yourself to create Oxygen theme. Then ask them for help. You can release official theme on A.M.O, however I wouldn't count on eventual inclusion in main.
> Then think about icons...

That's what I'm thinking of. I don't mind if Firefox is compiled in GTK, as long as it "looks right".

> and the theme ready, they can submit it... to the addons site.

That's the problem. This means that Firefox is destined to look bad in KDE by default, and users have no choice but to go to addons. It's as if the Firefox team only cares for Gnome users.

What I'm looking for is an official project to at least make it look fine in KDE, and if there is one I would gladly volunteer.

I mean, Firefox can also tell Mac users to just go download a Cocoa theme, but instead it is making a theme just for Mac. Several years ago, when Firefox was more concerned with consistency of look across platforms, I made an "Internet Explorer" theme. At that time, people downloaded my theme when they want Firefox to look well in Windows. But today, Firefox showed that they care about Windows users by making separate themes for WinXP and Vista. No need to tell them to go to addons site.

Why are KDE users an exception? I know there are hundreds of themes in addons, but why do we have to download one when users of other platforms already have one ready made for them? Shouldn't Firefox integrate with every platform by default? It's not like KDE is some obscure platform.

Again, I'm not just complaining -- I'm offering to help. In fact, if a project is started, I could start with one of the "Keyhole" themes being done for Windows and Mac, and then substitute icons that integrate well with KDE. A Crystal icon theme already exists for Firefox, so I could just use a simple modification of those icons to fit the Keyhole concept. I'm willing collaborate with the Firefox theme developers to ensure that the consistency across platforms is not lost. A delicate balance is important between retaining the Firefox identity and feeling native.
(In reply to comment #109)
> That's the problem. This means that Firefox is destined to look bad in KDE by
> default, and users have no choice but to go to addons. It's as if the Firefox
> team only cares for Gnome users.
It's my understanding that the Gnome community and some distros do the Gnome work.  As far as I know, we've begged and pleaded for the KDE community to do the same, but there's never really any interest.
(In reply to comment #109)
> It's as if the Firefox team only cares for Gnome users.

It's as if, but it isn't actually.  It's just that Firefox engineers have limited time, and we can't do everything that would be useful or valuable; we have to prioritize and focus on the highest reward tasks.

Of course, others may prioritize differently, and they are welcome to work on what they want.  That's scratching your itch, a fundamental tenet of our open source development process.


> What I'm looking for is an official project to at least make it look fine in
> KDE, and if there is one I would gladly volunteer.

Keep in mind that putting together an complete theme is a large, complex, difficult project, and I don't think there's an existing one you to contribute to (certainly not an "official" one), but if you're up for doing it yourself, more power to you.

You don't need any official approval.  That's not how we work.  You just need to do the work, make it good, and then distribute it via the appropriate channels (in this case AMO and perhaps KDE-centric distributions that ship Firefox).

See the documentation on developer.mozilla.org for more information about how to build themes for Firefox, ask questions in mozilla.dev.themes, and please file a new bug for the work, as this one is specific to Tango theme integration.
> It's my understanding that the Gnome community and some distros do the Gnome
> work. As far as I know, we've begged and pleaded for the KDE community to do
> the same, but there's never really any interest.

To say that no one in the KDE community is interested enough to make Firefox integrate is hasty generalization. Several Crystal themes exist, and there are even addons to make Firefox use KDE dialog boxes instead of Gnome ones. Mandriva distributes Firefox 2 with acceptable integration.

So yes, the KDE community and some distros also do the KDE work. Firefox only needs to integrate them in main, possibly with a little fixing.

If a KDE user downloads Firefox 3, it should look fine as is. If someone is willing enough to do the work, why then is Firefox reluctant to include it?
> Keep in mind that putting together an complete theme is a large, complex,
> difficult project

I know. This from my experience maintaining an "Internet Explorer" theme a few years ago.

> You don't need any official approval.  That's not how we work.  You just need
> to do the work, make it good, and then distribute it via the appropriate
> channels (in this case AMO and perhaps KDE-centric distributions that ship
> Firefox).

In that case, why aren't the new Mac, XP, and Vista themes just distributed in AMO? From what I understand, Firefox is now gearing towards platform integration.

The makers of the new theme with the keyhole back button only needs to add Linux. If they lack time and manpower, I can help. I'm not looking to make an independent theme, I want to collaborate with the existing theme makers so that Linux can be added to the new theme.

> See the documentation on developer.mozilla.org for more information about how
> to build themes for Firefox, ask questions in mozilla.dev.themes, and please
> file a new bug for the work, as this one is specific to Tango theme
> integration.

I will, thanks!
I find it very commendable that you're willing to invest time into a KDE integration. I just wonder whether it the work would be done with an oxygen icons sporting theme. One of the key points of the currently shipped default themes is that they adapt to changes the users make regarding their OS themes: Used icon sets, colors, fonts, sizes, scroll bars, buttons etc. Is this possible at all without going the QT route, which would need a much more committed maintainer than a "simple" theme?

Some linux distros sport(ed) a unified Gnome/KDE theme engine(RedHat/Suse, don't know whether they still do this), solving the problem differently. Others ship themes adapted to an overall look, without propagating user made changes to one theme engine to other parts of the system.

If you decide to work on this I hope your rather frustration resistant when only a minority of users in the end will take your solution among all those available. Have fun nonetheless. :)
> In that case, why aren't the new Mac, XP, and Vista themes just distributed in
> AMO? From what I understand, Firefox is now gearing towards platform
> integration.

Many themes haven't been updated to Firefox 3 yet so they're not available for AMO at this point. As someone who's been keeping an eye on the Theme Development group at Mozillazine I can tell you there's a ton of changes to be made, including some changes in the past month that have caused new issues for theme developers. Plus the themes for other OSes aren't quite rendered the same, which will cause a theme designer even more problems trying to get a theme that's truly platform agnostic.

Getting themes for Fx3 in AMO is simply going to take time. Hopefully within a month of when Fx3 launches in June there's going to be a river of theme updates coming in.

> The makers of the new theme with the keyhole back button only needs to add
> Linux. If they lack time and manpower, I can help. I'm not looking to make an
> independent theme, I want to collaborate with the existing theme makers so that
> Linux can be added to the new theme.

Dear God, please spare us the keyhole for Linux builds. Sure, someone can make a theme with it for those who want it, but I'm one of he user who were thrilled that Linux didn't get it. That just seems like an IE button configuration to me, and I don't run Windows anymore. (I may be mistaken about that, but that's how the keyhole strikes me, true or not.)
> Dear God, please spare us the keyhole for Linux builds. Sure, someone can make
> a theme with it for those who want it, but I'm one of he user who were thrilled
> that Linux didn't get it. That just seems like an IE button configuration to
> me, and I don't run Windows anymore. (I may be mistaken about that, but that's
> how the keyhole strikes me, true or not.)

Don't worry, it won't affect Gnome. :)
Some hints for the KDE themers:

- Get a complete set of icons you can use. Some can probably be used directly from KDE, but you need to get permission from the Oxygen guys to re-license their work, as the license is not compatible (to ship Oxygen artwork with Firefox).

- There's a bug open to support the Freedesktop icon spec (what KDE4 uses) for the next Firefox, which would greatly simplify this btw (vote for it on bug 406868)

- Take the gnomestripe theme and replace the icons. Fix some CSS perhaps. Take the theme to AMO and let people test it. Then, ask for inclusion upstream. 

Still, there will be things that "look better" on GNOME: Firefox has GNOMEish file and print dialogs for example, but only because Firefox uses GTK as the backend for XUL. It's certainly possible to get QT backends as well, but only if the QT community builds (and maintains) it I assume.
@Bamm:

> That's the problem. This means that Firefox is destined to look bad in KDE by
default, and users have no choice but to go to addons. It's as if the Firefox
team only cares for Gnome users.

Because KDE cares about their browser. If they would be interested, Mozilla would welcome those interested people with opened arms.

> I mean, Firefox can also tell Mac users to just go download a Cocoa theme, but
instead it is making a theme just for Mac.

Comparing desktop environment is simply unfair.

> Several years ago, when Firefox was
more concerned with consistency of look across platforms, I made an "Internet
Explorer" theme. At that time, people downloaded my theme when they want
Firefox to look well in Windows. But today, Firefox showed that they care about
Windows users by making separate themes for WinXP and Vista. No need to tell
them to go to addons site.

That's good example, however notice when we wanted to have Linux theme and when you want to separate a KDE theme... Too late.

> Why are KDE users an exception? I know there are hundreds of themes in addons,
but why do we have to download one when users of other platforms already have
one ready made for them? Shouldn't Firefox integrate with every platform by
default? It's not like KDE is some obscure platform.

If KDE project would be interested, as I said, this could probably happen, that Firefox could have KDE theme too. And maybe even Qt build.

> Again, I'm not just complaining -- I'm offering to help. In fact, if a project
is started, I could start with one of the "Keyhole" themes being done for
Windows and Mac, and then substitute icons that integrate well with KDE. A
Crystal icon theme already exists for Firefox, so I could just use a simple
modification of those icons to fit the Keyhole concept. I'm willing collaborate
with the Firefox theme developers to ensure that the consistency across
platforms is not lost. A delicate balance is important between retaining the
Firefox identity and feeling native.

One man is not too much for creating whole theme, even if based on existing.

--

@Myk:

> You don't need any official approval.  That's not how we work.  You just need
> to do the work, make it good, and then distribute it via the appropriate
> channels (in this case AMO and perhaps KDE-centric distributions that ship
> Firefox).

How do you see this? I can't imagine how you target DE can be "detected", or how n00b can choose the appropriate version.

-- 

@Bamm:

> To say that no one in the KDE community is interested enough to make Firefox
> integrate is hasty generalization. Several Crystal themes exist, and there are
> even addons to make Firefox use KDE dialog boxes instead of Gnome ones.
> Mandriva distributes Firefox 2 with acceptable integration.
> 
> So yes, the KDE community and some distros also do the KDE work. Firefox only
> needs to integrate them in main, possibly with a little fixing.

Take a look at Qt build... Not maintained anymore...

> In that case, why aren't the new Mac, XP, and Vista themes just distributed in
> AMO? From what I understand, Firefox is now gearing towards platform
> integration.

Because people were interested in creation of those themes and they contributed. Without interest from Tango! Project no native Linux theme could exist ever. Probably too much said ("ever"), however they made big job. Say "thanks you" to them.
Thanks for the tips, Michael. Just want to add...

> Get a complete set of icons you can use. Some can probably be used directly
> from KDE, but you need to get permission from the Oxygen guys to re-license
> their work, as the license is not compatible (to ship Oxygen artwork with
> Firefox).

Oxygen has published a complete set of guidelines for conforming with their UI style. One does not have to user their icons, but simply needs to conform with their guidelines.

As you know, the upcoming theme for Windows XP does not use the IE6 icons per se, but it is built with the XP feel. Of course, Microsoft's licence for the XP feel is not compatible either. :)

==

Instead of making Firefox for Windows take on the Vista feel, the developers did the wise thing and made a separate theme for Vista and XP. They knew that the Vista theme will not feel at ease with XP users. They could have said: "The XP community should just make a theme and submit it to AMO. This is the way we work." But they cared enough to make it a separate theme.

This even though several Windows XP themes already exist in AMO just waiting to be updated for Firefox 3 by their maintainers.

Anyway, I guess I should file a separate bug on this. At least I have gotten your attention. Thanks for all your advice.
(In reply to comment #118)
> How do you see this? I can't imagine how you target DE can be "detected", or
> how n00b can choose the appropriate version.

I'm not suggesting detecting the desktop environment, I'm suggesting that distributions that ship KDE by default could ship the KDE theme with Firefox.
It's not impossible to make it simply available in addons manager, however no such theme exists.
(In reply to comment #117)
> Some hints for the KDE themers:
[...]
> - Take the gnomestripe theme and replace the icons. Fix some CSS perhaps. Take
> the theme to AMO and let people test it. Then, ask for inclusion upstream. 

This is an excellent suggestion.

I'll also note that this is more-or-less how the new OS X theme got rolling... It was available as an AMO theme addon ("Proto") before it landed in the Mozilla code base. That worked well, because it allowed doing lightweight modification & feedback cycles without doing a full Mozilla review.
> Because KDE cares about their browser.

KDE *developers* care about their browser, of course. And many KDE users are also Firefox users. Similarly, Microsoft developers care about their browser. Apple developers care about their browser. We don't expect them to contribute to Firefox. We just make Firefox better for their users because many Windows and Mac users are also Firefox users!

Gnome is an exception because they do not have a browser like Windows, Mac, and KDE do (there's Epiphany but it uses Gecko or Webkit so it's mainly just an interface for a browser). And so we should be thankful to the Gnome developers who want to help Firefox to integrate it with Gnome.

But it's unfair to say that if KDE developers care about their browser, then Firefox is justified not to care for their users. There are users too, not just developers.

> Comparing desktop environment is simply unfair.

It is unfair when you are thinking as a developer, but it is fair if you are thinking as a user!

> you want to separate a KDE theme... Too late.

Because I am a user, and I only saw its ugliness when I downloaded the beta. Are not users entitled to voice their views? Do I have to be a developer involved in the planning from the start in order to be heard?

I agree that there is little time before the release. Can't we make just make Firefox a little less ugly for KDE users? We can make it better after that.

> If KDE project would be interested, as I said, this could probably happen,
> that Firefox could have KDE theme too. And maybe even Qt build.

I highly doubt that the MS and Apple teams are interested either. Like I said, Gnome is an exception for having no browser. Don't judge other developers based on what Gnome is doing, instead just be thankful for the help from the Gnome team and continue to help all users regardless of platform.

> Take a look at Qt build... Not maintained anymore...

That's a developer's problem not the users. Users like me don't care if the app I download is gtk, as long as it looks and works fine enough. That's why I use Firefox. It's only the upcoming Firefox 3 that has become a pain in the eyes with too much Gnome integration.

> If they would be interested, Mozilla would welcome those interested people
> with opened arms.

I am interested, but you said it's too late.

Your frustration with KDE developers is understandable, but please don't take it against the users. It is only fair that Firefox should look fine in all major desktops that it has users: Windows, Mac, Gnome, and KDE.
IMPORTANT: if you have something to say about KDE integration with Firefox, please stop posting it to this bug.  Post it to the mozilla.dev.platforms.linux newsgroup, or file a new bug for each specific KDE integration point you would like and post it there.

This bug is not the appropriate place for such discussion.
> This bug is not the appropriate place for such discussion.

It is. This bug is NOT about Tango per se, it's about using Tango "for better Linux UI integration". It's about pushing Tango as default for all Linux users, and that's what I'm against.
> Gnome is an exception because they do not have a browser like Windows, Mac, and
> KDE do (there's Epiphany but it uses Gecko or Webkit so it's mainly just an
> interface for a browser). And so we should be thankful to the Gnome developers
> who want to help Firefox to integrate it with Gnome.

Not interface for browser, because browser is the whole app. You probably mean "frontend for rendering engine", however every browser is based on something!

> But it's unfair to say that if KDE developers care about their browser, then
> Firefox is justified not to care for their users. There are users too, not just
> developers.

It's not Firefox' fault that KDE's not interested in contributing. Understand.

> It is unfair when you are thinking as a developer, but it is fair if you are
> thinking as a user!

Stop thinking as user-only.

> Because I am a user, and I only saw its ugliness when I downloaded the beta.
> Are not users entitled to voice their views? Do I have to be a developer
> involved in the planning from the start in order to be heard?

First, do something. Then talk with us.

> I agree that there is little time before the release. Can't we make just make
>  Firefox a little less ugly for KDE users? We can make it better after that.

How do you imagine this?

> I highly doubt that the MS and Apple teams are interested either. Like I said,
> Gnome is an exception for having no browser. Don't judge other developers based
> on what Gnome is doing, instead just be thankful for the help from the Gnome
> team and continue to help all users regardless of platform.

You're comparing completely different worlds. Every multiplatform app cares about Windows and Mac, 'cause they're popular, while GNOME simply wanted to help (maybe not GNOME, but Tango, to be sure).

> That's a developer's problem not the users. Users like me don't care if the app
> I download is gtk, as long as it looks and works fine enough. That's why I use
> Firefox. It's only the upcoming Firefox 3 that has become a pain in the eyes
> with too much Gnome integration.

Firefox always was integrated with GNOME. Instead of crying here, look at Konqueror and help them to make KDE-integrated competitor for Firefox.

> I am interested, but you said it's too late.
> 
> Your frustration with KDE developers is understandable, but please don't take
> it against the users. It is only fair that Firefox should look fine in all
> major desktops that it has users: Windows, Mac, Gnome, and KDE.

OMG. You're only talking, talking, talking. Have you made any step to create Oxy-theme?

> It's about pushing Tango as default for all Linux users,
> and that's what I'm against.

It has been done already. You may only cause removal with such behavior.
> This bug is NOT about Tango per se, it's about using Tango "for better
> Linux UI integration". It's about pushing Tango as default for all Linux users,
> and that's what I'm against.

"Better Linux UI integration" does not mean "pushing Tango as default for all Linux users", but it's irrelevant in any case, as bug reports are for technical discussion, not advocacy.  Take your thread to the appropriate forums.
> Instead of crying here, look at Konqueror and help them
> to make KDE-integrated competitor for Firefox.

If you think it's inappropriate to post my disagreement with the goals of this bug, then thanks. I'm out of here. I only wanted to help, but I know when I'm not welcome.
(In reply to comment #128)
> I only wanted to help, but I know when I'm not welcome.

You are welcome to post your disagreement, and we welcome your contributions of KDE integration.  We only ask that you post in the appropriate forums and open new bugs for the work.
>If you think it's inappropriate to post my disagreement with the goals of this
>bug

We also want to have these types of discussions in a more open forum so that everyone in the community can participate.  There are only a limited number of people cc'd to this bug, but pretty much everyone reads mozilla.dev.apps.firefox.  For instance, that is where the plan to create a tango theme originally formed starting with a post in May 2007 (http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/286d69093f0cdc01/c33ac8982e2c3100?lnk=gst)
I'm going to call this done. We still have some minor things to fix, but it's looking great!
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
So, it must be said:

Thanks, guys, for making Firefox rock again :) .
It's really amazing to see what has been done here in the last 6+ month. Thanks to everyone who contributed to make this rock!
Tango artists, see bug 429147.
Depends on: 429149
You need to log in before you can comment on or make changes to this bug.