[wingide-users] IDE "Run marker" and "Stop" button behavior
initcontact at grahamwideman.com
Tue Nov 19 16:39:19 MST 2013
Brief addition to this item:
If/when you revisit the "run marker" appearance, I wonder if you could address this detail point:
When the run marker stops at a breakpoint, the pink arrow is hidden by the red breakpoint circle. The pink highlighting of the line of source text is visible, but it's a bit disconcerting that the arrow is missing, as though the pink highlighting means something else.
Anyhow, it would be great if the breakpoint circle and run marker arrow could appear simultaneously, like with the arrow in front of the circle (in z-order), or maybe a smaller circle.
At 11/1/2013 06:23 AM, Wingware Support wrote:
>Graham Wideman wrote:
>>I'm enjoying a pretty smooth experience with WingIDE 5 (well done Wingware!).
>>But I want to comment on the behavior of the debug "run marker" and the "stop debugging" button in WingIDE5.0, as they do a couple of things that don't seem quite right to me. (However, there's some possibility I'm missing something due to my modestly revised color scheme.)
>>The UI elements of interest:
>>"Run marker": Highlighted line of code, and right-pointing arrow in the left margin. Both colored pink for me.
>>"Stop debugging" button: on the toolbar in the "Debug group", appears and disappears according to context.
>>The two odd behaviors are these:
>>1. When I run the code in the IDE, and there's a error, the run marker is set to the line with the error. Sometimes the Stop Debugging button appears, sometimes not.
>>The difference appears to be whether or not the error is one that a static syntax analysis would catch. If it is a "static" syntax error, then no "Stop debugging" button appears, suggesting that debugging is not actually in progress. But that is confusing, as the remaining debug buttons are still available ("Continue (or start running)", "Run to current cursor position", "Step into current execution point".)
>>I am pretty sure that in this "syntax error" case, the "run marker" actually does not indicate the/a current execution point. So the visible debug buttons will proceed from the start of the program, not from the run marker. If that surmise is correct, then it would be helpful for the indicator to*not* look like it's showing the execution point.
>>2. When the error is a "runtime" error (like divide-by-zero error), then the run marker stops at the culprit line, and the "Stop debugging" button does appear. However, hitting the "Stop debugging" button does not remove the run marker. So again the user sees a visual state that doesn't coincide with the program state. There's a visual indication of where execution is, yet execution is not at that location.
>>Now, there is a case for maintaining some indication on the culprit line, as the error message is still visible in the Exceptions window, and usefully so. However, I think the line indication in that condition should no longer look like the "run marker".
>Both of these are a result of a design decision to leave the exception in place after stopping debug and letting the Exceptions tool "own" the run marker and thus not remove it until the exception is cleared from its Options menu or otherwise.
>I agree this could be clearer, and it would be helpful to show variants for when it's a syntax error or when the debugger has been stopped. I will add this to our list of improvements to look at making in the future.
>Wingware | Python IDE
>Advancing Software Development
More information about the wingide-users