Bugzilla – Full Text Bug Listing
| Summary: | [CSS] No separation between view toolbar, view description and view content | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Michael Valenta <Michael.Valenta> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andrea.guarinoni, daniel.rolka, daniel_megert, emoffatt, Lars.Vogel, markus.kell.r, Michael_Rennie, Mike_Wilson, overholt, remy.suen, sudol.wojciech, thatnitind |
| Version: | 4.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 430872 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Michael Valenta
No, you haven't. Oops, sorry. I guess I didn't attach the image. Unfortunately, I changed laptops since I logged the issue but it should be pretty obvious if you look at a view with a description in 3.7 and 4.1 that the 4.1 presentation is different in a way that I would claim is not as good as how it was done in 3.7. *** Bug 350233 has been marked as a duplicate of this bug. *** (In reply to comment #3) > *** Bug 350233 has been marked as a duplicate of this bug. *** See bug 350233 for images. *** Bug 366836 has been marked as a duplicate of this bug. *** *** Bug 369508 has been marked as a duplicate of this bug. *** I've pushed a change to get the separator back. http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=391d4d71a020048e9b8586486fca0ed72ba8afbf (In reply to comment #7) > I've pushed a change to get the separator back. > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=391d4d71a020048e9b8586486fca0ed72ba8afbf This goes into the right direction. The separator after the toolbar is still missing though. See attached screenshot for the Java Outline view. Created attachment 210563 [details]
Picture of confusing Outline due to missing separator
Created attachment 214338 [details]
Separator still missing sometimes
The separator is now only missing if the view has a toolbar, has no description, and the toolbar is shown below the tab folder.
Created attachment 239605 [details]
Consistency would be good, but...
Please see the this screenshot. While views behaving consistently is a worthy goal, I have reservations about the direction suggested to be taken here. I don't want to see more useless lines added to the UI. If some must be added then there needs to be a way to turn them off in CSS.
I've prepared the initial patch for it - https://git.eclipse.org/r/#/c/23535/ Currently the user is able to modify the 'e4 default' theme with the preference dialog so maybe we should skip this bug in order to avoid the regression in the 'e4 default' layout. Daniel (In reply to Daniel Rolka from comment #12) > I've prepared the initial patch for it - https://git.eclipse.org/r/#/c/23535/ > > Currently the user is able to modify the 'e4 default' theme with the > preference dialog so maybe we should skip this bug in order to avoid the > regression in the 'e4 default' layout. I'm not sure I understand this. Is it just the user can modify it, and that would cause a regression for them? If they do it themselves, I'm not that worried about it. PW (In reply to Paul Webster from comment #13) > (In reply to Daniel Rolka from comment #12) > > I've prepared the initial patch for it - https://git.eclipse.org/r/#/c/23535/ > > > > Currently the user is able to modify the 'e4 default' theme with the > > preference dialog so maybe we should skip this bug in order to avoid the > > regression in the 'e4 default' layout. > > I'm not sure I understand this. Is it just the user can modify it, and that > would cause a regression for them? If they do it themselves, I'm not that > worried about it. > > PW I was thinking about the regression in the layout connected to the new patch - to see the separation I had to replace the 'white' color of the selected MPart with the 'blue' or 'olive' color. I think the users got used to lack of separation so I'm not sure if we should fix it Daniel (In reply to Daniel Rolka from comment #14) > (In reply to Paul Webster from comment #13) > > (In reply to Daniel Rolka from comment #12) > > > I've prepared the initial patch for it - https://git.eclipse.org/r/#/c/23535/ > > > > > > Currently the user is able to modify the 'e4 default' theme with the > > > preference dialog so maybe we should skip this bug in order to avoid the > > > regression in the 'e4 default' layout. > > > > I'm not sure I understand this. Is it just the user can modify it, and that > > would cause a regression for them? If they do it themselves, I'm not that > > worried about it. > > > > PW > > I was thinking about the regression in the layout connected to the new patch > - to see the separation I had to replace the 'white' color of the selected > MPart with the 'blue' or 'olive' color. I think the users got used to lack > of separation so I'm not sure if we should fix it > > Daniel Maybe regression is not proper word here, let's call it the change in the layout Daniel (In reply to Daniel Rolka from comment #14) > > I was thinking about the regression in the layout connected to the new patch > - to see the separation I had to replace the 'white' color of the selected > MPart with the 'blue' or 'olive' color. I think the users got used to lack > of separation so I'm not sure if we should fix it I was fine with fixing this, so that there is at least some border between the 3 areas. Just because we're used to it doesn't mean it's not clear :-) PW Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=87ce6024139c8ae949d7fe5c33a417ab2c3e4c0b We can still tweak this during the RCs. (In reply to Dani Megert from comment #17) > Fixed with > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=87ce6024139c8ae949d7fe5c33a417ab2c3e4c0b > > We can still tweak this during the RCs. Gack, I think that that's horrible (I'm sure others might like it :-). But mostly because it doesn't match the color palette I see with gtk. What if we made the gradient start with a lighter blue and end with a lighter blue, even if only on GTK? Also, because the disabled active tab is darker at the top and lighter at the bottom, would it make sense to reverse the active tab gradient and make it lighter on the bottom and darker on the top? PW (In reply to Paul Webster from comment #18) > (In reply to Dani Megert from comment #17) > > Fixed with > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > > ?id=87ce6024139c8ae949d7fe5c33a417ab2c3e4c0b > > > > We can still tweak this during the RCs. > > Gack, I think that that's horrible (I'm sure others might like it :-). But > mostly because it doesn't match the color palette I see with gtk. What if > we made the gradient start with a lighter blue and end with a lighter blue, > even if only on GTK? > > Also, because the disabled active tab is darker at the top and lighter at > the bottom, would it make sense to reverse the active tab gradient and make > it lighter on the bottom and darker on the top? > > PW Paul, yes, this was a first commit, basically to bring some movement into this. Please go ahead and just either tweak the basic theme or the one for GTK. (In reply to Dani Megert from comment #19) > Paul, yes, this was a first commit, basically to bring some movement into > this. Please go ahead and just either tweak the basic theme or the one for > GTK. I'm also OK to move the change from basic to win7 only. What about http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=a90f84fa0d4c9a86c770bbb2e3028e3e38906ba9 ? It's lighter, I think it doesn't jump out as much. I kept the lighter to darker order because the END value is used to draw around the view. You can revert it if it's not quite what you're looking for, or tweak it again :-) PW (In reply to Paul Webster from comment #21) > What about > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=a90f84fa0d4c9a86c770bbb2e3028e3e38906ba9 ? > > It's lighter, I think it doesn't jump out as much. I kept the lighter to > darker order because the END value is used to draw around the view. > > You can revert it if it's not quite what you're looking for, or tweak it > again :-) > > PW I was planning to use the similar colors working on the Bug 325937, but it was rejected - see Comment 16 Daniel (In reply to Daniel Rolka from comment #22) > I was planning to use the similar colors working on the Bug 325937, but it > was rejected - see Comment 16 https://bugs.eclipse.org/bugs/show_bug.cgi?id=325937#c16 Daniel We have to also define the new colors for the 'active.noFocus' state or at least copy the 'active' state ones. Currently it looks strange (the 'active.noFocus' state gets rendered with the white color) Daniel Created attachment 242456 [details]
Screenshot of the progress view.
With the recent changes (I20140428-2000) some views look bad. At least with Windows 7 theme.
Empty and selected Outline view is all blue.
Progress view - the same, except the "No operations to display at this time." label which has white background - see screenshot.
Help View - see screenshot.
Created attachment 242457 [details]
Screenshot of the Help view.
Created attachment 242458 [details]
Screenshot of the Outline view.
(In reply to Daniel Rolka from comment #24) > We have to also define the new colors for the 'active.noFocus' state or at > least copy the 'active' state ones. Currently it looks strange (the > 'active.noFocus' state gets rendered with the white color) When does the active.noFocus apply? when the workbench window doesn't have focus? On GTK, it's just white. Created attachment 242464 [details]
The current 'active.noFocus' state
Created attachment 242465 [details] The new 'active.noFocus' state proposal (In reply to Paul Webster from comment #28) > (In reply to Daniel Rolka from comment #24) > > We have to also define the new colors for the 'active.noFocus' state or at > > least copy the 'active' state ones. Currently it looks strange (the > > 'active.noFocus' state gets rendered with the white color) > > When does the active.noFocus apply? when the workbench window doesn't have > focus? On GTK, it's just white. It is the same as in the 'classic' theme - when the selected part loses the focus (after opening the modal dialog, switching to other window, ...) Currently on my Windows 7 it looks like - 'The current 'active.noFocus' state' - for me it doesn't look nice (the mixture of the white color with the blue one) I think it would be better to remove the blue color - 'The new 'active.noFocus' state proposal' Daniel I used it this morning and it's obvious we would have to change lots of other colors to get a consistent look and a lot is currently "tuned" for white color. We also need more time to test on all platforms. Since M7 is already this week, I think it's best to move this to 4.5 and work on a new consistent scheme early in the Mars cycle. I've reverted the changes back to white for now. Maybe we should follow the 'Dark' theme example and adopt some 'White with Blue' theme created by the Community - https://github.com/guari/eclipse-ui-theme Daniel (In reply to Daniel Rolka from comment #32) > Maybe we should follow the 'Dark' theme example and adopt some 'White with > Blue' theme created by the Community - > https://github.com/guari/eclipse-ui-theme Is their a popular 'white with Blue' theme? Maybe Andrea or others wanted to help directly with our default theme? (In reply to Lars Vogel from comment #33) > (In reply to Daniel Rolka from comment #32) > > Maybe we should follow the 'Dark' theme example and adopt some 'White with > > Blue' theme created by the Community - > > https://github.com/guari/eclipse-ui-theme > > Is their a popular 'white with Blue' theme? I believe it has to be created from scratch. I used the 'White with Blue' phrase in order to point the color palette for the theme. > Maybe Andrea or others wanted to help directly with our default theme? It would be great! Daniel See bug 320901 for the general issue. 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |