Community
Participate
Working Groups
Created attachment 120412 [details] screencast of the behavior. Build ID: I20081211-1908 Steps To Reproduce: To validate this, I made a screencast of the build, which is totally reproducible. Create a workspace with the PDE code Project > Clean, clean all and rebuild. More information: I reported this under PDE not because it's the pde source but because it's building plug-ins. Watch the attached screencast carefully. You can see that the build If you would like to see a larger screencast, with a view of the full workbench, let me know. But really, this is the only interesting part.
cc'ing Mike and Olivier as the change in total ticks appears to happen at the end of the api tooling builder.
Re-assigning for investigation.
Testing on our Mac I found that the progress works as expected, any total work reassigned does not affect the progress bar as shown in the video. I did notice that if I make the view very small and the scroll widget needs to be drawn, the progress bar is resized to show the additional widgets (what is perceived as a regression in progress) - the video show this as well, whenever the vertical scroll widget is shown the bar appears to shrink. marking as worksforme.
That seems a little suspect. What is the explanation for the discrepancy between your experience and my video?
(In reply to comment #4) > That seems a little suspect. What is the explanation for the discrepancy > between your experience and my video? > (from comment 3) > - the video show this as well, whenever >the vertical scroll widget is shown the bar appears to shrink. As I stated, the bar appears to shrink when the vertical scroll widget is drawn. If I shrink the view in such a way as to cause the scroll widget to be shown / not shown I can reproduce your experience.
Ah! OK! I hadn't ever noticed the scroll widget. So you know, the screencast was not the first time I saw the behavior. I made the view particularly small just to control the movie's byte size. But now I can see that that the PDE team is not guilty of bad progress monitor management. Whew! Still, I don't like the appearance of the scroll bar impacting the widget, though. It is misleading, and I think it merits reopening this bug and reassigning it to the team that owns the progress view. Can you recommend where I reassign it?
(In reply to comment #6) > Still, I don't like the appearance of the scroll bar impacting the widget, > though. It is misleading, and I think it merits reopening this bug and > reassigning it to the team that owns the progress view. Can you recommend where > I reassign it? > You could try SWT, but without a snippet that demonstrates the problem they will likely just close the bug. CC'ing Kevin in case there are any outstanding known issues with the progress view for Mac OS X.
Thanks. I've assigned to Platform / UI (hope that's correct!) Anyone no longer interested, please feel free to unsubscribe yourself from updates.
Interesting. I wouldn't have noticed that right away, either. Since the progress view is building the widgetry and electing to use progress bars along with a vertical scrollbar, this is a platform UI problem vs. SWT. I don't recall if there's a style bit for keeping the scroll bar static. If we did that, though, we'd get bugs for "why is there a scroll bar there when I don't need it?" There may be a layout trick we can do so that the progress bar won't expand/shrink as the scroll bar gets added (ie, a dummy widget next to it that absorbs the extra space??)
*** This bug has been marked as a duplicate of bug 378255 ***
