Closed Bug 572482 Opened 15 years ago Closed 11 years ago

[Linux] UI Refresh

Categories

(Firefox :: Theme, enhancement)

Product:
Firefox
Component:
Theme
Platform:
All
Linux
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: shorlander, Unassigned)

References

(
URL
)

Details

(Keywords: meta)

Attachments

(2 files, 1 obsolete file)

Linux Theme Design Spec
223.42 KB, image/png
Details
Linux Status (2010/09/20)
136.24 KB, image/png
Details
Attached image Linux Theme Design Spec —
For the Linux theme revamp many elements will need to move, merge and/or hide in the default configuration: * The Menu Bar will be hidden by default * Tabs above the navigation bar will be default (Bug #544815) * The Home button will not be needed on the toolbar because of the addition of the Home Tab (Bug #544819) * The Bookmarks Bar will be hidden by default for new profiles and profiles that have never modified the default contents (Bug #544817) * A Bookmarks Menu Button that replicates the Bookmarks Menu will be placed to the right of the Search Bar (Bug #544817) * The Refresh and Stop buttons will merge with the Go button attached to the Location Bar (Bug #544816) * The Bookmarks Star will move to the left of the Location Bar * Site Identity will move to an element inside the Location Bar (Details are still in progress) * Introduce an App Button in the titlebar and an App Menu containing the streamlined contents of the Menu Bar (Bug #556174) In addition there will be all new visuals. Many mockups covering various system themes and configurations can be found on the Wiki: https://wiki.mozilla.org/Firefox/4.0_Linux_Theme_Mockups Notable design considerations: 1. TitleBar Gradient - Get current titlebar gradient and extend to behind the tabs. Use theme native titlebar widgets. Use titlebar font for “Firefox” button. 2. Firefox Button/Menu - Create Firefox Button/Menu that resides in the titlebar. Should respect other system widgets in the titlebar. 3. Active Tab + Toolbar Backgrounds - Overlay white highlight gradient, edge effects, borders and shadows on window color. 4. Inactive Tab - Use window color at -20% luminance and saturation and 90% opacity. Alternatively get GTK theme inactive tab color at 90% opacity. Overlay gradients, edge effects, borders and shadows. Another possibility would be to use ThreeDShadow as a base color with gradient overlays. 5. Tab Progress Line - Use “Highlight” background color as base. Some themes like Ambiance use different color progress bars. Somehow extract that color? 6. Toolbar Buttons - Create adaptive toolbar buttons with translucent shades to fit any theme. Select icon set based on current theme or use SVG icons with base color using “Highlight” color. 7. Toolbar Fields - Use native fields for location and search bars. See attachment for mockup.
Blocks: 544823
Depends on: 513159, 544816, 544818, 544819, 572484, 572485, 572488
(In reply to comment #0) > * The Menu Bar will be hidden by default And you will be able to swap out the Firefox button for the menubar in the toolbar customization panel, right?
No. You will just enable menu bar.
blocking2.0: --- → ?
(In reply to comment #2) > No. You will just enable menu bar. Yes.
blocking2.0: ? → ---
I thought by enabling menu bar Firefox Menu goes away.
(In reply to comment #4) > I thought by enabling menu bar Firefox Menu goes away. Oh, sorry, that is what I meant. I was agreeing with you :)
Not sure if you removed the flag on purpose or not so putting it back for drivers to see. Apologies for the spam, have it minused if that's what you meant.
blocking2.0: --- → ?
Keywords: meta
(In reply to comment #0) > * Introduce an App Button in the titlebar and an App Menu containing the > streamlined contents of the Menu Bar (Bug #556174) It looks like bug 556174 is Windows 7-only; is there another bug for tracking the Linux-specific implementation. Also, is there a timeline for when these things can be expected? The planning page (https://wiki.mozilla.org/Firefox/Projects/New_Theme/Linux) doesn't provide one. (The reason why I ask is because this is the #1 Input feedback in the betas, so it would be nice to have a response to those people, e.g. "this will be ready in beta x!")
David, right now a window-frame integrated Firefox button is not really possible on linux without ugly hacks (see #513159). I think the current agreement is to - show a menu bar by default on linux - provide ways to toggle the menu display - (maybe) provide a firefox button as a toolbar button - revisit after Fx4 and see what can be done with Gtk3, once it is out >> because this is the #1 Input feedback in the betas This is interesting, though. Can you share what exactly the feedback is? Are people just curious what the plan is or are there already specific demands? :) Also, any feedback regarding the (lack of) theme change on Linux? Is there any indication that linux users would like the new tab and toolbar button look?
We can shrink menu bar to Firefox Button and place tabs next to it.
(In reply to comment #10) > We can shrink menu bar to Firefox Button and place tabs next to it. Sure, that is still a possibility. But as the menu is most likely staying as the default, getting the keylock, toolbar and tab look stuff sorted out and on par with Windows/OSX should be higher priority right now. Looks like we already missed beta3 but this should really be ready for beta4 IMHO to allow some adjustments after a bit of exposure.
I can't speak for all Linux users, but I personally love the new mockups, it brings a fresh look and I believe it it is more intuitive. I don't mind keeping the menu bar if its able to be turned off. Maybe have both if its doable. The ability to have a menu button and menu bar.
(In reply to comment #12) > The ability to have a menu button and menu bar. That is redudant.
(In reply to comment #9) > > >> because this is the #1 Input feedback in the betas > > This is interesting, though. Can you share what exactly the feedback is? Are > people just curious what the plan is or are there already specific demands? :) > > Also, any feedback regarding the (lack of) theme change on Linux? Is there any > indication that linux users would like the new tab and toolbar button look? The feedback is public and can be segmented by OS: https://input.mozilla.com/en-US/search/?product=firefox&version=4.0b2&sentiment=sad&os=linux&date_start=07%2F21%2F2010&date_end=07%2F30%2F2010 I did some research of this with b1 last week (http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/7f57b34ed588149b/24e96a1412edc51b) and by far the most common complaint among Linux users was the lack of UI updates. What worries me is that a lot of the more vocal early adopters (or, put differently, a lot of our most passionate community members) are using Linux and while I can understand why Windows/Mac is a priority due to the sheer number of end users, I think we're missing out in an important part of the early adopters crowd if we don't give the Linux crowd this visual refresh as well. Looking at the most recent negative feedback from b2, here are some quotes from today and yesterday: "I hate Old UI under Linux ." "I don't have the bright new interface on Linux, so I'm a little disappointed as I waited for it eagerly. Hope it will be in the next beta!!!" "No glass dessign for linux" "Linux beta version is falling behind the others (no new tabs - all versions should be the same in features)" "Lack of updated liux interface. As it is extremely stylish." "I don't get to see a bunch of the new features because they are windows only right now. At least FF4 is more stable than FF3." "Mi aspettavo un look più accattivante per Linux simile a quello di Windows..." ("I expected a more appealing look for Linux similar to Windows") "Can we remove traditional menu from firefox for linux? I can see the menu is not present in the windows version" "default linux/ubuntu theme is fugly" "The linux version is still fugly ;(" "j'ai testé cette béta sous windows et linux et je trouve que l'interface est beaucoup moins belle sous linux, malheureusement." ("I tested this beta on windows and linux and I find that the interface is far less beautiful Linux, unfortunately.") "The menu is still visible (Ubuntu, Firefox 4 beta 2)" "On linux running Firefox 4.0 Beta 2 the file, edit, view, etc. menus are above tabs set to "tabs on top""
Please do not mess with the window title bar. It is under the window manager's responsability, and is designed for interactions with the windows themselves: resizing, docking, minimizing, maximizing, sending to other workspaces, closing, etc. It should not be used for direct interaction with the process that is displaying the window content, and doing would be prone to user confusion. For interaction with the software itself, there is the content of the window, that may contain things like a toolbar, a menu bar, a menu icon or whatever. Should the menu be reduced to a simple button or icon, I think it could very well be displayed as a first icon in the toolbar, for instance. And if you do so, please include an easy to access option to display a full menu bar. There are people that have screen space to display it instead of adding one menu level.
(In reply to comment #15) > Please do not mess with the window title bar. Don't worry, FX devs are skilled enough not to mess up the title bar.
Also, it would be nice to keep using the system GTK+ theme. If a user does not like it, it can change it globally, so that all his applications look good. Adding a specific theme would destroy desktop coherence.
In addition to @tanguy, there are applets (e.g. in Ubuntu Unity) that pull the menu bar and put it in a panel to save screen space. With a lack of a menu bar, would such applets work? It would be nice to see FF utilize this feature.
That will be a problem...
The GTK+ theme in Chromium in my opinion looks bad but they tried :-). Chromium did give the option to not use the GTK window bar allowing for themes to cover the whole UI which was pretty cool.
I think we need to stay on topic here. We have individual bugs which should be worked on in this order IMHO: #572488 new tab style (already in Win/Mac) #572485 + #572484 new toolbar style (already in Win/Mac) #513159 Win/Chrome like window border stuff (not possible for 4.0) In addition we should probably file another to get at least menubar hiding and alt-toggle activated on linux and maybe another bug for a temporary firefox button replacement (low priority IMHO)
(In reply to comment #21) > #572488 new tab style (already in Win/Mac) Only initial implementation in Win. They aren't finished yet.
Less ugly solution: Making the window borderless and emulate current metacity style inside the window. Other window managers: use some own style or show toolbar.
(In reply to comment #23) > Making the window borderless and emulate current metacity style inside the > window. Feel free to read bug #513159 for the whole story i.e. why this is currently not a good idea and why it will be easy to do in about half a year from now.
I'm a Linux user, and I use Firefox since firebird. I appreciate the work you did on Firefox, for standards compliance on the web, and for providing a modern browser to Linux users. I don't want to sound sentimental, but thank a lot guys :) I appreciate most of the changes for version 4. I also appreciate the fact that you were thinking of leaving the choice, for those who would get the old behavior for some points. However, I have to agree with Tanguy Ortolo. The window title bar is under the window manager's responsability, and shouldn't be used for direct interaction with applications (and this concept could also apply to Win/Mac). I think the menu button on the tab bar, like Opera, is a good compromise. Moreover, I would like to talk about integration in KDE. Today in Firefox 3, if you want to use KDE dialog bok (which are much better than GTK, take a look to "kdialog --getopenfilename ~"), you have to use a hack like kgtk. Is it possible that Firefox 4 uses KDE dialog box if run under kde, and GTK dialog box if run under Gnome?
(In reply to comment #25) > However, I have to agree with Tanguy Ortolo. The window title bar is under the > window manager's responsability, and shouldn't be used for direct interaction > with applications (and this concept could also apply to Win/Mac). I think the > menu button on the tab bar, like Opera, is a good compromise. > > Moreover, I would like to talk about integration in KDE. Today in Firefox 3, if > you want to use KDE dialog bok (which are much better than GTK, take a look to > "kdialog --getopenfilename ~"), you have to use a hack like kgtk. Is it > possible that Firefox 4 uses KDE dialog box if run under kde, and GTK dialog > box if run under Gnome? That reasoning only applies to traditional software. Firefox is extremely customizable and themeable. If window frames are solely under the responsibility of window managers and therefore unchangeable for theme authors, you have a huge disconnect between the theme of the window frame and the Firefox theme. The titlebar should be customizable from Firefox so that theme authors have more freedom. Also the Firefox button is integral to its brand identity. Removing it or moving it to a less prominent position like the tab bar only serves to make Linux appear less capable than other OS's. Frankly this keep the native OS look and feel mentality is slowing down theme progress in Linux. It's quite saddening that Firefox hasn't changed much since Firefox 2, while Firefox on Windows and Mac have already gone through two revisions. Currently Linux users have to rely on 3rd party extensions and themes to make Firefox look and behave the same way it does on other platforms. This is completely flipped around. Rather Firefox devs should focus on making the Firefox brand consistent and users who want a more native theme should rely on 3rd party themes. But ditto on KDE integration. I'd like to see a version of Firefox with Qt widgets. I've seen random bug fixes with Qt but not sure when it will be usable, if ever.
(In reply to comment #0) > > 4. Inactive Tab - Use window color at -20% luminance and saturation and 90% > opacity. Alternatively get GTK theme inactive tab color at 90% opacity. Overlay > gradients, edge effects, borders and shadows. Another possibility would be to > use ThreeDShadow as a base color with gradient overlays. > In addition, we should also consider reducing the opacity of the favicons here. When there are a lot of tabs open, the tabbar is too noisy with all the multicolored favicons.
Depends on: 585370
No longer depends on: 513159
Not blocking on a meta bug - it obfuscates the actual set of work needed to be done. Please nominate the individual bugs for the pieces of work for blocking.
blocking2.0: ? → -
(In reply to comment #0) > Created attachment 451656 [details] Just wanted to say that I love this new theme! Its hurt me when I try Fx4 beta2 and see this old poor design... Hope you will succeed in your change efforts! Good luck.
(In reply to comment #14) > I did some research of this with b1 last week > (http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/7f57b34ed588149b/24e96a1412edc51b) > and by far the most common complaint among Linux users was the lack of UI > updates. Thanks for posting this!
I think that the new UI was the most anticipated thing on 4.0. I personally think that its absence will have negative impact on your trustfulness. Currently the UI is horrible and both Opera and Google Chrome have better UI than Firefox 4. I am using nightly versions of Firefox and I haven't expected any major change in UI yet (no, tabs on tob are not). Even though I like Firefox, this makes me a bit sad…
Yeah, it's annoying a lot of people. It sort of feels like someone in the UI department is trying to passive-aggressively drop Linux support. Nonetheless, Bugzilla really isn't for complaining. Please post only contributive comments.
(In reply to comment #32) > Yeah, it's annoying a lot of people. It sort of feels like someone in the UI > department is trying to passive-aggressively drop Linux support. Nonetheless, > Bugzilla really isn't for complaining. Please post only contributive comments. It's not in the UI-department that the problem lies. Beautiful mock-ups for Firefox 4.0 on Linux have been created. It just seems there's way too few people working on implementing things in Firefox nowadays.
I know. Say UI-implementing-department, then. Nonetheless, yes, of course people are very busy, but it just feels like Linux is less tier-1-ish these days. I'll point out that I and others are not even necessarily in total disagreement with focusing on other areas before Linux theming. Still annoying, though. ;)
One thing the UI devs might want to consider is making the theme look (especially the button look) consistent across all platforms... or at least consistent between Windows and Linux (as the OSX chrome look fits well with the Mac look-and-feel). The reason this is important is the personas extension. In my experience with firefox 3.5/3.6, personas only really work well with the default theme. Some of the fancy persona screenshots really didn't have the same polish in Linux as they did on Windows (or OSX) because of this.
(In reply to comment #35) See bug 572485 for a good route. With that things would have some cross-platform consistency and also have some blending with the local OS theme at the same time.
(In reply to comment #33) > It's not in the UI-department that the problem lies. Beautiful mock-ups for > Firefox 4.0 on Linux have been created. It just seems there's way too few > people working on implementing things in Firefox nowadays. As stated above, Mozilla is waiting on stuff in GTK to land so they can use it to implement the features in a SANE way that doesn't break things. There's no good way to fix bug #513159 on Linux at the moment, but there WILL be, however not in time for FF4 so Mozilla has decided to wait until they do it right.
Depends on: 593823
Depends on: 593653
Attached image screenshot w/patch on Windows 7 (obsolete) —
Here's what that patch looks like on Win7.
Comment on attachment 473392 [details] screenshot w/patch on Windows 7 Ugh. Thanks for loading the wrong tab, TabCandy...
Attachment #473392 - Attachment is obsolete: true
(In reply to comment #39) > Ugh. Thanks for loading the wrong tab, TabCandy... File a bug. ;)
After discussion on IRC it looks like plans changed regarding "7." and the text entry widgets will get a custom style as well, see bug #595973
Depends on: 595973
Added bug #596178 (tab close icon)
Depends on: 596178
Depends on: 415958
Depends on: 596963
Depends on: 580970
No longer blocks: 597414
AIUI, the spec for the linux theme has changed significantly from what is in the mockup (we don't do a Firefox button on linux, for instance, unless I'm mistaken -- which is possible!) Can we get an updated view of what Linux is supposed to look like for FF4 final, or some other way to understand how much distance is left to cover?
(In reply to comment #43) > we don't do a Firefox button on linux The current plan is to make it available as an option. See bug 585370. > changed significantly from what is in the mockup Linux would also look a lot closer to the mockups if bug 593823 were to just get approval to land. (not sure what the holdup is there)
(In reply to comment #43) > AIUI, the spec for the linux theme has changed significantly from what is in > the mockup (we don't do a Firefox button on linux, for instance, unless I'm > mistaken -- which is possible!) The technical limitations surrounding Linux have altered the desired design to some degree. The Firefox button won't be a in the titlebar or on by default. There is ongoing work in bug 585370 for implementing the Firefox button on Linux as a customization option. > Can we get an updated view of what Linux is supposed to look like for FF4 > final, or some other way to understand how much distance is left to cover? In the attached file the current state of Linux can be seen on top and the desired state on the bottom. The new tab style has landed and there is a bug with a patch to put them on top by default. The other major change would be the toolbar buttons which are in progress in bug 572484. There is also a fairly noticeable visual disturbance with certain system themes that create a unified titlebar+menubar appearance. In addition to those items there are other smaller bugs pertaining to polish and updated artwork similar to those still required for Windows and Mac.
(In reply to comment #45) > There is also a fairly noticeable visual disturbance with certain > system themes that create a unified titlebar+menubar appearance. That's Bug 580970 ;-)
I believe this updated status is wrong, as the new identity box won't make it into FX4.
Since this bug seems to be a meta-bug, i'd like to point out my comment under bug 567814 : new Remember Password doorhanger notification breaks consistency over the GNOME desktop which uses GTKInfoBar which looks like current Firefox 3.6 bar-style notifications system : very bad from my point of view and regarding user experience
(In reply to comment #48) > Since this bug seems to be a meta-bug, i'd like to point out my comment under > bug 567814 : new Remember Password doorhanger notification breaks consistency > over the GNOME desktop which uses GTKInfoBar which looks like current Firefox > 3.6 bar-style notifications system : very bad from my point of view and > regarding user experience In my point of view the badest thing is to annoy the user with a notification that need too much attention. That's why doorhanger notification have been created. ;-)
I understand your point of view but consistency is a GNOME feature (thanks to HIG and all) It's a goal of every HIG (whatever the desktop) because it helps the user who can share the same experience over all applications. Shall i fill a separate bug report ?
(In reply to comment #50) > I understand your point of view but consistency is a GNOME > feature (thanks to HIG and all) FWIW I don't think the GNOME HIG has anything to say about notifications like the ones you are talking about here. There was a design decision to move away from the bars and keeping them on one platform does not make much sense. Further improvements to the doorhanger notifications will probably not "fit" into a bar anymore anyway.
(In reply to comment #51) > (In reply to comment #50) > > I understand your point of view but consistency is a GNOME > > feature (thanks to HIG and all) > > FWIW I don't think the GNOME HIG has anything to say about notifications like > the ones you are talking about here. There was a design decision to move away > from the bars and keeping them on one platform does not make much sense. > Further improvements to the doorhanger notifications will probably not "fit" > into a bar anymore anyway. Sorry to insist but as i said, it's a goal of every HIG to allow the user to share the same experience on every applications (even if every particular points are not explicitly mentioned). To be clear : it's their raison d'être. Until know Firefox made effort to integrate well in each desktop and that is good if not necessary Breaking consistency by changing the notification system would be an aimportant regression to me. We should weigh carrefully the pros and cons For that purpose could you explicit :"Further improvements to the doorhanger notifications will probably not "fit" into a bar anymore anyway" ? thanks
HIG debates, and frankly most debates do not belong here. A most a meta bug should have light meta debate. Take this specific discussion elsewhere, either to a new bug specifically for it (which may be in this dependency tree) or probably a better place would be one of newsgroups.
ok, i've filled Bug 598337 since it's an important bug from my point of view. Thanks
Depends on: 613259
Shouldn't this bug have a blocking status? That way, the dependent bugs would not all need separate landing approval.
blocking2.0: - → ?
Depends on: 614692
Depends on: 608555
(In reply to comment #55) > Shouldn't this bug have a blocking status? > > That way, the dependent bugs would not all need separate landing approval. No, meta bugs cannot be blockers.
(In reply to comment #55) > Shouldn't this bug have a blocking status? > > That way, the dependent bugs would not all need separate landing approval. Actually, upon thinking on this that is a really dumb idea because anyone could then mark anything as being dependent on this just to get a free a+. I think a better Idea would be for the bug owner to go through the dependency list and mark the bugs that are really wanted as blocking 2.0.
(In reply to comment #57) > (In reply to comment #55) > > Shouldn't this bug have a blocking status? > > > > That way, the dependent bugs would not all need separate landing approval. > > Actually, upon thinking on this that is a really dumb idea because anyone could > then mark anything as being dependent on this just to get a free a+. > > I think a better Idea would be for the bug owner to go through the dependency > list and mark the bugs that are really wanted as blocking 2.0. But then, it is owned by nobody ... sigh :-(
blocking2.0: ? → ---
Sorry, this is already described in bug 613259 and I should whine here too, but I read that Firefox 4 is going to be released in February and if the bug isn't fixed it's going to wait for months until Firefox 4.1, 4.5, 5 or whatever gets released. This: 4. Inactive Tab - Use window color at -20% luminance and saturation and 90% opacity. Alternatively get GTK theme inactive tab color at 90% opacity. Overlay gradients, edge effects, borders and shadows. Another possibility would be to use ThreeDShadow as a base color with gradient overlays. is a problem. You should just pick the inactive color from the theme, I suppose that you're using "window color at -20% luminance and saturation and 90% opacity" but even if you're not doing that, whatever it is you did doesn't work.
Depends on: 635897
No longer depends on: 635897
No longer depends on: 544819
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
No longer depends on: 572485
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: