About Dialog Keypress Toggles/esc/clicking To Close

[SneaksieDave]

This was first raised in 105 and since that's now closed, I just wanted there to be a place to possibly discuss further.

 

There are several ways to approach the issue of opening and closing the floating dialogs in the editor. DoomEd works by allowing most dialogs to be toggled on/off with a press of the same key twice. OrbWeaver raised the valid issue that this is not always desirable because there is word typeahead for many dialogs. Then there is the option to close them all with Esc (like DoomEd). Greebo raised a valid point against ESC, in that many times you want the dialog to stay up while you work on, for instance, different brush faces or light entities. Finally, there is the option to always be required to click to close a dialog (puke).

 

I think with all of these angles considered, the best option is to allow the keypress toggle functionality to remain, as long as they are/remain remappable. This way, the user is able to change the light editor from J to Alt-J, if they so choose; such a shortcut, chosen well, won't get in the way of typeahead, it won't close when attempting to deselect (with ESC) and select another light, and it can still be opened and closed without a mouseclick. And ultimately, it's left up to the user whatever they prefer.

[OrbWeaver]

You know you can do Alt-O to activate the OK button (I think)? I tested this when I was implementing the ESC shortcut for the Light Inspector.

 

Assuming this does work (or can be made to work if it isn't set up correctly), are remappable shortcuts that important?

[SneaksieDave]

In my opinion, the shortcuts (and thus the ability to toggle with same keypress) are of utmost importance. My main mode of operation is: go to fullscreen (or not), open dialog make changes, press key again, move on. If suddenly I'm pressing ESC and having it disappear instead of deselecting the face/entity (as greebo pointed out and converted me to), or having it not close with ESC (because of above) but falling behind my maximized cam, but not being able to toggle the same keypress and instead having to keep hitting Okay even when I just want the action cancelled or the dialog closed... yeah that'd be aggravating. When it does fall behind the cam, I just tap S, S and it's back. With alt-O (or the less friendly ESC), it's "where's the dialog? okay. S. Nope. Alt-O. Is it gone? Maybe. S. Yep, it's back." Prefer to just quickly tap S, S.

 

IMO the way it works right now is best, and even a step above DoomEd. S to open, S to close. Don't like S, because it interferes with typeahead? Then make it Alt-S. Done. Left up to user preference. Sorry, being long winded (just trying to explain this side thoroughly). The short answer: Yes, to me it's that important. It's important enough that if it were removed, I'd probably try to go through the code myself to re-enable it for myself.

 

Edit: I'm wondering, why not remappable shortcuts? The func is there for everything else, so why specifically disable it for these dialogs? It's consistent, and the most user-friendly method.

[OrbWeaver]

Edit: I'm wondering, why not remappable shortcuts? The func is there for everything else, so why specifically disable it for these dialogs? It's consistent, and the most user-friendly method.

 

Greebo can probably answer that better than I can, since he worked on the shortcut system. If it is fairly simple to implement what you suggest and does not interfere with the in-dialog navigation/typeahead, then I don't have a problem with it.

[greebo]

Sorry, what do you exactly want to have? The LightInspector being toggle-able by hitting "J"? That could easily be done.

[New Horizon]

Sneaksies preference sounds good to me as well. I quite enjoy the current functionality.

[OrbWeaver]

Sorry, what do you exactly want to have? The LightInspector being toggle-able by hitting "J"? That could easily be done.

 

Basically for arbitrary dialogs to respond to the same shortcut that was used to trigger them (which is configurable by the user) so that they can be closed. I guess the dialog would have to hook into the EventManager in some way.

[SneaksieDave]

Yeah basically the way it is now (for surface props, texture tool, entity list, etc - they already work this way). But with definable shortcuts, if they're really necessary so as not to interfere with typeahead. That part wasn't my concern originally, but it's a good point.

 

The only thing I know of which doesn't currently work this way is the light inspector (J to open, ESC to close). I'll confirm and see if I can find others, of course. Apologies if I worded this over-complex. Trying to find the right balance of "detailed enough" vs. "rambling" is tough for me.

[greebo]

Yeah, that's fairly easy.

 

First step is to implement a toggle() method of the dialog that does the actual toggling.

 

Second step is to create a command like this:

GlobalEventManager.addCommand("ToggleLightInspector", <Caller>)

 

Third step is to connect the dialog window via:

GlobalEventManager().connectDialogWindow(GtkWindow* lightInspectorWidget)

in the LightInspector constructor. That's it. All shortcuts that are not caught within the dialog window itself will be propagated to the "background" windows.

[OrbWeaver]

OK, I will look into this for the Light Inspector.

 

Once the dialog is connected with that second statement, does it have to be disconnected when hidden in order to avoid still catching shortcuts, or is this unnecessary?

[greebo]

It's not necessary. Only focused widgets will catch keypresses in the first place. You'll have to disconnect it on destruction though.