Can't Open Devtools with Dialog Open

[TuckerWhitehouse]

Open a Dialog (About, Extension Manager, etc) and then choose Debug > Show Developer Tools.

Expected Result: Devtools Opens (In Chrome)
Actual Result: Nothing Happens

Mac OS X 10.8.4

I kind of assume this is "expected" behavior based on how the dialogs are intended to work, but not expected based on how the UI is shown.

[TomMalbran]

You can't run any command besides the ones used by the Dialog when a Dialog is open. So it does make sense that you can't use it. But it doesn't make sense that you can open the menus and click on the items which do nothing.

Not sure what would be the best here. Disable opening all the menus, or just disable the commands that don't make sense when the dialog is open and show them disabled in the menu.

[RaymondLim]

These two pull requests adobe/brackets-shell#268 and https://github.com/adobe/brackets/pull/4341will disable all the menu items when a dialog is open.

[TuckerWhitehouse]

Understandable, albeit an inconvenience. Would be nice if certain commands could be executed anyway (Like Brackets > Quit...).

I think the clearest way to do it would be to disable all of the menu items that can't be executed (rather than the menu's themselves) and have a way of executing certain functions regardless of if a Dialog is open (Brackets > Quit, Debug > Show Dev Tools, etc).

[njx]

Yup - our menu commands in general aren't disabling themselves when they're not appropriate. We have an icebox item for this - https://trello.com/c/yMTclKIs/435-198-infrastructure-for-enabling-disabling-commands-as-a-brackets-developer-i-need-an-infrastructure-for-enabling-and-disabling-c - we should fix this before 1.0. I'll send mail to @adrocknaphobia.

Closing as move to backlog.

[peterflynn]

@TuckerWhitehouse For dev tools in particular, you can always get to them by manually going to http://localhost:9234/ in Chrome. This is useful while a dialog is open, or any time you manage to get Brackets too hosed for menus to work.

In terms of keeping some menu items enabled in general while dialogs are open, it's hard to guarantee they'd work right. For example, what happens if Quit needs to show an unsaved changes confirmation? What if you're already in the middle of such a confirmation (either from Close or an earlier Quit) when Quit is invoked? What if you invoke Quit while you have unsaved edits in some other sort of dialog -- does quitting imply canceling it, or Ok'ing it first? Etc. So I think we're unlikely to allow menu use while you're in a modal dialog, but that's pretty consistent with native apps too (for all the same reasons).

[TuckerWhitehouse]

@peterflynn, thanks for the tip!

As for keeping some menu items enabled, there are a few which don't affect the state of the current Brackets window (Debug > Show Developer Tools, Debug > New Window, Help > anything) so I think still being able to execute some commands could be useful.

As for Quit, I think it should function the same as when I right click on the Dock icon and choose Quit (If no dialog is open, and there are unsaved changes, show the dialog prompting for change, in any other case, just quit.) And this same behavior could be applied to the Debug > Reload Brackets command.

The default could be to disable all of the menu items, and then have certain menu items be able to override this behavior. In TextEdit for example, if you have unsaved changes, and choose "Quit", it shows the Save dialog, and disables most of the menu items, but other menu items are still active (New, Open, etc) and functional.