Bugzilla – Full Text Bug Listing
| Summary: | local toolbar icons and pane controls (such as min/max) should be at 50% opacity when inactive | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] e4 | Reporter: | Susan McCourt <susan> | ||||||||
| Component: | UI | Assignee: | Project Inbox <e4.ui-inbox> | ||||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | Bogdan Gheorghe <gheorghe> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | azerr, bokowski, gheorghe, s.muecke | ||||||||
| Version: | 1.0 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Bug Depends on: | 320584 | ||||||||||
| Bug Blocks: | 293481 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Susan McCourt
(In reply to comment #0) > This bug summarizes the things we need to do to get tab rendering looking like > what's in the mockups. > > - currently we show a solid color in the selected tab stack, and we need to > switch to the gradient in the latest mockups. Working correctly in I20100706-2130 > - tab font should be larger than the default size (investigate antialiasing) The font is bigger now in I20100706-2130. However, on Win7, the font used is incorrect. It should be picking up the default (Segoe UI) and is instead using something that looks like Arial or Tahoma > - deselected tab stacks have vertical separator lines around the selected tab The separator lines for the selected tab are not showing. > - hovering over deselected tab stacks should cause the hovered tab to appear Working correctly in I20100706-2130 Created attachment 173711 [details]
screenshot
mismatched fonts on win7 for view tabs
I'm just catching up with some screenshot reviews Linda did. These are items that I still believe to be true. Note that I'm not saying these are critical to ship, but I want to review where we are and if stuff can be tweaked per styling or layout, we could attempt... per Linda's review of 20100615 win7 screenshots (the ones I still think are true) - shadows on sides are darker than on bottom. bottom should be darkest. Are shadows transparent? per Linda's review of 20100707 screenshots: - local toolbar icons and pane controls should be at 50% opacity when inactive, then switch to 100% - Mac only - active stack keyline is blue on exterior editor, should be same as the keyline on the bottom of tabs (in the hue of the active stack bar, the warm grays) we should look into the font problem Created attachment 174920 [details]
Screenshot depicting the problem in question.
You can see that 3.7 is slightly "thicker". At least, it looks that way to me anyway.
On Windows 7, we use Arial for the tabs but Segoe UI everywhere else (like we should). Created attachment 174933 [details]
patch
This is not a full solution but it should be good enough for 4.0.
There are two issues that need to be solved:
1. On Windows 7, if you don't specify anything about fonts for tabs (not even the font size), you get Segoe UI. By specifying just the font size, you get Arial.
2. As you switch between style sheets, things like font-family, if set by one theme but not mentioned by another, you will get the specified font when you switch to that theme, but the font will never change back. (You can also see this when you try to switch from the default to classic.)
What's similar about 1. and 2. is that we need defined default values for everything, or else you'll get random results.
(In reply to comment #7) > There are two issues that need to be solved: I meant to say: there are two unresolved issues that we will need to address for 4.1. (In reply to comment #7) > There are two issues that need to be solved: > 1. On Windows 7, if you don't specify anything about fonts for tabs (not even > the font size), you get Segoe UI. By specifying just the font size, you get > Arial. > 2. As you switch between style sheets, things like font-family, if set by one > theme but not mentioned by another, you will get the specified font when you > switch to that theme, but the font will never change back. (You can also see > this when you try to switch from the default to classic.) > > What's similar about 1. and 2. is that we need defined default values for > everything, or else you'll get random results. What I think is needed is that the CSS code that gets the font queries the default system font and uses its defaults for any font attributes that aren't specified. In other words: if the stylesheet simply says font-size: 9 the query should not just look for the first 9 point font it finds. That is what gives us random results. It needs to query the default system font and then fill in the font metrics with any values overridden by the stylesheet. So that on win7, if Segoe UI is the default font, you'd always get facename Segoe UI if you didn't specify it. And then move to another platform and you get whatever its facename is. The font query needs to be explicit even if the stylesheet is not. (Note I'm saying all this based on knowledge of OS fontmetrics and what I've seen in the past, I haven't looked closely at the CSSSWT code but I suspect this is the nature of the problem). I spun off bug 320584 for the font problem, and we can use this bug to discuss the general problems with implementation vs. mockup. We probably want to spin off another bug for the font face issue in CSS/SWT. (comment 9) *** Bug 320588 has been marked as a duplicate of this bug. *** The real problem is the styles reset of the CSS engine. I had tried to explain the problem into the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=308940#c1 And I had created this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=298081 to give propositions to manage correctly styles reset . But it's a big refactoring! I'm waiting Bogdan decision. Regards Angelo I think there are multiple problems being discussed here. - general issues where the new look doesn't match the mockups on the tabs (this original bug) - the fact that changing stylesheets doesn't change the font. Sounds like Angelo has documented issues in bug 298081, but note that we have other issues of being not dynamic due to the way we use styling info (For example, the margin support we added for TrimLayout in bug 312842 isn't dynamic either - so if you switch between classic look and any other look the margins don't change until you restart.) - the fact that if you don't specify a font face, it is not using the platform default font face. (In reply to comment #13) > I think there are multiple problems being discussed here. > - the fact that changing stylesheets doesn't change the font. opened bug 321050 to collect info about things that don't change dynamically. > > - the fact that if you don't specify a font face, it is not using the platform > default font face. opened bug 321051. > - general issues where the new look doesn't match the mockups on the tabs (this > original bug) > This bug tracks places where we have not yet implemented the mocked up design. - tab font should be larger than the default size For example, on Win7 we are using Segoe UI 9, and it should be 10. We couldn't make this change because the gradient math leaves an extra white line in the tab space. (See https://bugs.eclipse.org/bugs/attachment.cgi?id=174997) - deselected tab stacks shoulhave vertical separator lines around the selected tab is now covered in bug 320894 - shadows on sides are darker than on bottom. bottom should be darkest. Are shadows transparent? - local toolbar icons and pane controls (such as min/max) should be at 50% opacity when inactive, then switch to 100% - Mac only - active stack keyline is blue on exterior editor, should be same as the keyline on the bottom of tabs (in the hue of the active stack bar, the warm grays) Per implementation review, these were fixed for 4.0 final.. - shadows on sides are darker than on bottom. bottom should be darkest. Are shadows transparent? - Mac only - active stack keyline is blue on exterior editor, should be same as the keyline on the bottom of tabs (in the hue of the active stack bar, the warm grays) Retitling bug to reflect the remaining issue. - local toolbar icons and pane controls (such as min/max) should be at 50% opacity when inactive, then switch to 100% The CTabFolder can accomplish this because it does the drawing itself, but the toolbar is drawn by the platform toolbar. To do this, we would have to draw the images internally with a different alpha and then reset them into the toolbar when the active stack changes. *** Bug 320527 has been marked as a duplicate of this bug. *** This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword. |