Bugzilla – Full Text Bug Listing
| Summary: | [Progress] Progress view heights are inconsistent | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Mike Wilson <Mike_Wilson> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | RESOLVED INVALID | QA Contact: | Prakash Rangaraj <prakash> |
| Severity: | normal | ||
| Priority: | P3 | Keywords: | helpwanted |
| Version: | 3.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mike Wilson
both issues are the result of deliberate design decisions: - the background coloring is done is a way so that the background color of the last item is always the darker color, so that the remaining space of the view (following the last item) automatically gets the view's default background color. - the vertical height cannot be made fixed because a job group can have any number of jobs, and each job gets its own task line in the progress item. I spoke with several people about the first issue. Some of them had not noticed the behavior, but when I pointed it out to them, they all agreed that the coloring should stay consistant (i.e. first item should always be white). Essentially, the presentation should be similar to a sheet of leger paper, where the colors stay in the same positions, while the items move. Please fix, or escalate. As to the second item, it's unfortunate that the size grows, since this (again) breaks the metaphore that you are seeing "rows on leger paper". This is not how it looks on the Mac, for example. In any case, this doesn't explain why we allow them to become *smaller* than the single job case. I suppose, if they are going to change size anyway, it's probably worth saving the space. Oh well. Re #1: What color should I use for the empty space at the end of the view? - the default view background color (will match color of last item in 50% of all cases) - the correct color (will result in a potential large empty area with non-default background color). The effect I was looking for was something like you see in the Safari "Downloads" window: The colors continue to alternate for as large as you resize the window, and each band is a fixed size. It's not as clear what to do if the bands change size, however. One possibility would be to use a "grey'ed out" color choice of some kind. I'm not sure which would be appropriate though. Maybe "COLOR_TITLE_INACTIVE_BACKGROUND" or even simply "COLOR_DARK_GRAY". [not Mac specific; setting Hardware & OS to All] *** This bug has been marked as a duplicate of 115683 *** I think you may have made a typo. This bug and bug 115683 do not sound like duplicates. Thanks Amy *** This bug has been marked as a duplicate of 115863 *** Reopening I am renaming this as I have broken off the part about the colors being set incorrectly to Bug 137784. There is a third issue here - that of the choice of colour we are making. McQ do you want me to create another bug for that? I'm mostly interested in seeing the problem identified in the original problem description fixed. I'm not particularly fussed by the color choices. (In reply to comment #12) > I'm mostly interested in seeing the problem identified in the original problem > description fixed. I'm not particularly fussed by the color choices. The original problem is fixed. The top color is always the dark color now. This bug no longer valid for 3.5 |