Help is here! Vote for VWR-2448 TO-DAY!

This message brought to you by the Ad Council for the Egregious Use of Bolding.

In theory, here’s how things are supposed to go:

1. Someone opens a new issue. We’ll call that person the issue reporter. The issue is now Open.
2. People vote and comment and add more info.
3. A programmer (either a Linden or an open source volunteer) sees the issue and decides to tackle the job. The issue is now In Progress.
4. When the programmer is done working their voodoo, they upload a patch to the JIRA. The issue is now Resolved. Or maybe it’s still Open. Who knows?
5. A Linden with access to LL’s source code repository applies the patch and marks the issue as Resolved, with a resolution of “Fixed Internally”.
6. It’s compiled and examined and made sure it works and there don’t seem to be any bugs. This is called QA (Quality Assurance), and it can take a long time, because there are lots of issues to check. The issue has to wait in a queue until it can be looked at.
7. If it all checks out, eventually it will be released in a new version along with other fixes. Yay!
8. The issue reporter downloads the new version and makes sure the issue has really been addressed. If it has, they mark the issue as Fixed, and Close it. If not, they change it back to Open, and we go back to step 1.
9. Done!

That’s how it’s supposed to go, anyway; or rather, as I said last time, my interpretation of it based on experience.

In practice, though, issues often don’t end up Closed. Instead, they linger as Resolved until a dutiful volunteer sifts through the hundreds (thousands?) of Resolved issues, marking off the ones that have been fixed. Often, issue reporters simply don’t realize they’re supposed to check back later to Close the issue.

As it happens, the Closed state isn’t used much. Maybe it’s the ambiguous difference between Resolved and Closed. Maybe it’s confusion about when it’s appropriate to Close an issue, and who is allowed to do it. Maybe it’s fear that Closing an issue is forever, as implied by the description of Closed as “the final resting place” (it’s not forever; you can re-open Closed issues just like you can for Resolved issues). Maybe they don’t want to make the reporter angry by closing their issue.

Another contentious issue is the fact that voting is closed for Resolved issues, which (in my opinion) should not be the case. There are cases of high-profile bugs that are still ruining a lot of people’s SL experiences, but the fix seems to be stuck in QA limbo. Since issues are marked Resolved / Fixed Internally while going through the QA process, people can’t vote for it anymore. That means there could be hundreds of Residents who would have registered the fact that it affects them, but couldn’t. This prevents the number of voters reflecting the relative severity of the problem, a metric that could (and possibly should) be used to prioritize issues in the QA queue.

Fortunately, there are JIRA issues about the issues with JIRA (how delightfully recursive)! A lot of progress has already been made on improving JIRA, but there’s still more to do. To get you started, check out:

• WEB-194 (“Streamline and clarify JIRA reporting process for non-technical users”)
• WEB-274 (“Change status labels for PJIRA”)
• WEB-315 (“Meta Issue: LL JIRA Guidelines”)

What’s the difference between “Resolved” and “Closed”? When is something “Fixed”, and why do some issues seem to get stuck in “Fixed Internally” for a long time?

Read on to find out!

Due to some confusing technical jargon that doesn’t make a lot of sense if you’re not used to them, the meanings of the various states aren’t immediately obviou. Here’s a list of the possible states that an issue can have right now:

• Open: the normal state, people can vote and comment and post patches and such.
• In Progress: someone’s working on it, so never ye worry.
• Resolved: some sort of action has been taken to address the issue, but someone needs to confirm that it’s addressed, or it still needs to be released. Voting is closed, but you can comment or even re-open it.
• Closed: the issue has been solved and released, everything’s groovy, nothing more to be done. Voting is closed, but you can comment or re-open it.

At least, that’s my interpretation of them, based in large part on this well-hidden blurb on the SL wiki. There’s a lot of confusion about issue states, especially among users who aren’t used to issue tracking software and its weird jargon.

When someone says a problem has been “resolved”, that usually means the thing has been fixed. But wait, that’s what the “Closed” state means on JIRA! So what does “Resolved” mean, then? Is it the same as “Closed”? Why do they have both of them?! Arrrgh, so confusin’!

To make it even more confusifying, the “Resolved” state can mean lots of very different and unrelated things, depending on what the “resolution” is:

• Fixed Internally: LL has fixed the issue (or applied a patch) in their internal source code repository, but it still needs to be reviewed to make sure everything’s good and it can be released.
• Fixed: the issue has been fixed and released. Yay!
• Won’t Finish: LL won’t fix the issue, for any number of reasons. Maybe it would break content, or make things really slow, or it just doesn’t fit within their grand vision.
• Duplicate: someone has already reported this same (or a very similar) issue earlier or with better info/repro, and you should comment/vote on the other issue instead.
• Needs More Info: the issue doesn’t have enough info, or it isn’t specific enough, for anyone to address the issue. E.g. “inventory is borked plz fix kthxbai” <– needs moar infos!!
• Cannot Reproduce: the Linden who looked at this issue can’t make babies. Just kidding! It means they tried to make the bug happen so they could study it (and later try again to make sure it doesn’t happen up anymore), but they couldn’t. Repros are an important part of the process!
• Misfiled: this issue doesn’t belong on JIRA. Examples include “Halp I furgetted my password”, “I liek ponies”, and “LL sucks cuz there poopy heads”. These types of reports don’t help make SL better!

But those labels can be confusing, too, hence me needing to explain what they mean. And some of them don’t really fit with the Resolved state: the “Fixed” resolution, for example, should really only go with the Closed issue state. But, the same list of resolutions is used for both Resolved and Closed, and there’s some overlap, so it’s fuzzy and ambiguous.

Tune in next time for an overview of the JIRA process flow, more JIRA quirks and weirdness, and some tips on making JIRA a better place!

void reload_vertex_shader(void *)
{
	//THIS WOULD BE AN AWESOME PLACE TO RELOAD SHADERS... just a thought	- DaveP
}

(Made me chuckle. From indra/newview/llviewermenu.cpp in the SL client source.)

BOOL LLManipTranslate::handleHover(S32 x, S32 y, MASK mask)
{
    // Translation tool only works if mouse button is down.
    // Bail out if mouse not down.
    if( !hasMouseCapture() )
    {

Three hundred ninety-six lines later, we come to the end of the function:

    dialog_refresh_all();		// ??? is this necessary?
 
    lldebugst(LLERR_USER_INPUT) << "hover handled by LLManipTranslate (active)" << llendl;
    gViewerWindow->setCursor(UI_CURSOR_TOOLTRANSLATE);
    return TRUE;
}

One function.

Over 400 lines long.

Not intimidating enough for you? Here’s a sample of what some of those lines look like:

            // snap to planar grid
            LLVector3 cursor_point_agent = gAgent.getPosAgentFromGlobal(cursor_point_global);
            LLVector3 camera_plane_projection = gCamera->getAtAxis();
            camera_plane_projection -= projected_vec(camera_plane_projection, mManipNormal);
            camera_plane_projection.normVec();
            LLVector3 camera_projected_dir = camera_plane_projection;
            camera_plane_projection.rotVec(~mGridRotation);

This is one of those functions that makes your eyes go blurry and your head start to hurt until you curl up into fetal position and question the existence of a merciful god.

You might notice a new entry in the Tools menu for SL 1.17.1.0: Edit Linked Parts!

That’s right, the feature I added back in March and submitted to the JIRA has now made its way into the official client release! The menu item works just like the checkbox in the Build/Edit floater, allowing you to switch between editing whole linked sets of prims, or editing the individual members.

Not good enough? You want more?

Well then how about I tell you guys how you can add your very own keyboard shortcut… in just 3 easy steps?

1. Open the Second Life/skins/xui/en-us/menu_viewer.xml file in your favorite text or XML editor.
2. Go down to line 695 (or do a search for “Edit Linked Parts”) where it says shortcut="", and type in your shortcut between the quotation marks! For example, to bind it to Shift-L, you’d type in shift|L!
3. (Re)start Second Life, and enjoy!

A word about the format for shortcuts: Put the modifier keys first, separated by the pipe character, | (Shift-Backslash, above the Enter key). The standard order for modifiers is control|alt|shift, but I’m not sure the order matters too much. For Macs, “control” means the Command key.

Obstacles: Few. Mostly just making any sense of the gigantic almost-totally uncommented functions.

How to accomplish the goal:

1. Modify LLPanelObject::getState(), around line 816 of ‘indra/newview/llpanelobject.cpp’ (the file that controls the Object tab of the Edit window), to make the ‘advanced_cut_visible’ variable TRUE if Advanced Mode is enabled.

Rewards: It is now much more convenient to torture Box & friends to make them very thin. No need to swap to other prim types to do the job!

Required knowledge:

• How preferences work (for Advanced Mode)
• How XUI works

I’m already done with this feature. It was pretty easy to add! (I’m totally on a roll today!)

Obstacles: The preference for “Edit Linked Parts” is actually saved as the opposite of that: “SelectLinkedSet”. When the ELP checkbox is on, that means the SLS preference is off. This means there must necessarily be an extra layer of code between the checkbox and the preference, in order to do everything oppositely.

How to accomplish the goal:

1. Convert “SelectLinkedSet” preference to a new “EditLinkedParts” preference.
2. Update all the code in the viewer that depends on SLS, to make them depend on ELP instead. Don’t forget to correct for the non-oppositeness.
3. Change the “Edit Linked Parts” checkbox to use the LLUICtrlFactory to access ELP.
4. Add a menu entry with a key binding to the Tools menu to toggle ELP.*

* I might be able to add a key binding without adding the new menu entry, but I don’t currently know how to do that, and the menu entry is a good thing anyway.

Rewards: The building process will be much faster and more fluid!

Required knowledge:

• How XUI keyboard shortcuts work. (Check!)
• How XUI Menus work. (Check!)
• How Preferences work. (Check!)
• How LLUICtrlFactory works.

So, since I have been spending a fair bit of my time during the past couple days digging around the code related to Second Life viewer client user preferences, I’m sharing what I found out, to help those who come after me! Thus I present to you a guide for Second Life viewer code hackers (i.e. programmers): How Preferences Work! I hope I have saved some other people a little bit of work that they would have to do to gather the knowledge in that guide!

By the way, you might be curious about the purpose behind my researching how preferences work! Here is what’s floating around in my head: “Advanced Mode”, a preference that advanced SL users can turn on to get rid of some of the crutches and barriers that have been built into the tools to protect the newbies from themselves. Stuff like how “Transparency” only goes up to 90% in the edit tool, even though it’s trivial to make it go up to fully transparent. It’ll also act as a global toggle for any features that I add that a) significantly modify the way existing things systems work, and/or b) probably shouldn’t be enabled by default for all users.