There you’ll find helpful articles and guides to using Awesomium as well as a new discussion board for support requests.

The current Awesomium support forum is being phased out in favor of the new discussion board at our support site. The new board has a couple of really neat features:

• Our support staff can tag certain discussions (i.e., support requests) with development-task tickets so that you can track the progress of your issue, bug, or feature request.
• If you’ve got a sensitive issue, you can make your discussion private so that only our support staff will see.
• You can be notified by email of any updates to your discussion.
• You can login with your Khrona Customer Account or OpenID (login is only required for posting private discussions)

Questions posed in the existing Awesomium support forum will continue to be responded to for the next month only, at the end of which the forum will be locked for archival purposes.

A couple of things have changed since v1.6 Beta:

Fixed:

• Resizing of WebViews now works properly (see WebView::resize)
• WebViews no longer crash upon destruction (see WebView::destroy)

Added:

• Cursor change notifications are now cross-platform and work properly.

API Changes:

• added CursorType enum to WebViewListener.h
• modified WebViewListener::onChangeCursor with new, cross-platform cursor change notification
• removed WebView::getContentAsText
• removed WebView::deselectAll

Known Limitations/Bugs:

• Transparency doesn’t work correctly yet on Windows
• Drop-down lists don’t work correctly yet on Mac OSX
• WebView::getDirtyRect doesn’t return correct values after scrolling
• WebView::executeJavascriptWithResult still needs further implementation
• WebCore::setCustomResponsePage still needs further implementation
• The CBundle.framework fails to be found on Mac OSX when a non-NSBundle-based application is run inside the XCode IDE

User Data Paths

Previously, cookies and cache would be stored using the “Local Settings” directory of the current Windows User Account, regardless of any user-specified paths— this has been fixed. Additionally, the cookies and cache paths have now been consolidated into a single “user data” path (see the WebCore constructor).

Drop-down Lists

Drop-down Lists (e.g., the “select” element in HTML) now work as expected on the Windows platform. This feature still needs some work on the Mac OSX platform.

Opening of External Links

The behavior of external links (e.g., links that would usually open in a new tab/window, usually due to target=”_blank” attribute, a GetURL call in Flash, or a window.open call in Javascript) has changed. These links are no longer opened automatically; if you wish to handle these, you will need to register a WebViewListener subclass and override the “onOpenExternalLink” method.

Additional Plugin Search Paths

The plugin search path (see the WebCore constructor) now works as expected– you may use this path to specify an additional directory to load plugins from (useful for bundling Flash).

Log Level and Log Path

The log verbosity and log path settings (see the WebCore constructor) now work as expected.

Keyboard Focus Change Notifications

Keyboard focus change notifications (see WebViewListener::onChangeKeyboardFocus) now work as expected.

Various Stability Improvements

• Fixed freeze during drag-drop and selecting text.
• Fixed crash on pages that trigger loading of the default plugin (eg, GMail, Google Docs, etc.).
• Fixed crashes related to user-data paths (saving of cookies/cache in unwritable directories, etc.).
• Made it so a crashed WebView does not return true upon WebView::isDirty.

Summary of Changes to the API:

Class: WebCore

In WebCore constructor: cachePath and cookiePath parameters have now been consolidated into a single userDataPath parameter.

Class: WebView

Removed WebView::setOpensExternalLinksInCallingFrame

Class: WebViewListener

Removed WebViewListener::onCreateWindow

Other

Made it so KeyboardCodes.h is included when WebCore.h is included.

Version 1.6 is essentially a major rewrite of Awesomium (roughly 80% of the codebase has been scrapped and redone) that takes advantage of Chrome’s process-isolation architecture in a big way: both WebViews and Plugins are now isolated within their own process. What this basically translates to is better stability (crashes are isolated within each WebView/Plugin), improved security (scripts are run in an outside process), better plugin support (Flash is now 100% on both Windows and Mac OSX builds), and faster performance on multicore systems (multiple WebViews scale across multiple cores).

What’s more, Awesomium has been upgraded to the very latest builds of Chromium and WebKit which brings additional gains in performance, compatibility (especially with the bleeding edge of CSS3 and HTML5), and stability.

While most of the internals have been revamped, the API has only gone through a few minor changes– the biggest difference you will notice is that the function signature for WebView::render has changed and also there are some new member functions for WebViewListener. Please see “examples/HelloAwesomium” for an example of using the new API in a basic application.

There are quite a few extra resources that you’ll need to bundle with your executable (pretty much everything within the bin/debug and bin/release directories, respectively). Also, the size of the final binary has increased significantly due to all the added dependencies (though, work is still being done on eliminating a few redundant components). Expect another reduced-size build of the ICU DLL for the final release of Awesomium v1.6 for users who only need support for UTF-8 and Western-encoded web pages.

If you’re feeling ambitious, an experimental “Alpha” build of Awesomium v1.6 is available for download here. Please feel free to test the new build and let us know any and all issues you might have in the Awesomium Support Forum.

Please note that while the major functionality of the alpha build is finished, it is still not totally feature-complete at this time– the biggest parts still in progress are opening of external windows (eg, via target=”_blank” or via GetURL in a Flash plugin) and asynchronous retrieval of JSValues via WebView::executeJavascriptWithResult.

Also of note, be aware that the Debug builds of Awesomium link against the Debug build of WebKit which implies the debugger is very likely to halt upon encountering instances of malformed HTML/Javascript– this is normal behavior. Also, if you’re using XCode, you should be aware that Flash 10 on Mac OSX makes calls to “Debugger()” and so it is helpful to disable “Stop on Debugger()/DebugStr()” when debugging your application.

** Update: Somebody just alerted me to a compatibility issue with Windows XP with the Alpha build (loading of dwmapi.dll), I’m working on it and will post an updated build later.

** Update 2: An updated build “Awesomium v1.6 Alpha B” has been posted with a fix.

One of the biggest changes is the introduction of the “Independent” license which was added to open up use of Awesomium to smaller, “indie” groups of developers. This license can be ordered online now at a special introductory price of US$475 for each application.

We’ve also done away with revenue caps for the “Professional” license; you can enjoy unbridled use of Awesomium 1.x in a single commercial application for just US$4800 (limited time offer).

For use of Awesomium in an unlimited number of applications/platforms or for resale as part of an engine, we have the “Enterprise” license. Contact us to discuss terms and pricing for this license.

Additionally, we now offer source code contracts, support contracts, and licensing for products intended for broadcast. Check out the licensing page for more details.

We hope you’ll enjoy our new licensing model for Awesomium, if you have any questions or concerns please let us know at sales@khrona.com!

For help upgrading from v1.5.0, please see Upgrading to Awesomium v1.5.1.

This new release bring some neat new enhancements, the most notable of which is improved support for the handling of external links. An external link is any link that normally is opened in a new window (typically, via target=”_blank”, window.open(url), or URL events from Flash). The default behavior in v1.5.0 was to open external links automatically in the calling frame however some users desired more flexibility (ie, opening the external link in an outside application). So, in response, we added WebView::setOpensExternalLinksInCallingFrame and added a new notification, WebViewListener::onOpenExternalLink.

Also of consequence, all the member methods of WebViewListener now specify which WebView invoked the event as the first argument. This is an API-breaking change but we felt that it was needed for the sake of future convenience.

Finally, we have also added an oft-requested feature: the ability to override the default user-agent. See the last parameter of the WebCore constructor for more.

P.S.,
To help coordinate tracking of bugs/enhancements, you can now view all open issues online at: Awesomium Support: View All Tickets.

The Windows SDK is available for download right now, the Mac OSX SDK will be up shortly (we’ll announce it on our twitter once it’s up).

For more information about this release, head on over to the Awesomium Overview.

P.S., Awesomium v1.6 is deep under development. Three things coming: Linux Support, Multi-Process Architecture, HTML5