WebPositive: Address bar list uses user colors.

* Before this commit address bar used:
B_MENU, B_LIST, B_DOCUMENT colors.
With strange results during customization.
* Now the address uses list user colors.
* Partialy fixes #10840.

Only use the scrollview if it is needed (to avoid the problem of a useless
disabled scrollbar.)

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

Add a scrollview (with associated resizing trickery to cut-off the sides of the
scrollbar) to the auto-complete list. This now also makes the scrollwheel work
but selection by mouse still needs implementing.

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

Fix style violation.

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

Fix crash that occurred when hitting pgup/pgdn in the URL input without having the choice list visible.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@530 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

Improved coding style and the looks of the matched pattern in choices.

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

Better to darken the match color, this makes it visible also in non-selected
choice items.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@274 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

WebPositive: Address bar list uses user colors.

* Before this commit address bar used:
B_MENU, B_LIST, B_DOCUMENT colors.
With strange results during customization.
* Now the address uses list user colors.
* Partialy fixes #10840.

Only use the scrollview if it is needed (to avoid the problem of a useless
disabled scrollbar.)

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

Add a scrollview (with associated resizing trickery to cut-off the sides of the
scrollbar) to the auto-complete list. This now also makes the scrollwheel work
but selection by mouse still needs implementing.

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

Fix style violation.

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

Fix crash that occurred when hitting pgup/pgdn in the URL input without having the choice list visible.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@530 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

Improved coding style and the looks of the matched pattern in choices.

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

Better to darken the match color, this makes it visible also in non-selected
choice items.

git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@274 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