Bugzilla – Bug 376
";debugflags trace" has no effect when the plug-in has a dialogue
Last modified: 2019-04-08 07:47:15 UTC
The optional Audacity/Nyquist plug-in header ";debugflags trace" is only partially functional on Windows and does not work at all on Linux. http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#debugflags
(In reply to comment #0) On looking again, this may not be a bug. ;debugflags trace appears to work for plug-ins that have no ;control lines, but not for plug-ins that have any user interaction.
Roger changed the debug behaviour in r10785: http://code.google.com/p/audacity/source/detail?r=10785 when he fixed a bug where as soon as the Debug button was used, the plug-in remained in Debug mode. His intention was that ;debugflags trace should have no effect if there was a dialogue box - i.e. in a plug-in that has a dialogue, you must use the Debug button to use Debug mode. If you recall our Forum discussion, we both agreed to ask Roger if he could make it so that ;debugflags trace always runs Debug even if OK is used in the dialogue. Roger agreed to change to this behaviour, providing of course he could do it without re-introducing the bug. I think the bug is valid, because fixing it makes it far easier for plug-in developers to work on the code. I've added Roger to the Cc's so he can give us his current view.
Maybe I'm missing something. It seems to me that if there is a dialog offering either Debug or OK, and you want to Debug, you would click Debug. If you decide not to click Debug, why would you be surprised that OK does not do the same thing as Debug? On the other hand, it should not be too difficult to give precedence to ;debugflags trace (effectively making Debug and OK do the same thing) (or maybe OK should be disabled?) I don't think it's a big deal and there are reasonable arguments for either behavior.
(In reply to comment #3) <<< It seems to me that if there is a dialog offering either Debug or OK, and you want to Debug, you would click Debug. If you decide not to click Debug, why would you be surprised that OK does not do the same thing as Debug? >>> I totally agree with that logic, which is why I thought that this may not be a bug, but from a previous conversation with Gale I thought that the intended behaviour was that ";debugflags trace" should take priority over the "OK" button. There are occasions when it would be useful to be able to force the Debug window, even if the "OK" button is pressed. One example that immediately comes to mind is the "Apropos" plug-in. It would also be useful for any plug-in that outputs text that the user may want to copy. (Windows can not copy text from the normal text output screen). My preference would be that ";debugflags trace" should take priority so that the OK and Debug button will effectively do the same. I would definitely not want the "OK" button to be disabled as I'm certain that doing so would confuse many users.
(In reply to comment #3) Thanks, Roger. I just collided with Steve's reply. I don't think greying OK when ;debugflags trace" exists is that bad an idea in principle IF this feature is only for developers, and documented. However, one of the good practical effects of OK also debugging is that you can just hit ENTER to make it work. This helps productivity if you are having to debug dozens of times. And certainly, adding ;debugflags trace" but it having no effect at all in a dialogue plug-in (which most are) just doesn't seem right.
Assigned to myself as it relates to my plug-in button changes. Current behaviour as of today: 1) The debugflags header has no net effect for plug-ins that have a UI, as it is _always_ overridden in UI plug-ins by which button is pressed. That is: (i) If the OK button is clicked, mDebug is 'false'. (ii) If the Debug button is clicked, mDebug is 'true'. 2) For plug-ins that don't have a UI: When the header ";debugflags trace" is included, mDebug is set to 'true' when the headers are parsed, and the debug window will open, but note that plug-ins are cached (the headers are parsed only on first run unless the plug-in has been modified). When processing is completed, mDebug is reset to 'false', and because the header is not re-parsed, mDebug remains 'false' and the debug window does not open on subsequent runs. Additional note: Regardless of this header, the bool value of *tracenable* may be set in the plug-in code, but the state of *tracenable* is unrelated to whether the debug window opens or not. *tracenable* just controls whether XLISP generates a backtrace when an error is encountered. It has no relevance to how the plug-in behaves, or where error messages are sent. When *tracenable* is false, error messages may still be generated, but no backtrace. When *tracenable* is 'true', a backtrace is generated if there is a Nyquist error. Upshot: A) The documentation is wrong http://wiki.audacityteam.org/wiki/Nyquist_Plug-ins_Reference#debugflags B) The current behaviour is imo, confusing and not really useful. To 'Fix' this bug, we need a logical and useful way to handle plug-in debug information, that is correctly documented.
Debug behaviour changed in https://github.com/audacity/audacity/commit/b6a1ca916b88f Documentation still required.
(In reply to Steve Daulton from comment #7) Documentation now completed: https://wiki.audacityteam.org/wiki/Nyquist_Plug-in_Headers#functional_headers
Updated steps to reproduce to match the intended behaviour.
(In reply to Steve Daulton from comment #9) Testing on W10 with audacity-2.3.2-alpha-219-9ba023d607cb8a79cdf90c9b0ef9dec9af98e6a9 Following the Stepsw to reproduce - the debug window opens with "Hello World"
(In reply to Steve Daulton from comment #9) Testing on macOS 10.14.4 with James' latest Mac build of 06Apr19 Following the Steps to reproduce - the debug window opens with "Hello World"
As this isn't platform dependent, and Peter has confirmed that it works as stated on Windows and Mac, I'm closing this as Fixed.
