[sldev] LLUICtrl::onFocusLost() callback

Alissa Sabre alissa_sabre at yahoo.co.jp
Thu Aug 23 07:02:18 PDT 2007


Linden/SLDev developers,

I've been working on improving Chinese/Japanese/Korean text input on
the viewer (See, e.g., VWR-250).  I'm facing a blocker now.  I want to
hear your opinions.

In my latest patch, preedit (aka composition or unconfirmed) string is
shown on the LLTextEditor and LLLineEditor components as the user type
and then sent to the components buffer (through handleUnicodeCharHere)
when the user perform a commit (aka comple or confirm) operation.  This
is fine.

The problem is the case that the user changed the keyboard focus to
another UI control befor comitting the preedit string.  We need to
automatically commit the contents of the preedit before actually
switch the focus, because that's what the user expects.
Unfortunately, it doesn't work well now.

Exising LLUICtrl provides a callback onFocusLost().  I first thought
that issueing a commit operation from LLTextEditor::onFocusLost() and
LLLineEditor::onFocusLost() solves the problem, but it didn't work.
onFocusLost() is invoked *after* the focus has been lost, but I need a
callback invoked just *before* the focus is lost.  More precisely
speaking, in the existing code, when the onFocusLost() callback is
invoked, gFocusMgr.childHasKeyboardFocus(this) returns false, because
the focus is set to the new component that receives the focus.  I need
a callback that is invoked during
gFocusMgr.childHasKeyboardFocus(this) returns true, so that the
LLWindowCallback::handleCharHere() to be invoked during the automatic
commit operation is delivered to this.

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."

Comments?

    Alissa Sabre
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/



More information about the SLDev mailing list