[Fwd: [sldev] Cleanup and XUI conversion of the MiniMap]

[Aimee Trescothick]

On 14 Jan 2009, at 20:39, Melinda Green (Coco) wrote:

> Aimee,
>
> I support this work. Please patch from the featurettes branch and  
> attach it to one of your meta sub-tasks.

Thanks Coco :) It might be a couple of days though before I can  
prepare the patch due to work commitments.

> Regarding renaming files, that's a fine idea but logistically it's  
> probably too painful to take in as a patch.

Yeah, that's pretty much what I guessed.

> Regarding panning support, rather than removing it, I like the idea  
> of making it work but of course there are some UI ramifications.

OK, I'll put it back in.  I initially removed it as I guessed it was  
made redundant way back with the introduction of the main world map.  
However, UI considerations allowing, it should be fairly easy to get  
working. One UI concept might be to allow panning by shift-drag on the  
mini-map. That raises the question of what happens when the camera  
moves though, you could either snap back to camera position or move  
the map with it at the same offset (though I could see that leading to  
confusion if people do it accidentally) or ...

... that might work best alongside another possible featurette, which  
would be to add a selection to the right-click menu to choose whether  
the mini-map centers your avatar or your camera position. Then, if you  
turned both off, you could free-pan with-shift drag instead. Having to  
explicitly go into the menu and turn the centering off would side-step  
the possible issue of people panning the map accidentally while doing  
other things. While the map centering is enabling it might be nice to  
still allow shift-drag panning, but making it "springy" so that when  
you release it returns to the centered position over a short period.

That's all just come straight off the top of my head while I was  
writing this though, so I haven't thought it through that far yet :)

> Regarding gMiniMapScale, rather than create a member for it (a  
> definite improvement) it might be best to eliminate it altogether  
> and just make calls to get/set the saved settings value when needed.

I did consider that, but there are a couple of other member variables  
that also get updated in setScale whenever it changes, so I made it a  
private member accessed only through setScale to ensure that happened.  
Using the saved setting directly might lead to odd things if it got  
changed without calling setScale to update the others, though that's  
not necessarily an intractable issue, I decided to err on the side of  
caution to begin with and maybe look more closely at how it and the  
other member variables are used as a second iteration.

> There's always the possibility of colliding with other work but my  
> philosophy is to make small incremental improvements until those  
> things happen. It's therefore smart of you to want to do a clean-up  
> patch before more visible work that depends on it.
>
> Thanks Aimee!
> -coco

Thank you :) It seemed sensible to make sure the foundations were  
sound before trying to build on top of them.

Aimee.