Jump to content
The Dark Mod Forums

About Dialog Keypress Toggles/esc/clicking To Close


Recommended Posts

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...