[wingide-users] Suggestion: Breakpoint button behavior
initcontact at grahamwideman.com
Mon Nov 25 15:48:53 MST 2013
Responses inline below...
At 11/25/2013 07:47 AM, Wing IDE Support wrote:
>On 11/24/13 12:59 AM, Graham Wideman wrote:
>>However, after hitting Stop, while moving over to hit Run, the toolbar goes through two repaints, in which the Breakpoint button disappears, the remaining buttons shift left (modifying my targeting of the mouse toward the shifted Run button) and then as I approach the shifted Run button, the Breakpoint button reappears at the Run button location, shifting the Run button right. If I'm not anticipating this I end up hitting the Breakpoint button that has just replaced the Run button. Grrrr.
>Is the issue here that the toolbar is slow to be repainted and thus distracting?
Yes, if the repaint was faster, or there was no intermediate repaint, then the problem wouldn't be so severe.
FWIW, I think I have a machine with speedy CPU and graphics card, so I'm pretty sure that slow repaint is not an issue of outdated hardware. And when I say "slow repaint", it's probably not the "painting" per se, but rather lag in calculating the new UI state.
Also, I've noticed this lag is longer on some projects (perhaps with larger files showing in the editor?) than others.
And I'd say the effect is not so much "distraction" as frustration in attempting to hit buttons that are a moving target. (This against a backdrop of considerable satisfaction with most of the IDE!)
> The breakpoint, run, run to cursor buttons don't change positions when all of the drawing is finished (this is by design).
The *order* of the buttons stays the same, but the absolute positions of the buttons definitely does change according to state. And in the scenario mentioned, after hitting Stop, the UI goes through two states, the first of which hides the Breakpoint button, and the second reinstates it.
> That said, a preference for always displaying all of the debug tools might be helpful. We would retain the current behavior -- I (& probably others) use the changing toolbar to see if the debugger is running or not.
In the "display all buttons" design, the toolbar would still change according to state -- some buttons would be grayed out in different states.
Presumably it's the state of the Stop button that's the biggest cue for "debugger running"? Currently, the Stop button appears and disappears. I, for one, would favor all the buttons being present, so that the Stop button "indicator light" for "debugger running" is always present, and indicates not only "debugger running" but is also there to indicate "debugger not running" (grayed out).
More information about the wingide-users