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.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
