Rolling Your Own Menu

Jacek's secret herbs and spices

Have you ever wanted to gather all your favorite and most-used items from Second Life's main menus, and put them all in one place for easy access? Well, you can do exactly that by editing SL's XUI files!

For my own purposes, made a new sub-menu, Builder Tool, which lives under the Tools main menu. In it, I put lots of useful building tools and options that I took from various other menus. Now I can tear off one little menu, and have them close at hand while working! Yay!

I also added two new menu items, for options found in the Edit tool window: Stretch Both Sides and Stretch Textures! Because they are now menu entries instead of checkboxes in the Edit window, I can assign keyboard shortcut keys to toggle them! Double-Yay!

Rather than walk through every step of editing the XML, I'll just point out the important or new things. All the editing is done in menu_viewer.xml, the same file we editted to change the keyboard shortcuts before, but I also referred to floater_tools.xml, as described later in this post.

Creating a new menu is fairly easy: just make (or duplicate and modify) a <menu> block, being careful (of course) to close the block with a </menu> tag. Gathering items from other menus is a simple matter, just copy and pasting each desired <menu_item_*> block into the middle of your new menu block. From what I can tell, the positioning attributes (bottom, left, etc.) are ignored or overridden by SL, so you don't even have to worry about getting those numbers right.

Adding the two new menu items, Stretch Both Sides and Stretch Textures, was not much harder. But in fact, it is only possible because of the particular way that those two options, along with the Snap to Grid/Use Grid option, were implemented; I suspect that they were all once menu items in the past, or were intended to be so. Snap to Grid currently is a menu item in the Tools menu, and it was by examining the XML for the menu item and comparing it to the corresponding checkbox in the Edit window that I discovered that it was possible to do the same with the other two options.

The key is that all three of these options are manipulated by calling the ToggleControl function and passing the control name of the option. Both the menu and the checkbox refer to the SnapEnabled control name: in floater_tools.xml, the Use Grid checkbox has an attribute, control_name="SnapEnabled"; in menu_viewer.xml, the Snap to Grid item has two lines which mention SnapEnabled, once in an <on_click> tag, and once in an <on_check> tag.

Making the two new menu items was just a matter of looking up their control names (ScaleUniform and ScaleStretchTextures) in floater_tools.xml, and plugging them into copies of the Snap to Grid menu item definition in both lines (be sure to change the text labels to be descriptive of their new functions).

Doing a quick grep of the XML files, there are a handful of other miscellanious options which have control_names. This suggests to me that menus could be built to change these too. Some notable example uses are: (un)muting audio; the Copy Selection tool; toggling chat bubbles; toggling avatar names above their heads.

It may also be possible to change other options which are not simple on/off switches. For example, it just might be possible to make a menu item which changes all the render detail settings and draw distance to the minimum, for dealing with crowded areas.

Unfortunately, this dependence on knowing the option's control name means that this method does not allow us to add an "Edit Linked Parts" menu item—the checkbox in the Edit window does not refer to any control name. I still hope that it can be added somehow, but for now it's up to the Lindens.

Happy building!

My XUI Wishlist

There are specific things that I want to accomplish which drive me to poke my nose in SL's XML User Interface (XUI) definitions.

Here are the ones I have already accomplished:

1. Customize some menu shortcuts.
   
2. Rename "Hole Size" to "Thickness".
   
3. Decripple Transparency.

Here are the things I want to accomplish, but are probably impossible through XUI-editing alone:

1. Define keyboard shortcuts to toggle "Edit Linked Parts" and "Stretch Both Sides".
2. Move the color and texture eyedroppers/pipettes from the Color/Texture Selection windows to the Toolbox's Texture panel, next to the swatches.
3. Decripple the prim attributes.
4. In particular, be able to edit the Profile Cut attribute for Box, Cylinder, and Prism.

I have already tried #2, performing a simple copyandpastectomy of the pipette button from the Color Selection window to the Texture panel, but the button was nonfunctional/disabled. I suspect that the Toolbox window does not have the proper function(s), or is not programmed to listen for clicks to that button. Likewise for #1: the button tag may not respond to shortcut attributes as the menu items did.

#3 and the more specific #4 appear to be impossible because the functionality involved in limiting, adjusting, and hiding various attributes based on prim type is programmed into the SL viewer, and is not part of the XML. To be able to coax the Profile Cut attribute to appear for Boxes, I would probably need access to SL's source code; of course, I do not have access to the source code, so this seems to be out of my hands.

Decrippling the UI

Ok, so I changed the Second Life XML User Interface files to change some text labels and names in the Toolbox (Edit window). This was just a simple matter of reading through the floater_tools.xml file and changing a few words here and there. No biggie. (No, I did not add a new prim type!—I just renamed "Sphere" to "Watermelon". It's much nicer, don't you think?)

But aside from the obvious comedic value, what can changing the UI do for us?

Here's a good one, the true poster child of useful UI changes: we can decripple the Texture panel's "Transparency" input form. Have you noticed that you can only make an object 90% transparent using the UI, but you can make it 100% transparent with a single function call in a script? Linden Lab crippled the UI, perhaps to prevent new Residents from making hundreds of totally invisible prims and forgetting where they put them.

Well, if you are capable enough to edit SL's UI definitions, you are experienced enough to toss aside that crutch! Please note that the same disclaimer as my earlier post also applies here—you are doing this at your own risk! Here's how: in floater_tools.xml, search for the string ColorTrans. That should take you to a <spinner> tag defining the spinner (a numeric entry form with up/down arrows on the side) that controls transparency. That tag has an attribute, max_val, which defines the highest number you are allowed to put in it. Change that number from 90 to 100. While you are at it, change the increment attribute to something more useful, like 5 or 10; now it will increase by that amount whenever you click the up/down arrows on the spinner (or use your mousewheel ← bonus pro tip for you!). The default value of 2 gives you a good degree of precision, at the expense of convenience. Don't forget that you can always just click on it and type in whatever number you want, when you need precision!

Now start (or restart) SL, and enjoy your newfound freedom!

IM IN UR XML IMPROVIN UR INTERFACEZ

(Write-up and useful changes to XUI tomorrow.)

Hacking XUI for Fun and Goodness

Today, I was writing up a huge post about custom keyboard shortcuts. I was covering all the bases: why keyboard shortcuts make everything happy and warm, the ways in which SL's shortcuts are poo, and how Linden Lab could and should implement custom keyboard shortcuts. During my research into this last aspect, I realized something:

I can do it myself.

In fact, I not only can do it, I have done it. As a proof of concept, I successfully remapped the Ctrl-Shift-M shortcut. It had previously been bound to View > Mini-Map; it is now, for my Viewer, bound to World > Force Sun > Midnight.

This is just the beginning.

For the curious, here's how I did it.

Second Life's user interface is (at this point in the time, but not so in the past) defined as XML located in the skins/xui/xyz/ directory (where xyz is the language code; for English readers like myself, it's en-us). The XML for the menu bar along the top of the viewer is in the menu_viewer.xml file.

The majority of this file are <menu_item_call> tags, one block for each menu item. One of the possible attributes for this tag is "shortcut". The values for the shortcut attribute are a pipe-separated list of modifiers followed by a key. For example, the "Ctrl-Shift-M" key combination is expressed as "control|shift|m".

Make a backup copy of menu_viewer.xml before you make any changes, in case you break something and need to revert. Then use a text editor (or, if you have one, a dedicated XML editor) to open the file. Find the entry for "Mini-Map", and cut out the part that says: shortcut="control|shift|m". Then find the entry for "Midnight", and paste it after name="Midnight" (but before the closing brace; and don't forget to put a space between between the quote after Midnight and the beginning of shortcut).

That's it. Start up SL, and if everything went as planned, the "World > Force Sun > Midnight" menu item will show a shortcut key combo next to it, and "View > Mini-Map" will not. You can press Ctrl-Shift-M to see for yourself that it now forces the sun to midnight.

Like I said earlier: This is just the beginning. There are dozens of other XML files in that same folder, defining such things as the layout of the edit window, the min and max values of number entry forms, and many, many other things which I intend to experiment with.

I will close with this disclaimer: I re-read the SL Terms of Service tonight, especially section 4.2, which covers accessing SL with "unauthorized" software (this is one of the sections that was amended after the recent CopyBot scare). And although I think that modifying the XML files accessed by the SL Viewer client is probably not a violation of the spirit of the TOS, should you choose to do it, you do so at your own risk.

It would be a mistake for Linden Lab to discipline anyone for trying to improve their own user experience without harming others; but it wouldn't be Linden Lab's first. Fair warning.