* Added a context menu to the URL input for integration with the system
clipboard when you want to use the mouse only.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@403 94f232f2-1747-11df-bad5-a5bfde151594
works with the BTextView.
* Factored out the URL text handling into a new class URLInputGroup, which is
used instead of a plain BTextControl, but currently works much the same way.
It's a BGroupView though and allows easy addition of other controls and items
into the URL text field.
* Moved baseURL() method into it's own file, since it's used from multiple
places now.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@402 94f232f2-1747-11df-bad5-a5bfde151594
likely to introduce erros with spelling settings keys wrong somewhere.
* Introduced new setting for the behavior if tabs should show at all if only
one page is showing in a window. Defaults to on, i.e. the previous behavior.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@393 94f232f2-1747-11df-bad5-a5bfde151594
will be passed to CreateNewTab(), so that BrowserWindows can be created to
embed a view which already exists.
* Extended NewPageCreated() hook with the additional information that
BWebPage::createPage() already provides. It can be used to decide if new
windows shall be created instead of creating another tab for the new page.
* Reworked BrowserWindow constructor with regards to the "DoNotHaveToolbar"
policy. All views are always created, BLayoutItems are remembered for the
various groups and are being turned invisible depending on policy. This way
each BrowserWindow is fully valid and can be reconfigured easily during
runtime. (Settings could be exposed as well now.)
* Changed ChromeClientHaiku::createWindow() implementation to not disregard
the "window features" properties if only some of them are not set.
All this combined makes the Haiku User Guide translation page open a separate
window for editing the translations just like BeZillaBrowser. What does not
work (but apparently also not in BeZillaBrowser) is clicking another block and
having the editing window update to show that block instead. Don't know if this
is actually supposed to work that way, it just seems like it should.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@380 94f232f2-1747-11df-bad5-a5bfde151594
B_QUIT_REQUESTED, instead BWebWindow has a new hook and derived classes can
implement it.
* Some refactoring in BrowserWindow to move code from MessageReceived into
separate methods for easier debugging and cleaner code.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@378 94f232f2-1747-11df-bad5-a5bfde151594
* Search for existing bookmarks recursively.
* Open all bookmarks at once, when the user clicks a bookmark folder in
the menu (thanks Axel). But do ask for confirmation if there are more
than ten bookmarks.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@318 94f232f2-1747-11df-bad5-a5bfde151594
WebPositive is moved into the Haiku repo.
* Convert the Bookmarks menu into a BNavMenu, make sure it updates to the
current folder contens each time it opens.
* Wire everything to complete the bookmark support. Managing bookmarks is
fairly nice by re-using Tracker. One can even put anything into the book
mark folder and WebPositive will launch the respective app if it doesn't
have a META:url attribute. The most immediate benefit is that clicking
sub-folders in the Bookmarks folder will also open that folder in Tracker.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@315 94f232f2-1747-11df-bad5-a5bfde151594
* Introduced BWebPage::RequestDownload() public API (expected to run
synchronous).
* Added necessary wiring for "Download this link" in context menus.
* Restarting downloads works in principle, although with some quirks.
(Sometimes it appears the "Desktop" is being downloaded...)
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@310 94f232f2-1747-11df-bad5-a5bfde151594
delete itself in the application thread, we cannot delete the BWebView before
this happens in the window thread. Now BWebPage is repsonsible for deleting
the view.
* Also make sure that there are not still loaders running on the frame. Since
the timer messages arrive in a different handler than the BWebPage handler,
the timer functions being called could operate on stale pointers. I am not
sure why WebCore doesn't make sure of this itself. Perhaps we are not supposed
to delete something directly, but via reference counting. Though I am not sure
what it would be, since WebCore::Page is not reference countable. Maybe the
frame... need to investigate. After all, there could be other timers in the
queue besides loading related ones.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@295 94f232f2-1747-11df-bad5-a5bfde151594
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
necessary. The only usable effect as of yet is that favicons arrive at the
BrowserWindow. Favicons are stored in a database and are not fetched when they
alreary exist. The application is expected to try and fetch an icon for a given
url. This is currently done in BWebWindow when the URL for loading has been
initiated. Otherwise it fetches the URL upon the new ICON_RECEIVED notification
from the FrameLoaderClientHaiku. In any case it ends up at BWebWindow::IconReceived(),
so derived classes don't have to worry about the difference. In any case, via
BWebSettings, icons can also be fetched manually, like for the forthcomming
autocompletion text control.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@257 94f232f2-1747-11df-bad5-a5bfde151594
it so much, since it somehow looks alien for no /really/ good reason. Maybe
I'll integrate this option into the settings, when I get to those.
git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@253 94f232f2-1747-11df-bad5-a5bfde151594
Original commit message of r238:
Split up WebPositive from HaikuLauncher. HaikuLauncher is back to it's simple
self. WebPositive uses a new WebPositive folder in config/settings. Otherwise,
everything should be as before. LauncherWindow and LauncherApp have been renamed
and cleaned up for the Haiku coding style.
Edit history with this rename commit to preserve history as we will git-filter --subdirectory-filter the WebPositive directory. The HaikuLauncher directory was renamed to WebPositive trough the past history with git-filter.
