Debugger view confused about which editor window to use to show place of interruption
-
In the debugger view offered by Qt Creator, it is possible to choose which windows to display by using the right-click context menu on any of the the title bars, if displayed (otherwise on some of the top bars, like that of the Locals or Expressions windows).
That way, it is also possible to deactivate the editor window altogether. I use this very often in combination with Window > Open in New Window (and then I place that new editor window on my other monitor).
However, the internal debugger logic seems confused as to where to show me the place the execution pointer is currently at, especially when it gets actively placed (on interruption) or moved (when using "Step" or "Next"). If the text file that the execution pointer is in is open as part of the editor in the main window, it seems that the logic will tend to prefer that editor, EVEN IF I HAVE HIDDEN/CLOSED IT. It will forcibly reinsert the editor in that window if needed, even if only as a very thin vertical band (so pretty much useless). I have to at least close the file in that editor, make sure it is open in the editor in my other window, then double-click on the step in the stack view to have the editor in my other window jump to that place while leaving the main window intact.
Also, when re-opening Qt-Creator, it remembers the fact that I have a separate window and opens it for me as it was, and when I run the debugger it also remembers and resurrects the placement of all my debug menus (Stack, Locals, ...). But it will still place an editor in the main window, even though I had closed it.
All this is somewhat annoying, I spend all my time re-closing the useless editor in the main window, and finding workarounds to get the debugger logic to understand that I want to view my stepping action in the editor in my other window.
Is there a fix for that, or a plan for a fix maybe ?
-
In the debugger view offered by Qt Creator, it is possible to choose which windows to display by using the right-click context menu on any of the the title bars, if displayed (otherwise on some of the top bars, like that of the Locals or Expressions windows).
That way, it is also possible to deactivate the editor window altogether. I use this very often in combination with Window > Open in New Window (and then I place that new editor window on my other monitor).
However, the internal debugger logic seems confused as to where to show me the place the execution pointer is currently at, especially when it gets actively placed (on interruption) or moved (when using "Step" or "Next"). If the text file that the execution pointer is in is open as part of the editor in the main window, it seems that the logic will tend to prefer that editor, EVEN IF I HAVE HIDDEN/CLOSED IT. It will forcibly reinsert the editor in that window if needed, even if only as a very thin vertical band (so pretty much useless). I have to at least close the file in that editor, make sure it is open in the editor in my other window, then double-click on the step in the stack view to have the editor in my other window jump to that place while leaving the main window intact.
Also, when re-opening Qt-Creator, it remembers the fact that I have a separate window and opens it for me as it was, and when I run the debugger it also remembers and resurrects the placement of all my debug menus (Stack, Locals, ...). But it will still place an editor in the main window, even though I had closed it.
All this is somewhat annoying, I spend all my time re-closing the useless editor in the main window, and finding workarounds to get the debugger logic to understand that I want to view my stepping action in the editor in my other window.
Is there a fix for that, or a plan for a fix maybe ?
Hi @SuperSelrak,
could you provide a screenshot of how your setup would look like?
From the description (and my understanding) it sounds like a setup that is used and tested rarely. Maybe there is a bug.
Regards
-
Hi @SuperSelrak,
could you provide a screenshot of how your setup would look like?
From the description (and my understanding) it sounds like a setup that is used and tested rarely. Maybe there is a bug.
Regards
@aha_1980 Maybe. I only ended up wit that setup because I could, given what Qt Creator offers - not because I forced it or anything. Here the screenshot.
Left, a separate window on a separate monitor, with just an editor an nothing else.
Right, the main Qt Creator window, here in the "Debug" mode, with the views setup how I often have them (this also just because I did it once and Qt Creator remembered, and remembers any subsequent modifications I make to the setup and always uses that.)Here, if I close the main file, and run with debug again, it will break on the one breakpoint in the main file and will choose to open that file in the main window, contrary to 1. past choices I made and 2. the fact that I asked for the editor to be closed in that window and have another one ready to go (indeed, raring to go) in the other window.
Here, if I open the main file in the editor of the other window, whilst the editor in the main window is closed, and run with debug again, when breaking it will nonetheless choose to reopen the editor in the main window and show me the break location in that editor, again, against all expectations.
Last, if I close the file in the editor of the main window, open the file in the editor of the other window, then run the debugger again, it will switch to debug mode, open an empty editor (or in other context, open the editor as it would be in edit mode, i.e. with the stack of other files that are open - in this case there are no other files open), but will show me the break point in the other window, which is something.
I think, after this small experiment to provide screenshots, that it comes down to two things.
- Qt Creator should remember that I want no editor open in debug mode in the main window (at least, if I have at least one editor open elsewhere that can be used) - i.e. it should remember what I have done with that option in the right-click context menu, like it already does with all other debug views.
- If a file is not open but needs to be when breaking, it should be open in the first available editor (and only if none are available should a new one be opened, and here we could even add : opened in a separate window as per usual - but okay this is slightly off-topic). This is in opposition to the current logic which seems to be : prefer opening the file in an editor that currently has it open, but is hidden - by making it reappear (and actually it already reappeared when last exiting debug mode, and didn't disappear again when debugging again, contrary to expectations). I guess some people would prefer it that way then maybe this is impossible to solve except by a super-niche setting.
At least this behavior was super-easy to observe in a playground project.
Thank you for your time and answers, really useful.
-
@aha_1980 Maybe. I only ended up wit that setup because I could, given what Qt Creator offers - not because I forced it or anything. Here the screenshot.
Left, a separate window on a separate monitor, with just an editor an nothing else.
Right, the main Qt Creator window, here in the "Debug" mode, with the views setup how I often have them (this also just because I did it once and Qt Creator remembered, and remembers any subsequent modifications I make to the setup and always uses that.)Here, if I close the main file, and run with debug again, it will break on the one breakpoint in the main file and will choose to open that file in the main window, contrary to 1. past choices I made and 2. the fact that I asked for the editor to be closed in that window and have another one ready to go (indeed, raring to go) in the other window.
Here, if I open the main file in the editor of the other window, whilst the editor in the main window is closed, and run with debug again, when breaking it will nonetheless choose to reopen the editor in the main window and show me the break location in that editor, again, against all expectations.
Last, if I close the file in the editor of the main window, open the file in the editor of the other window, then run the debugger again, it will switch to debug mode, open an empty editor (or in other context, open the editor as it would be in edit mode, i.e. with the stack of other files that are open - in this case there are no other files open), but will show me the break point in the other window, which is something.
I think, after this small experiment to provide screenshots, that it comes down to two things.
- Qt Creator should remember that I want no editor open in debug mode in the main window (at least, if I have at least one editor open elsewhere that can be used) - i.e. it should remember what I have done with that option in the right-click context menu, like it already does with all other debug views.
- If a file is not open but needs to be when breaking, it should be open in the first available editor (and only if none are available should a new one be opened, and here we could even add : opened in a separate window as per usual - but okay this is slightly off-topic). This is in opposition to the current logic which seems to be : prefer opening the file in an editor that currently has it open, but is hidden - by making it reappear (and actually it already reappeared when last exiting debug mode, and didn't disappear again when debugging again, contrary to expectations). I guess some people would prefer it that way then maybe this is impossible to solve except by a super-niche setting.
At least this behavior was super-easy to observe in a playground project.
Thank you for your time and answers, really useful.
Hi @SuperSelrak,
thanks for the screenshots, now its clear what you want to achive, and it sounds valid to me.
I'd suggest you file a bug at bugreports.qt.io to make the developers aware of this problem. It would also be useful to add a link to the report here, so others can follow the discussion.
Regards
-
Hi @SuperSelrak,
thanks for the screenshots, now its clear what you want to achive, and it sounds valid to me.
I'd suggest you file a bug at bugreports.qt.io to make the developers aware of this problem. It would also be useful to add a link to the report here, so others can follow the discussion.
Regards
@aha_1980 Excellent, noted. Will do. Glad to be part of this active community.
