Haiku/haiku
Haiku/haiku
1
0
Fork 0
mirror of https://review.haiku-os.org/haiku synced 2025-02-05 05:14:57 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
haiku/src/apps/webpositive/BrowserApp.h

88 lines
2.7 KiB
C
Raw Normal View History

Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
/*
* Copyright (C) 2007 Ryan Leavengood <leavengood@gmail.com>
Added my copyright, since I've redesigned here quite a bit. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@94 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-15 16:23:31 +00:00
* Copyright (C) 2010 Stephan Aßmus <superstippi@gmx.de>
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
*
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
* notice, this list of conditions and the following disclaimer.
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
* 2. Redistributions in binary form must reproduce the above copyright
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
*
* THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ``AS IS'' AND ANY
* EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL APPLE COMPUTER, INC. OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
* OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
#ifndef BROWSER_APP_H
#define BROWSER_APP_H
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
#include <Application.h>
* Link against liblocale.so and load app catalog. * Took FontSelectionView from Haiku Fonts preflet, but almost rewrote it to adapt for WebPositive needs. It's now a BHandler, so that it can actually receive messages itself. The Fonts version is a BView which is never attached, and only receives messages, because the window forwards them. Implemented option to use separate style menu. * Provide font settings in the Settings window. * Wired everything to make it work, although I am not sure standard font is applied. It does work for the serif font, though. Maybe I ought to install more fonts and check with simpler HTML. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@284 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-04 18:17:24 +00:00
#include <Catalog.h>
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
#include <Rect.h>
* Added a class CookieJarClient to WebCore's CookieJar.h which provides the same functionality as the global methods for managing cookies. This is only enabled for the Haiku platform. Since the global cookie methods get a Document pointer, I envision, the CookieJarClient could eventually be a member of Document instances. It would then be passed upon WebCore::Page creation. Still waiting on feedback from other WebKit developers on this one. This change is more elegant than what the Qt port does, which is to use WebKit classes in WebCore (layering violation). Right now, a single global instance of a CookieJarClient can be assigned. * Implemented CookieJarClientHaiku which uses a BNetworkCookieJar to forward the requests. Eventually, the behaviour could be browser specific. * Added all the necessary wiring to BrowserApplication to make the cookie jar persistent. * TODO: Actually parse cookies and handle at least the expiration date, but other stuff like matching the domain of the cookie and the URL and "HTTP-only" cookies seems important as well. Even though I have confirmed that cookies are stored and restored correctly, and also retrieved via the global cookie methods, I can see no change in browser behaviour. For example enabling "Stay signed in" on googlemail.com does not work in WebPositive, although BeZillaBrowser automatically logs in in a new session when surfing to googlemail.com. No idea if this is even implemented with cookies, although it seems like it should be. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@303 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-09 11:49:34 +00:00
class BNetworkCookieJar;
First basic GUI download progress display... git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@54 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-12 21:16:25 +00:00
class DownloadWindow;
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
class BrowserWindow;
Reworked BrowserApp to use SettingsMessage. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@279 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 11:23:06 +00:00
class SettingsMessage;
Implemented basic settings window skeleton. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@277 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 10:57:46 +00:00
class SettingsWindow;
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
class BrowserApp : public BApplication {
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
public:
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
BrowserApp();
virtual ~BrowserApp();
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
virtual void AboutRequested();
virtual void ArgvReceived(int32 agrc, char** argv);
virtual void MessageReceived(BMessage* message);
virtual void RefsReceived(BMessage* message);
virtual void ReadyToRun();
virtual bool QuitRequested();
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
private:
* Revised the application startup to check how many windows have been created at all. Open a blank page if no pages have been created from the arguments passed to the application. * If no pages have been created yet, don't offset the last known window frame. This fixes windows shifting over the screen from session to session. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@397 94f232f2-1747-11df-bad5-a5bfde151594
2010-04-07 10:55:29 +00:00
void _RefsReceived(BMessage* message,
int32* pagesCreated = NULL);
Implemented a neat new window management feature: When the app is asked to open a new file or url, check if there is already a window open on the current workspace, and if so, open a new tab in that window and bring it to front. ArgReceived() now reuses RefsReceived(), which has been extended to handle "url" string fields in the message, since ArgReceived() may also be asked to open urls and not only local files. The LOAD_AT_STARTING mechanism, which turned out to be broken for multiple args anyway, could be replaced, since RefsReceived() already buffers the message when it has been called earlier then ReadyToRun(). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@244 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-28 13:32:39 +00:00
void _CreateNewPage(const BString& url);
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
void _CreateNewWindow(const BString& url);
void _CreateNewTab(BrowserWindow* window,
const BString& url, bool select);
Implemented basic settings window skeleton. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@277 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 10:57:46 +00:00
void _ShowWindow(const BMessage* message,
BWindow* window);
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
private:
int fWindowCount;
BRect fLastWindowFrame;
BMessage* fLaunchRefsMessage;
bool fInitialized;
First basic GUI download progress display... git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@54 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-12 21:16:25 +00:00
Reworked BrowserApp to use SettingsMessage. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@279 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 11:23:06 +00:00
SettingsMessage* fSettings;
* Added a class CookieJarClient to WebCore's CookieJar.h which provides the same functionality as the global methods for managing cookies. This is only enabled for the Haiku platform. Since the global cookie methods get a Document pointer, I envision, the CookieJarClient could eventually be a member of Document instances. It would then be passed upon WebCore::Page creation. Still waiting on feedback from other WebKit developers on this one. This change is more elegant than what the Qt port does, which is to use WebKit classes in WebCore (layering violation). Right now, a single global instance of a CookieJarClient can be assigned. * Implemented CookieJarClientHaiku which uses a BNetworkCookieJar to forward the requests. Eventually, the behaviour could be browser specific. * Added all the necessary wiring to BrowserApplication to make the cookie jar persistent. * TODO: Actually parse cookies and handle at least the expiration date, but other stuff like matching the domain of the cookie and the URL and "HTTP-only" cookies seems important as well. Even though I have confirmed that cookies are stored and restored correctly, and also retrieved via the global cookie methods, I can see no change in browser behaviour. For example enabling "Stay signed in" on googlemail.com does not work in WebPositive, although BeZillaBrowser automatically logs in in a new session when surfing to googlemail.com. No idea if this is even implemented with cookies, although it seems like it should be. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@303 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-09 11:49:34 +00:00
SettingsMessage* fCookies;
BNetworkCookieJar* fCookieJar;
Reworked BrowserApp to use SettingsMessage. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@279 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 11:23:06 +00:00
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
DownloadWindow* fDownloadWindow;
Implemented basic settings window skeleton. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@277 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-03 10:57:46 +00:00
SettingsWindow* fSettingsWindow;
* Link against liblocale.so and load app catalog. * Took FontSelectionView from Haiku Fonts preflet, but almost rewrote it to adapt for WebPositive needs. It's now a BHandler, so that it can actually receive messages itself. The Fonts version is a BView which is never attached, and only receives messages, because the window forwards them. Implemented option to use separate style menu. * Provide font settings in the Settings window. * Wired everything to make it work, although I am not sure standard font is applied. It does work for the serif font, though. Maybe I ought to install more fonts and check with simpler HTML. git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@284 94f232f2-1747-11df-bad5-a5bfde151594
2010-03-04 18:17:24 +00:00
BCatalog fAppCatalog;
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
};
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
extern const char* kApplicationSignature;
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
extern const char* kApplicationName;
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
Manually update to the r238 state, so that we can rebase next commits on top of it 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.
2012-07-03 15:05:29 +02:00
#endif // BROWSER_APP_H
Future public API for interfacing with WebKit on Haiku. (What will eventually become BWebView.) Compared to the original port, the threading has been completely redesigned such that all interaction with WebKit happens in the application thread, as required by the PThread threading backend. This is counteracted by using an offscreen BBitmap/view as the top-level GraphicsContext for each Page, such that drawing is performed in various app_server threads asynchronously. WebViewWindow provides as a target for messages from within WebKit (mostly FrameLoaderClientHaiku events), which are forwarded via virtual hook methods (implemented in LauncherWindow.cpp of the HaikuLauncher). git-svn-id: http://svn.haiku-os.org/webpositive/webkit/trunk@6 94f232f2-1747-11df-bad5-a5bfde151594
2010-02-11 21:57:24 +00:00
Copy Permalink