Allow right-click popup menu to be controlled when called

ID:2628747
 
Oct 24 2020, 1:27 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
The client.show_popup_menus var is nice, but it's not sufficient. It'd be nice if we could decide on whether the popup menu shows based on what turf was clicked on (even better if we could actually filter the items to display).

That could be done two ways; either make a DM turf proc that can be overridden on them that could return 0/1 to disallow/allow that specific call for the menu (ideally passing the turf/loc and the menu contents to it). Alternatively it could just be a var *on* the turf that would dictate whether that turf should display the menu (and it would take precedence over client.show_popup_menus).

For our use case I used a workaround where I use the MouseEntered proc to toggle client.show_popup_menus but it's kind of ugly and I assume it's not very performance friendly (maybe someone can comment about that?)

Use case for reference: https://github.com/Aurorastation/Aurora.3/pull/10328
Oct 24 2020, 6:09 pm
A proc could never handle this type of behavior because the client would have to talk to the server first.
Oct 25 2020, 3:54 am
In response to Lummox JR
Lummox JR wrote:
A proc could never handle this type of behavior because the client would have to talk to the server first.

Right, what I mean is, whenever the client tries to pop-up the menu, make it run the proc (just like you make it run a proc when it does a MouseEntered or MouseClick), except here the return code of the proc would be meaningful.

Or, as suggested, just make it a turf variable, that'd be a good enough solution for most use cases I think, and it also wouldn't need to communicate with the server when the click happens. By default null so that it just follows the client variable (and doesn't break existing code), but setting it to 0 would override the client var to 0 and vice versa.

Another thing that comes to mind would be adding a proc to make the menu pop-up by a server request; that way we could have it disabled, but capture a MouseClick (right) and make it pop-up on demand that way. This would be great in addition to making it a turf variable.
Oct 26 2020, 9:33 am
In response to Amju
Amju wrote:
Lummox JR wrote:
A proc could never handle this type of behavior because the client would have to talk to the server first.

Right, what I mean is, whenever the client tries to pop-up the menu, make it run the proc (just like you make it run a proc when it does a MouseEntered or MouseClick), except here the return code of the proc would be meaningful.

The problem is that you're introducing client-server communication into the mix, and there would be a delay every single time. You have to send a message to the server, wait for it to be processed, and wait for a response. This is a small amount of time but you do not want this in a menu.

There's some degree of this now for command expansion in an input control, but that comes up less often.

Or, as suggested, just make it a turf variable, that'd be a good enough solution for most use cases I think, and it also wouldn't need to communicate with the server when the click happens. By default null so that it just follows the client variable (and doesn't break existing code), but setting it to 0 would override the client var to 0 and vice versa.

I think there's actually a feature request for a var of this sort already, come to think of it.

Another thing that comes to mind would be adding a proc to make the menu pop-up by a server request; that way we could have it disabled, but capture a MouseClick (right) and make it pop-up on demand that way. This would be great in addition to making it a turf variable.

Tying in additional server-client communication for menus would not be a good thing. There's also no way to pop up a menu without having system mouse coords (as opposed to translated coords that get sent to the server) so it's not something the server could initiate.
Oct 26 2020, 9:49 am
Your reasons as to not make it a proc absolutely make sense.

If there is a request to have it as a var then I'm sorry, I couldn't find it when checking for similar requests. But I'd be absolutely delighted to have it!

(also I just noticed I used the wrong account to post the other reply, but whatever)
Oct 27 2020, 7:49 am
Actually I realized that making a var on a turf would not be enough as that can't be used per client. What would be required is having that var on /atom, because we can make atoms appear only for some clients.
Oct 27 2020, 11:56 pm
In response to Amunak
I think you're thinking of /image. Turfs are atoms.
Oct 30 2020, 2:21 am
No I did mean atoms - just all atoms, not only turfs.

Though having it on /image would probably work just as well.
Nov 29 2020, 12:15 am
I can think of a few ways to do what they want a little better.

One, iirc the client gets told about what atom levels to send mouse_over calls to to avoid unneeded network traffic, that same system, looking at what right click procs are defined could work, only issue is i think clicks go through all the same proc.

Two, appearance flags.

Three, compromise and allow specifying a modifier to switch behavior, ie, if say, popup_modifier_key is set to "alt", and show_popup_menus is set to TRUE, then while alt is held right clicks go to the procs. even add support for specifying any modifier, so you can default to the right click menu except when a modifier is held down.

/tg/ would likely get use out of the third system, we would make it so alt has to be pressed to bring up the normal context menu, and then use right click for various actions.
Nov 30 2020, 4:01 pm
In response to MrStonedOne
MrStonedOne wrote:
Three, compromise and allow specifying a modifier to switch behavior, ie, if say, popup_modifier_key is set to "alt", and show_popup_menus is set to TRUE, then while alt is held right clicks go to the procs. even add support for specifying any modifier, so you can default to the right click menu except when a modifier is held down.

/tg/ would likely get use out of the third system, we would make it so alt has to be pressed to bring up the normal context menu, and then use right click for various actions.

You actually can do #3 right now in 513. Add a macro for the alt key down and up events, that just uses the .winset command to turn right-click to true or false on your map control. (You'd also have to set right-click to true for the map control if you want to use the normal context menus only when Alt is held.)

Alt
.winset :map.right-click=false
Alt+UP
.winset :map.right-click=true