Community
Participate
Working Groups
ToolBarManager contains a logic to turn of redraw if the toolbar entries are above a certain limit. I think we should remove the logic because it makes the code a bit more complex and I see no advantage of not doing it for a small number of items. See https://git.eclipse.org/r/#/c/39353/3/bundles/org.eclipse.jface/src/org/eclipse/jface/action/ToolBarManager.java,cm Line 304 boolean useRedraw = (clean.size() - (mi.length - toRemove.size())) >= 3;
Andrey, what do you think?
(In reply to Lars Vogel from comment #0) > ToolBarManager contains a logic to turn of redraw if the toolbar entries are > above a certain limit. I think we should remove the logic because it makes > the code a bit more complex and I see no advantage of not doing it for a > small number of items. You mean we should always set setRedraw(false) before starting TB manipulations? I have no experience in that area, no idea if this can cause any regression. But BTW I've seen Paul had some bugs related to the non-refreshing toolbar buttons - might be this is somehow related?
(In reply to Andrey Loskutov from comment #2) > But BTW I've seen Paul had some bugs related to the non-refreshing toolbar > buttons - might be this is somehow related? Maybe. Could you find the bug numbers?
See bug 432856
New Gerrit change created: https://git.eclipse.org/r/42052
New Gerrit change created: https://git.eclipse.org/r/46053
(In reply to Eclipse Genie from comment #6) > New Gerrit change created: https://git.eclipse.org/r/46053 Sorry, forgot to press ammend commit. Correct one is https://git.eclipse.org/r/#/c/42052/
Gerrit change https://git.eclipse.org/r/42052 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=692712ce5fb6f604ed4905254329f29c069feb2e
Fixed. See Bug 465353 for more work here.
Created attachment 253885 [details] introduced rendering problem The last commit has the side effect that simple trim widgets (like http://stackoverflow.com/a/10331418) registered via the org.eclipse.ui.menus extension point were no more rendered correctly. If I remove the last commit everything looks fine. I have attached a screenshot that shows the rendering problem in our RCP application.
(In reply to Dominik G. from comment #10) > Created attachment 253885 [details] > introduced rendering problem > > The last commit has the side effect that simple trim widgets (like > http://stackoverflow.com/a/10331418) registered via the org.eclipse.ui.menus > extension point were no more rendered correctly. > If I remove the last commit everything looks fine. I have attached a > screenshot that shows the rendering problem in our RCP application. Which platform? Please attach an example RCP application which demonstrates the problem.
Created attachment 253916 [details] Sample RCP Product I have attached a sample product that has two trim widgets. One in the main toolbar that has a text control and one in the status line that has a combo control. My platform is Windows 7 (64bit), Java 8 (64bit), eclipse 4.5RC1.
Created attachment 253917 [details] Sample RCP Product
I am seeing the same regression on Windows 7 with an Eclipse (IDE) plugin on Mars.1 that used to work correctly on Kepler. With this change, our trim bar control contribution gets a fixed height of 7 pixels, which makes it unusable. Reverting this change returns it to the previous fixed height of 22 pixels (which is not ideal either, but acceptable). Since the change looks reasonable, it seems like this might only have worked by chance before. However, I have not been able to figure out where the 7 pixels come from that appear to be caused by the additional WM_SETREDRAW Windows messages caused by this change. I am wondering why the SWT ToolBar is implemented using a Win32 Toolbar at all, as that just seems to result in a whole bunch of quirks and limitations.
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.
The original context of this bug was fixed by the commits. The regression of caused by this bug, or the behavior it uncovered, is also reported as Bug 471313.
