[sldev] LLUICtrl::onFocusLost() callback

[Ryan Williams (Which)]

Alissa Sabre wrote:
> I have two alternatives here.  I want to hear from you which you think
> is better.  (Or another alternative if you have one.)
>
> (a) Change the timing that the existing onFocusLost() is invoked to
>     facilitate my requirement.
>
> (b) Add a new callback, say onFocusBeingLost(), that is invoked
>     immediately before the keyboard focus is lost, so that I can use
>     it.
>
> The alternative (b) is safer than (a) in that it makes less impact on
> the existing code.  However, such ad hoc additions of methods to
> handle special cases will make the SL viewer code something like
> Windows API, and I don't want to do so unless absolutely needed.
>
> I believe there is no existing code that depends on the timing whether
> onFocusLost() is invoked before or after the actual focus-loosing.  I
> examined all uses of onFocusLost() callback in viewer source set.
> Hence, changing the timing should cause no problem.  Of course, I
> can't see server-side programs, and I have no idea the same thing is
> true for LL's so-called "server-side development tools that share UI
> components with viewer."
>
>   
Hoo boy, our focus code is complicated.  One additional problem that I 
can recall arises from the fact that we have two apis for changing focus 
-- calling the gFocusMgr directly, and calling setFocus() on the object 
itself.  The latter is the preferred method, but we still have some 
instances of the former kicking around, and they behave subtly differently.

The timing dependencies of the viewer are unfortunately difficult to 
understand by looking at the code, so while a) is cleaner, it also comes 
with the added QA burden of "you have to look at every possible ui 
interaction and make sure it's no more broken than before".  :-( 

It'd be great if we had a "right thing" to do, but it doesn't seem like 
there is an obvious right thing in this case.  I would love it if the 
viewer had a simpler and more consistent event model, though.

-RYaN