Menu Support

ID:132718
 
Dec 6 2009, 4:15 pm
I would like to see support for font play in right click menus
as well as sub-menus. (I know this has been suggested before)

http://img525.imageshack.us/img525/9673/sugg.png

Currently the menus show as <b>name...</b>
or as ÿ┤name...ÿ┤ if used \b \b in set name.
Dec 6 2009, 4:17 pm
I'm not sure I follow what you're asking about fonts; the screenshot you posted doesn't really explain that.

As for sub-menus, we already do have support for that. Sub-menus can be created at runtime.

Lummox JR
Dec 6 2009, 4:19 pm
In response to Lummox JR
See how "Send an instant message" is bolded?
something like that. er (Default action) I guess you could say..
Dec 6 2009, 4:27 pm
In response to Lummox JR
Is there a tutorial for sub-menu's? I just searched the forums couldn't find anything.

Would be nice to create them at compile time using a format similar to:

set name="menuname/subitemname"

or even

set name="subitemname"
set group="menuname"
Dec 6 2009, 4:45 pm (Edited on Dec 6 2009, 4:51 pm)
In response to Leur
Kaioken posted an example in this forum within the last week or two. You need to search harder :P

Maybe he didn't post it after all. I can't seem to find it either; regardless, all you need to do is create a list, use list2params(), and then use winset(). It must be documented somewhere.
Dec 6 2009, 4:55 pm
In response to Jeff8500
and then use winset().

What if I want it in context menus <.< which is what I am suggesting it for. (right-click)
Dec 6 2009, 4:58 pm
In response to Leur
Oh, then I misunderstood you (and it seems like Lummox did too). There is no way to do that, as far as I know.
Dec 6 2009, 5:09 pm
In response to Jeff8500
Thus why it is in the suggestions ;p
Thanks for trying to help me though if I did mean the other way.
Dec 6 2009, 7:25 pm
In response to Leur
I don't understand how this would be used in context menus. Right-click menus right now are just a list of atoms and their associated verbs. How would multi-level menus be used there?

Lummox JR
Dec 6 2009, 7:58 pm
In response to Lummox JR
Organization.

Normal
-> Normal Verbs
Admin
-> Admin Verbs
a.t.o.m
-> atom specific verbs

This would be a great feature if one wished to group verbs together, eliminating lengthy lists.

If I'm not clear with how I speak I'll make a demo when I get out of school tomorrow.
Dec 6 2009, 8:02 pm
In response to Leur
The right-click menu is done by DS automatically, so to organize verbs it'd have to be told by the server somehow what category each went in. That seems like a lot to modify for the sake of organization. But for right-click menus I think adding a bunch of sub-menus would really only frustrate users, because it's adding extra actions to get to the command you want.

Lummox JR
Dec 7 2009, 7:34 am
In response to Lummox JR
Lummox JR wrote:
The right-click menu is done by DS automatically, so to organize verbs it'd have to be told by the server somehow what category each went in. That seems like a lot to modify for the sake of organization. But for right-click menus I think adding a bunch of sub-menus would really only frustrate users, because it's adding extra actions to get to the command you want.

True, but sometimes submenus can be helpful. ie. to separate Administrative commands from commands regular players can use.

I think it should be possible to completely override the right-click menu and what goes on inside of it. To achieve this, a special list could be used. This list would be internal like BYOND's main list, and it can only be modified with a winset()-like proc.

This proc would allow you to add and remove menu components and add submenus at will. The moment this is used the new system should be used, otherwise it should fall back to the default of listing verbs.

The following parameters could exist for these menu components:
- parent: The parent menu to follow. Leaving this blank deletes the menu, setting this to "menu" will make the primary right-click menu its parent.
- is-default: This may only be set on a single control. If set, this option will be in bold. Usually people who set this want to set the "command" argument below to the .click or .dblclick command so it will carry out the left-click action (which is the default).
- command: Specifies the command to use. .click and .dblclick may freely be used in here. \ref[src] will be converted internally to refer to the object itself, so setting this to "myverb \ref[src]" will cause the "myverb" verb to be executed as part of the src object.
- is-disabled: If set, the button is greyed out.
- is-checkable: If set, this button can be checked, just like an ordinary menu.
- is-checked: If set, this button is checked (if checkable). Otherwise, it is not.

Being able to define right-click menus yourself is something which can turn out to be very helpful. Administrative commands can end up in a sub-menu, and the use of is-checked allows you to immediately see if a particular state is true. For example, I could place a menu item called "Density" in an "Admin" submenu which is checked if the item has density. Clicking it toggles density.

In order to make the system really useful, it would be neat if atoms had a RightClickMenu() proc of some kind. The result of this proc can be either null (to display the default right-click menu), a positive value (which tells BYOND you're handling it by yourself and to skip displaying the default menu) or an associative list which builds up the menu.

Sample usage:
obj
    lightswitch
        name = "Lightswitch"
        desc = {"This button operates a nearby light.
        Clicking on it will toggle the light. Right-clicking will display a list of actions."}
        var
            state = 1 //0: off; 1: on
            locked = 0 //1: the lightswitch cannot be toggled
        RClick(location, control, params)
            var/list/L = list(
                "mnuToggle" = list(
                    "is-default" = "true",
                    "is-checkable" = "true",
                    "is-checked" = "[state ? "true" : "false"]",
                    "is-disabled" = "[locked ? "true" : "false"]",
                    "name" = "Toggle",
                    "command" = ".click \ref[src]" //\ref[src] gets translated internally
                )
            )
            
            if(usr.isAdmin())
                L["mnuAdmin"] = list("name" = "Admin")
                L["mnuAdminLocked"] = list(
                    "parent" = "mnuAdmin", //a lack of parent causes the main menu to be used;\
                        in this case we want a submenu, so we specify it
                    "is-checkable" = "true",
                    "is-checked" = "[locked ? "true" : "false"]",
                    "name" = "Locked",
                    "command" = "\ref[src] lock" //executes the "lock" verb of this object
                )
                L["mnuAdminDelete"] = list(
                    "parent" = "mnuAdmin",
                    "name" = "Delete",
                    "command" = "admin-delete \ref[src]" //executes the "admin delete" verb (which the player\
                                needs access to) with src as an argument
                )
            return L
        Click(location, control, params)
            if(!locked && (usr in oview(1, src)))
                state = !state
                usr << "\icon[src] The light switch is now [state ? "on." : "off!"]"
                ... //update the area to reflect change in luminosity
        verb
            lock()
                set hidden = 1
                if(usr.isAdmin()) locked = !locked
    computer
        communications
            name = "Emergency Communications Console"
            desc = {"This control panel operates a link between this base and the main HQ.
            Clicking on it will open up the control panel."}
            /*
            RClick(location, control, params)
                return null
            //RClick default action: display the right-click menu we're all used to
            */
            Click(location, control, params)
                if(usr in oview(1, src))
                    //display a control panel
                    usr << browse("&lt;insert control panel here&gt;", "window=\ref[src]")
    antenna
        name = "Communications Antenna"
        desc = {"This is one of the four antennas that controls the communications of this base.
        Clicking it will show the current status of the antenna. Right-clicking it will manually disable the antenna."}
        var
            online = 1
        Click(location, control, params)
            if(usr in oview(5, src))
                usr << "\icon[src] This antenna is [online ? "online" : "offline"]."
        RClick(location, control, params)
            if(usr in oview(1, src))
                online = !online
                usr << "\icon[src] The antenna is now [online ? "online" : "offline"]."
            return 1

admin/verb
    admin_delete(atom/O)
        set src in world
        del O
mob/proc/isAdmin() return 1


I think this system would be better than the current system, which is an "opt-in or opt-out" method: you can either go with it and change right-clicking for all objects, or you can leave it alone for every object.

The system as mentioned above would be versatile, allowing developers to change right-clicking on a per-object basis.

Since the RClick() proc in my example shares the same access to variables that the other mouse procs have access to, I could even check the map we're on and act accordingly. Thus I could show different menus for the same atom depending on whether the atom is shown on the main map or in a secondary map, or even in a grid.