Extend the auto-completion framework in order to support using page-up/down
to navigate the choices list.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@501 94f232f2-1747-11df-bad5-a5bfde151594

The mechanism with which the TextViewCompleter detected changes (attaching a
BMessageFilter to the BTextView to pre-process key down events) missed changes
to the BTextView via other means, for example by pasting, or simply when
SetText() is invoked on the BTextView. -> Introduced an alternative method
of making the TextViewCompleter aware of changes, by invoking new method
TextModified(). To bypass the old method, one has to call
SetModificationsReported(true). URLInput::URLTextView now uses the new method
in InsertText() and DeleteText(), which catches any and all changes to the
text. Since the BAutoCompleter framework also controls the editor view contents,
it needs to protect against re-entering some methods when the editor view
reports the changes (fIgnoreEditViewStateChanges). Since we want the
BAutoCompleter to always be aware of the current editor view contents, but not
necessarily also running the choice mechanism (i.e. when you enter
"www.google.com", you don't want the auto-completion kick back in when it is
programmatically changed to "http://www.google.com" later on), the
EditViewStateChange() method gets a boolean now "updateChoices". All
programmatic changes to the URL will then not trigger displaying the choice
pop-up, but the BAutoCompleter is always aware of the current editor view
contents.

All this fixes numerous issues and inconsistencies with entering text in the
URL text view.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@500 94f232f2-1747-11df-bad5-a5bfde151594

Fixed header guards, thanks Ryan!

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@271 94f232f2-1747-11df-bad5-a5bfde151594

Wired everything and improved the TextControlCompleter behavior a bit with
regards to eating the B_RETURN key before we can dispatch in BrowserWindow. So
autocompletion for URLs basically works. What's missing is:

* Much better grouping of matches.
* Fix the delay when the BrowsingHistory is first accessed (lazy loads itself
from disk just then, ought to do it in the application thread after startup,
which probably makes it unnoticable before the user starts typing a URL).

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@268 94f232f2-1747-11df-bad5-a5bfde151594

Imported Beam auto completion framework, converted license to MIT (with
permission from Oliver) and applied Haiku coding style. The base classes have
been named such that they could become official Haiku API in the future.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@266 94f232f2-1747-11df-bad5-a5bfde151594

Extend the auto-completion framework in order to support using page-up/down
to navigate the choices list.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@501 94f232f2-1747-11df-bad5-a5bfde151594

The mechanism with which the TextViewCompleter detected changes (attaching a
BMessageFilter to the BTextView to pre-process key down events) missed changes
to the BTextView via other means, for example by pasting, or simply when
SetText() is invoked on the BTextView. -> Introduced an alternative method
of making the TextViewCompleter aware of changes, by invoking new method
TextModified(). To bypass the old method, one has to call
SetModificationsReported(true). URLInput::URLTextView now uses the new method
in InsertText() and DeleteText(), which catches any and all changes to the
text. Since the BAutoCompleter framework also controls the editor view contents,
it needs to protect against re-entering some methods when the editor view
reports the changes (fIgnoreEditViewStateChanges). Since we want the
BAutoCompleter to always be aware of the current editor view contents, but not
necessarily also running the choice mechanism (i.e. when you enter
"www.google.com", you don't want the auto-completion kick back in when it is
programmatically changed to "http://www.google.com" later on), the
EditViewStateChange() method gets a boolean now "updateChoices". All
programmatic changes to the URL will then not trigger displaying the choice
pop-up, but the BAutoCompleter is always aware of the current editor view
contents.

All this fixes numerous issues and inconsistencies with entering text in the
URL text view.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@500 94f232f2-1747-11df-bad5-a5bfde151594

Fixed header guards, thanks Ryan!

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@271 94f232f2-1747-11df-bad5-a5bfde151594

Wired everything and improved the TextControlCompleter behavior a bit with
regards to eating the B_RETURN key before we can dispatch in BrowserWindow. So
autocompletion for URLs basically works. What's missing is:

* Much better grouping of matches.
* Fix the delay when the BrowsingHistory is first accessed (lazy loads itself
from disk just then, ought to do it in the application thread after startup,
which probably makes it unnoticable before the user starts typing a URL).

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@268 94f232f2-1747-11df-bad5-a5bfde151594

Imported Beam auto completion framework, converted license to MIT (with
permission from Oliver) and applied Haiku coding style. The base classes have
been named such that they could become official Haiku API in the future.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@266 94f232f2-1747-11df-bad5-a5bfde151594