Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing option for hiding the new debug launcher from the statusbar #37954

Closed
fabiospampinato opened this issue Nov 9, 2017 · 15 comments
Closed
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded
Milestone

Comments

@fabiospampinato
Copy link
Contributor

v1.18.0 introduced a statusbar item for launching a debug session, I already use my StatusBar Debugger extension (below in the second rectangle in red) and I want to hide the included one because it's useless and broken:

pn

  1. If one uses the debugger only via shortcuts it's wasted space.
  2. Unless I already started a debug session, the item is hidden. I guess it has been introduced to avoid switching to the debug view, but I have to do it anyway for starting the debugger the first time.
  3. If I click it, even if I have a single debug configuration, it asks me to pick one.
  4. If the debug session is already started, clicking it again doesn't stop it. You may think that this is the intended behavior, but I usually only have one debug configuration anyway, why would I start it again?
  5. It displays the name of the debugging session, which is useless if I only have one configuration. Currently it's always useless since I still have to select the debug configuration to use manually anyway, and once I selected it I guess I know which one I picked, I don't want a reminder.
  6. The chosen start symbol looks too big and out of place, there's already a start symbol in octicon, why didn't you use it instead? (In the screenshot above you can see that my extension uses it and it's arguably better looking).

Please, give us an option for hiding it 🙏

@vscodebot vscodebot bot added the debug Debug viewlet, configurations, breakpoints, adapter issues label Nov 9, 2017
@weinand weinand assigned isidorn and unassigned weinand Nov 9, 2017
@isidorn isidorn added the feature-request Request for new features or functionality label Nov 9, 2017
@isidorn isidorn added this to the Backlog milestone Nov 9, 2017
@isidorn isidorn removed their assignment Nov 9, 2017
@fabiospampinato
Copy link
Contributor Author

@isidorn I'm sorry if I insist, but isn't the 1st point of my list a good enough reason for fixing this?

@weinand
Copy link
Contributor

weinand commented Nov 10, 2017

@fabiospampinato thanks for the feedback. We will start a discussion about how to proceed.

@isidorn isidorn self-assigned this Nov 14, 2017
@isidorn isidorn modified the milestones: Backlog, November 2017 Nov 14, 2017
@isidorn
Copy link
Contributor

isidorn commented Nov 14, 2017

@fabiospampinato thanks for the feedback. I have reduced the size of the icon slightly so the size aligns well with the warning / errors size. If I go too small that will not be the case.
I have introduced an option debug:showInStatusBar: ['never', 'always', 'onFirstSessionStart'] with the last one being the default.

As for your other points I do not agree since then it would not align nicely with the typing debug in quick open and you could not add a new configuration via the status bar.

@weinand had a great suggestion that this all could be done using an extensoin. So why not give that a try @fabiospampinato. If the extension works great I would be more than happy to remove the debug status bar if I get the blessing from @egamma

@weinand
Copy link
Contributor

weinand commented Nov 14, 2017

@fabiospampinato Just to be clear: removing our debug status bar support would require that its most important feature "showing the current launch configuration" would be covered by your extension (and that you would provide a setting for turning off all your other buttons ;-) )

@isidorn
Copy link
Contributor

isidorn commented Nov 14, 2017

I think it would be better to have 2 seperate extensions imho

@fabiospampinato
Copy link
Contributor Author

fabiospampinato commented Nov 14, 2017

@isidorn I don't know if this is true for everyone, but I usually edit the debug configurations when I create a new project, and then basically never touch them again. While on the other hand I may start a debugging session tens of times, this is the use case the statusbar item should optimize for imho. Adding a Debug: Add Configuration... command to the command palette sounds like a better solution to me.

@weinand Sounds great, I'll work on this tomorrow. Btw it would be awesome if we could expose more state/methods via APIs (#30810), such as:

  • Pause state: so that the extension can fade out the step over/into/out buttons and hide the play/pause button when appropriate.
  • Number of configurations: so that one can choose to let the extension run the only configuration available if there's only one, and make it us pick one if there are more than one.
  • If the current debugging session is compound, so that a button can be shown for switching session.
  • Support for switching session in a compound session programmatically. Other than being required by the previous item on this list it would also make it possible to configure a keybinding for switching session, which would make things a bit faster compared to clicking the select element in the floating viewlet (if one hides it via the settings, for good reasons Debug actions pane often blocks file names #2513, I'm not even sure it's possible to switch session anymore):

screen shot 2017-11-14 at 23 45 53

@isidorn
Copy link
Contributor

isidorn commented Nov 15, 2017

@fabiospampinato wow there cowboy. I think most of those are valid API requests. However I would take this one step at a time. To get a the current behavior you have everything you need, just using quick pick to type Debug
If you want to go fancy and do different behavior based on content of launch.json you can always use nodefs to read the content of the launch.json file. So this could cover your 2nd and 3rd request.
Your 1st request would mean exposing the running / stopped state in the debugSession which I think makes sense.

@fabiospampinato
Copy link
Contributor Author

@weinand @isidorn I've just published a new version of the extension, this is how to make it look like the included statusbar item:

  • "statusbarDebugger.actions": [], this hides all the extra buttons such as pause/continue/etc.
  • "statusbarDebugger.template": "$(triangle-right) [name]", by default the bug icon is used, since the tringle-right icon is used for the continue action. With this setting the bug will be replaced by the triangle.

There are some differences though:

  • It's displayed even before the first debug session has started
    • Because hiding it doesn't really make sense to me
  • By default the executed action when clicking it follows a different logic:
    • If a debug session is active, it will trigger workbench.action.debug.stop
    • If there are no configurations, it will trigger debug.addConfiguration
    • If there's only one configuration, it will trigger workbench.action.debug.start
    • If there are more than one configuration, it will trigger workbench.action.debug.selectandstart
    • But if for whatever reason you prefer to always select the configuration just set "statusbarDebugger.command": "select". Clicking it while debugging will still stop the session, just click it again if you want to start a new session. I don't see the point of not stopping the session.
  • The name of the session is only displayed when it starts
    • By default your statusbar item always displays what's active on the select element in the sidebar, even if the active session is another one, I wouldn't call this "showing the current launch configuration". My extension instead displays what's actually active.
    • It doesn't display any name when the session stops. I'd like to fix this, but I think there's no API for getting the name that's selected on the select element in the sidebar. I've tried listening for onDidChangeActiveDebugSession but I don't think it has anything to do with the select element.

I'd love to make it better, but for doing so I think I need those extra APIs I mentioned.

What do you think?

@sandy081
Copy link
Member

sandy081 commented Dec 5, 2017

@isidorn What has to be verified here?

@isidorn
Copy link
Contributor

isidorn commented Dec 5, 2017

@sandy081 that there is an option to hide the debug status bar

@sandy081
Copy link
Member

sandy081 commented Dec 5, 2017

Yeah, just figured that out by searching in settings. Would be happier if it was mentioned here :)

@sandy081 sandy081 added the verified Verification succeeded label Dec 5, 2017
@sandy081
Copy link
Member

sandy081 commented Dec 5, 2017

@isidorn What is the difference between the options onFirstSessionStart and always?

@isidorn
Copy link
Contributor

isidorn commented Dec 5, 2017

@sandy081 always should always showw the debu status. OnFistSessionStart should only show the debug status after the first debug sesison was started (thus not spamming users who do not care about debugging)
If you think the description is not precise enough let me know if you have a suggestion on how to improve

@sandy081
Copy link
Member

sandy081 commented Dec 5, 2017

I think you can add description for each enum value. May be it is worth adding above description for the value OnFistSessionStart ?

@isidorn
Copy link
Contributor

isidorn commented Dec 5, 2017

@sandy081 thanks, tackled via a3366bb

@vscodebot vscodebot bot locked and limited conversation to collaborators Dec 29, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality verification-needed Verification of issue is requested verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

4 participants