Community
Participate
Working Groups
Created attachment 213825 [details] Screenshot showing the poor redrawing CDT provides a feature to allow to do reverse debugging (step backwards). When reverse debugging is possible, CDT makes visible 4 new buttons on the debug toolbar: "reverse step into", "reverse step over", "reverse resume", and "uncall" (reverse step return). This small howto shows screenshots of the buttons and how to enable them: http://wiki.eclipse.org/CDT/User/FAQ#How_do_I_do_Reverse_Debugging.3F The problem is that when the 4 new buttons become visible (or invisible), the view toolbar does not redraw properly to make room (or remove room) for the new buttons. After resizing the view, the toolbar is redrawn nicely. Attached is a screenshot showing: 1- the normal toolbar 2- the proper toolbar with the extra buttons after a resize of the view 3- the error where buttons were hidden and the view toolbar has extra space 4- the error where buttons were made visible and the view is truncating buttons If I can help get more information, please let me know.
OK, we expect org.eclipse.ui.internal.e4.compatibility.ActionBars.updateActionBars() to re-layout the CTabFolder and all of its children, but we might not be picking the correct composite. Marc, which build did you use? PW
Eric, when org.eclipse.ui.internal.e4.compatibility.ActionBars.updateActionBars() is called we need to re-layout the CTabFolder for that part stack. Right now it's just guessing at a parent, we probably shouldn't do that. Any suggestions? PW
(In reply to comment #1) > Marc, which build did you use? Sorry, I should have mentioned that. I'm using the latest I-build: I20120321
Little detail that may or may not be useful. If I select anything outside the debug view, the toolbar redraws properly; re-sizing the debug view or selecting something outside of it fixes the problem.
Paul, the MPartStack's widget is the CTF, no guessing required. If you have already changed the size of the toolbar (i.e. through 'pack') then a 'layout(true, true)' on the CTF should do the trick. If not get back to me and I'll get together with Bogdan...
Changing to M7 as this should be a quick code fix... Also, we could add a size change listener to the TB so that when the 'pack' changes its size we can force the layout. Is there a way for me to see this without having to install CDT ??
(In reply to comment #6) > Is there a way for me to see this without having to install CDT ?? I tried to find another action set that enables buttons on a view toolbar but I couldn't quite find one. The only ones that I know of are in CDT (then again, I only really know CDT...).
Eric, to reproduce we just have to have a view that when asked directly adds or removes IContributionItems from getViewSite().getActionBars().getToolBarManager() and then calls getViewSite().getActionBars().updateActionBars(). I should be able to give you a reproducible test case tomorrow. PW
(In reply to comment #8) The debug view does this now: open the view menu and select "Show Debug Toolbar". However this works as expected. The action that marc is referring to doesn't call update action bars directly. Instead it calls the IEvaluationService.requestEvaluation() on a property that it modified. I'll see if I can get the handler to call updateActionBars() rectly.
It seems that it won't be enough to try to update action bars just for the location where the handler was called. I can make a simplified example of what the CDT reverse debugging commands are doing using the PDA debugger example in platform, if that will make it simpler to debug.
(In reply to comment #9) > The action that marc is referring to doesn't call update action bars directly. > Instead it calls the IEvaluationService.requestEvaluation() on a property that > it modified. I'll see if I can get the handler to call updateActionBars() > rectly. Oh, are these contributed through org.eclipse.ui.menus with a core expression? Then we should be handling that ourselves (just in a slightly different location). PW
(In reply to comment #11) > (In reply to comment #9) > > The action that marc is referring to doesn't call update action bars directly. > > Instead it calls the IEvaluationService.requestEvaluation() on a property that > > it modified. I'll see if I can get the handler to call updateActionBars() > > rectly. > > Oh, are these contributed through org.eclipse.ui.menus with a core expression? Pretty much, but with a little more steps in between using definitions. Here is the xml, if it helps. Definition of the reverse-resume button: <extension point="org.eclipse.ui.menus"> <menuContribution locationURI="toolbar:org.eclipse.debug.ui.DebugView?after=threadGroup"> <command commandId="org.eclipse.cdt.debug.ui.command.reverseResume" icon="icons/obj16/reverse_resume.gif" label="%ReverseResume.label" style="push"> <visibleWhen checkEnabled="false"> <reference definitionId="org.eclipse.cdt.debug.ui.testIsReverseDebuggingEnabled"> </reference> </visibleWhen> </command> </menuContribution> which uses the following definition: <definition id="org.eclipse.cdt.debug.ui.testIsReverseDebuggingEnabled"> <and> <reference definitionId="org.eclipse.cdt.debug.ui.testIsReverseDebuggingActionSetActive"> </reference> <with variable="debugContext"> <iterate ifEmpty="false" operator="and"> <test property="org.eclipse.cdt.debug.ui.isReverseDebuggingEnabled"> </test> </iterate> </with> </and> </definition> which uses the following property: <extension point="org.eclipse.core.expressions.propertyTesters"> <propertyTester class="org.eclipse.cdt.dsf.gdb.internal.ui.actions.ReverseDebuggingPropertyTester" id="org.eclipse.cdt.dsf.gdb.ui.selectionReverseDebuggingTester" namespace="org.eclipse.cdt.debug.ui" properties="isReverseDebuggingEnabled" type="org.eclipse.cdt.dsf.ui.viewmodel.datamodel.IDMVMContext"> </propertyTester> So, in the java code, we sometimes need to refresh this isReverseDebuggingEnabled property and we use: IEvaluationService.requestEvaluation("org.eclipse.cdt.debug.ui.isReverseDebuggingEnabled")
(In reply to comment #10) > It seems that it won't be enough to try to update action bars just for the > location where the handler was called. I can make a simplified example of what > the CDT reverse debugging commands are doing using the PDA debugger example in > platform, if that will make it simpler to debug. Yes, that would make it much easier to debug, thanks Pawel. If I had to guess, I would say the new logic in EvaluationReference#evaluate(..) might be causing problems. I'll work with Pawel to get a simple example of the problem and dig deeper.
Created attachment 214154 [details] Example to reproduce the problem. Well well, I refactored the CDT reverse toggle enablement logic as to do something equivalent with the platform PDA example: instead of toggling reverse debugging actions, this one toggles visibility of the restart action. The only problem is that my patch works! The action appears/disappears as expected. Not sure if this is good news or bad news, but as an example of the bug, it's a failure :-(
(In reply to comment #14) > Created attachment 214154 [details] > Example to reproduce the problem. Thanks! > The only problem is that my patch works! The action appears/disappears as > expected. Not sure if this is good news or bad news, but as an example of the > bug, it's a failure :-( Good news is that for me, when I try your example, things break as they do for CDT. I start the PDA debugger then I press the new "enable restart" button and nothing happens, then I click somewhere else, and the restart button appears. I'm using I20120411-2034 and the latest (just did a fetch) plaform debug code from git. Pawel, do you see the problem with CDT reverse toggle or is it something with my own environment?
(In reply to comment #15) > Pawel, do you see the problem with CDT reverse toggle or is it something with > my own environment? Yes, I see the problem with reverse debugging buttons, so I was rather surprised that the example didn't work. I also sometimes see painting artefacts where the toolbar icons paint over the menu triangle, but not with the example.
(In reply to comment #16) > (In reply to comment #15) > > Pawel, do you see the problem with CDT reverse toggle or is it something with > > my own environment? > > Yes, I see the problem with reverse debugging buttons, so I was rather > surprised that the example didn't work. I also sometimes see painting > artefacts where the toolbar icons paint over the menu triangle, but not with > the example. I see the triangle being painted over with the example and I see the extra empty space when the button is removed with the example. BTW, I'm on Ubuntu 10.4 with GTK 2.20.1. I also see other redrawing problems that I reported in Bug 376633.
Good news, the situation is much better when I use I20120429-1800. In truth, everything seems ok except a little flicker when the redrawing is done. During that flicker, I can see the view menu triangle appear for a split second in the wrong place, and then everything is ok. I'm not sure if you want to keep the bug open for that, but from a CDT point-of-view, the problem is fixed. Thanks!
(In reply to comment #18) > Good news, the situation is much better when I use I20120429-1800. > > In truth, everything seems ok except a little flicker when the redrawing is > done. During that flicker, I can see the view menu triangle appear for a split > second in the wrong place, and then everything is ok. > > I'm not sure if you want to keep the bug open for that, but from a CDT > point-of-view, the problem is fixed. > > Thanks! Thanks for reporting back Marc, I will mark this bug fixed. The toolbar flicker you describe sounds a lot like bug 364975.
