Refactoring proposal

[Michael Robinson]

Here is my proposal.

While trying to find a mouse selection bug in Dan's xmlhttp version, I quickly concluded that entire selection/activation mechanism is overcomplicated and could benefit from a big refactoring.  Currently the entire selection list is recreated whenever the selection changes, and is continuously recreated whenever the mouse is over the list.  Even though the performance is still acceptable, I think a refactoring can provide a much simpler (code wise), and much more efficient implementation.

This is a rough sketch of the changes I am planning on making:

1.  Explicitly create the elements of the match list with document.createElement, and keep a reference to the currently selected object.  When the user presses the down key, we simply swap the selectedElement with selectedElement.nextSibling and change the relevant attributes.

2.  When the mouse moves over the selectedElement gets deselected, and we fake the mouse selection using :hover to change the css attributes.  When an element is clicked, it is inserted with the help of onmouseup="insertSelection(this)", which we added to the list elements in step1.

Any comments or criticism?

:)
   Mike

[Michael Robinson]

It seems that hover doesn't work as I thought, and will not be usefull, but even with a workaround, this approach is still a big improvement.

[Dave Mahon]

If you can figure out a way around the text selection bug, the rewrite I posted is really fast.  It only re-renders the list when the contents of the list changes.

[Dave Mahon]

More specifically, the ONLY time we need to setSmartInputData is when the user is typing in the SmartInputBox.  The rest of the time, we're merely scrolling and highlighting, which cuts down nicely on network transfers and processor cycles.

setSmartInputData should only initialize the SmartInputFloater and populate it with text.  My patch didn't preserve the user's selection, but your idea should work.

selectSmartInputBoxContent can't just use next and previous siblings because you can't be certain the user didn't move the mouse outside of the SmartInputFloater.

I ended up just looping through the entire matchCollection, setting every object's class to matchedSmartInputItem and adding selectedSmartInputItem when siw.matchCollection[i].isSelected was true.  This could definitely be optimized.

Taking this approach, we don't technically need to muck around in WICK's original keystroke and mouse handling functions as much.