Bugzilla – Full Text Bug Listing
| Summary: | Linux themes: Background of part without input should not change when (de-) activated | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dani Megert <daniel_megert> |
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | akurtakov, Lars.Vogel, markus.kell.r, mistria |
| Version: | 4.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=546673 | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 544446 | ||
|
Description
Dani Megert
I fully disagree with that change and I'd be curious to read objective reasons why this is a bad thing. Please read https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg06708.html and other comments about theme before reverting something users enjoy. > On 3.x the darker / grey background was used to indicate that a part
currently has no input, but we never changed the background when
(de-)activating a part. Otherwise, the user can no longer match a background
color to a state.$
By state you mean whether it as input or not? If so, I have the impression that what users want to easily find is which part has focus, not much if there is input. Also, whether a part has an input or not can easily be guessed from its actual content, no need for a color.
(In reply to Mickael Istria from comment #1) > I fully disagree with that change and I'd be curious to read objective > reasons why this is a bad thing. > Please read > https://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg06708.html and > other comments about theme before reverting something users enjoy. Sorry, Mickael but this is really a completely useless and off-topic link. Where does it say something about parts with input? It is a completely generic statement. So, for me useless in this context. > By state you mean whether it as input or not? Yes, of course. That was the 3.x design where we still had designers that were capable of making such (good) decisions. > If so, I have the impression that what users want to easily find is which part > has focus, not much if there is input. You are disagreeing with yourself. The proposed change in bug 325937 was introduced a different color for that state. You liked that change. Now you question it. Please, before your next comment, take a step back, look at the problem and make comments that don't contradict which each other. > Sorry, Mickael but this is really a completely useless and off-topic link. Where does it say something about parts with input? It is a completely generic statement. So, for me useless in this context. I just want to make sure that your proposal to restore some legacy behavior in Eclipse IDE doesn't contradict with current user expectations. We've had pretty good feedback about this GTK theme, and no complaint except yours. You can understand I am defensive against changing it for dogma reasons just as much as you are defensive against changing the GTK theme. (In reply to Dani Megert from comment #3) > You are disagreeing with yourself. The proposed change in bug 325937 was > introduced a different color for that state. You liked that change. Now you > question it. Please, before your next comment, take a step back, look at the > problem and make comments that don't contradict which each other. To be honest, as a user, I never realized whether there is a different state for whether a part has input or not. Either there is interesting content or not is enough as far as I understand. The goal of the change in bug 325837 is to change the active part/stack colors to remove gradients and use a scale of colors to highlight selection/activation. The background is changed by the way in order to have consistency and continuity between the color of the tab and the color of the part. The color was actually not introduced but reused from someplace else. I don't really care about the state when there is no input on a part, what I care most is the regular state with multiple editors and views and having something that clearly highlights the active selected part. All that said, I'm not against change, but I just want to make sure that we place users, usability and prettiness as superior values over legacy. I'd gladly review proposals on this GTK theme with as much objectivity as I can. (In reply to Mickael Istria from comment #4) > > Sorry, Mickael but this is really a completely useless and off-topic link. Where does it say something about parts with input? It is a completely generic statement. So, for me useless in this context. > > I just want to make sure that your proposal to restore some legacy behavior > in Eclipse IDE doesn't contradict with current user expectations. > We've had pretty good feedback about this GTK theme, and no complaint except > yours. You can understand I am defensive against changing it for dogma > reasons just as much as you are defensive against changing the GTK theme. Sure! Point me to feedback about part background regarding parts that have not input. I bet 1 million that you cannot provide any data for this. Bet is open. > (In reply to Dani Megert from comment #3) > > You are disagreeing with yourself. The proposed change in bug 325937 was > > introduced a different color for that state. You liked that change. Now you > > question it. Please, before your next comment, take a step back, look at the > > problem and make comments that don't contradict which each other. > > To be honest, as a user, I never realized whether there is a different state > for whether a part has input or not. Either there is interesting content or > not is enough as far as I understand. I do agree that it we can question whether showing that state us useful, but that is a different topic. > The goal of the change in bug 325837 is to change the active part/stack > colors to remove gradients and use a scale of colors to highlight > selection/activation. The background is changed by the way in order to have > consistency and continuity between the color of the tab and the color of the > part. > The color was actually not introduced but reused from someplace else. > I don't really care about the state when there is no input on a part, what I > care most is the regular state with multiple editors and views and having > something that clearly highlights the active selected part. I agree, but you defended the change that introduces that change for Windows 7. > All that said, I'm not against change, but I just want to make sure that we > place users, usability and prettiness as superior values over legacy. > I'd gladly review proposals on this GTK theme with as much objectivity as I > can. I'm not sure what you mean by "legacy". The 3.x look was just 1000% superior to what we have now because it was designed by designers as a whole. What we have now is a mess. (In reply to Dani Megert from comment #5) > I'm not sure what you mean by "legacy". The 3.x look was just 1000% superior > to what we have now because it was designed by designers as a whole. What we > have now is a mess. I personally think the new styling is way better than the classic one. In general people tend to have very strong opinions about styling, one of the reasons why Eclipse offers both the classic ad the new styling. IIRC the old design had also lots of critics. To quote Paul from https://bugs.eclipse.org/bugs/show_bug.cgi?id=420238#c34 about the classic styling: ----- It's not well designed. It was created the same way this was, and was complained about the same way (it was dubbed the pink shag toilet seat cover of desktop applications). ------ (In reply to Lars Vogel from comment #6) > (In reply to Dani Megert from comment #5) > > > I'm not sure what you mean by "legacy". The 3.x look was just 1000% superior > > to what we have now because it was designed by designers as a whole. What we > > have now is a mess. > > I personally think the new styling is way better than the classic one. Can you please provide concrete arguments. Why is it better to not see whether a part has input or not. Do you have people that said this was good? > ----- > It's not well designed. It was created the same way this was, and was > complained about the same way (it was dubbed the pink shag toilet seat cover > of desktop applications). > ------ I am not sure what that paragraph is meant to be. Is it a citation? The 3.x designed was made by graphic designers, so, if you claim "It was created the same way this was", then you just don't know the history. (In reply to Dani Megert from comment #7) > Why is it better to not see whether a part has input or not. I don't think that "whether a part has input or not" is a clear concept for end-users. Actually, "whether a part has input or not" is already something that end-users won't be able to understand or deal with. Hence, if we agree it's something most users don't get nor care about, it's easier for us to get rid of this constraint. And, no, I didn't found external feedback about it, but I'm still looking (for a million it's worth spending a few minutes or trying to hack some wiki pages :P ). But I agree like you that it's a topic for which we'll probably never have data, so the best thing we can have is our judgement, or user interviews/polls. (In reply to Mickael Istria from comment #8) > (In reply to Dani Megert from comment #7) > > Why is it better to not see whether a part has input or not. > > I don't think that "whether a part has input or not" is a clear concept for > end-users. Actually, "whether a part has input or not" is already something > that end-users won't be able to understand or deal with. Hence, if we agree > it's something most users don't get nor care about, it's easier for us to > get rid of this constraint. Yeah, but why did you promote the change that implements exactly that? > And, no, I didn't found external feedback about it, but I'm still looking > (for a million it's worth spending a few minutes or trying to hack some wiki > pages :P ). But I agree like you that it's a topic for which we'll probably > never have data, so the best thing we can have is our judgement, or user > interviews/polls. Just to make my point clear again: I do not challenge that the new GTK theme is better than the old one. I only challenge the background change for parts that have no input. Whether we get rid of that special "no input" state or whether we get rid of their background change when changing the active part is not that important to me. (In reply to Dani Megert from comment #7) > Why is it better to not see whether a part has input or not. I didn't say that. I was saying I like the current theme better than the classic ones. It sounded to me that you were saying the whole new styling is a mess. If you only referring to the one particular issue, maybe you can clarify that by posing before and after screenshots or windows vrs. Linux. Your issue description is a bit vague to me, as I currently only have a Linux system available. > > ----- > > It's not well designed. It was created the same way this was, and was > > complained about the same way (it was dubbed the pink shag toilet seat cover > > of desktop applications). > > ------ > > I am not sure what that paragraph is meant to be. Is it a citation? The 3.x > designed was made by graphic designers, so, if you claim "It was created the > same way this was", then you just don't know the history. True, I don't know the history. But I was quoting Paul, who was involved in this process that this time. See the bug discussion, Paul said the new design was also made by graphic designers. Don't get me wrong, I also think the initial new design was a mess. Before we fixed Bug 420238, I personally think it was a bad joke. But I really like what we have at the moment for Linux, IMHO is looks way better than the current Windows styling (in general, not necessary with reference to your specific issue, which is still vague to me). (In reply to Dani Megert from comment #9) > (In reply to Mickael Istria from comment #8) > > (In reply to Dani Megert from comment #7) > > > Why is it better to not see whether a part has input or not. > > > > I don't think that "whether a part has input or not" is a clear concept for > > end-users. Actually, "whether a part has input or not" is already something > > that end-users won't be able to understand or deal with. Hence, if we agree > > it's something most users don't get nor care about, it's easier for us to > > get rid of this constraint. > > Yeah, but why did you promote the change that implements exactly that? I didn't change that intentionally. I just changed the colors of tabs according to their selected/focus state and made the part background be the same as tab color for "continuity". I didn't change anything with the intent of dealing with the input/no-input state. Anything that happened with the theme change on this regard is an unexpected (and even unknown) side-effect. Is there smth still pending on this bug ? (In reply to Alexander Kurtakov from comment #12) > Is there smth still pending on this bug ? The bug is still there. Mac and Windows work but Linux themes change color. 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. |