The long overdue introduction to Elm_Web is finally here, thanks in part to this little blog being back, and in part to me being reminded for the sixth time that I had still to put it up. But those are unimportant details, what matters is what follows.

What

Elm_Web is a new Elementary widget that provides a way to display Web content in your Elementary applications. It uses WebKit's EFL port, wrapped around to integrate properly within Elementary's infrastructure and to provide a simpler API, so it can be used without having to worry about needing to write the boilerplate code required to get things up and running.

Why

WebKit-EFL provides two main classes that developers can interact with to control how their documents will be shown. Ewk_View and Ewk_Frame.

Ewk_Frame is a lower level object and there's one for each frame as the loaded document contains. As such, they are created by WebKit as needed, but things like key or mouse events and scrolling the frame contents need all be fed by someone else to be processed.

Ewk_View is the higher level object the developer will actually interact with. It always contains at least one Ewk_Frame in it and it abstracts almost every part of the frame API, so that developers need only work with specific Ewk_Frame objects when it's absolutely required.

Still, the Ewk_View class demands that a lot of boilerplate code be provided to get something more than the bare basics. It's implemented as a Smart Object with its class being public, so applications have to define most of it to handle things like JavaScript dialogs, mouse events for touchscreen style scrolling and requests to open a new window.

Elm_Web simplifies this. It provides default implementations for the items mentioned above, while allowing the user to override them by giving their own callback functions to handle each event. It takes care of finding and setting the theme path for WebKit to use when rendering its internal widgets and attempts to provide an API similar to those of other Elementary widgets.

However, Elm_Web is meant to be a simple layer on top of WebKit-EFL, intended to provide a simple way for applications to have a Web widget where to display simple pages, online help or simple markup content. It is not meant to write a full featured browser, at least in its current state.

The API provided is the most common subset of functions that the Ewk_View object supports, but if something more advanced is needed, it's always possible to get the internal Ewk_View object and operate on it directly. Note must be taken though, that not everything can be changed, and some things may enter in direct conflict with how Elementary handles the object internally.

How

So how do we get this new toy you ask? Assuming you already know how to build the EFL (here's some help), you would now need to get and build WebKit before Elementary.

Detailed instructions on how to get WebKit can be found in its own wiki, right  here.

Once WebKit is built (it can take a long time, depending on the computer), it's time to build Elementary. If everything's right, it should auto-detect the WebKit installation and inform that Web support will be built in its configure output. If it doesn't find it, make sure that the PKG_CONFIG_PATH environment variable contains the path where ewebkit.pc can be found, usually something like "/usr/local/lib/pkgconfig".

When the build finishes, check out the Web test in elementary_test and the example in src/examples/web_example.c to see it in action.

To start using it in your own programs, refer to the documentation that can be found  here.

And if you want to help improve the widget, refer to the next point.

Pending

There's always work to do and there are always ways to improve things, so here are a few pending items, in no particular order.

• Each Ewk_View object requires a theme to be set to it so it can render the internal objects like buttons, textarea, scrollbars, etc. Elm_Web will do this for you by looking in the list of themes set for the program (in order, going from overlays to main theme and then extensions) looking for one that provides the "webkit/base" group. Once it finds one, it will set it as the theme for its internal view object. If no theme contains this group, it will fall back to WebKits default theme, using the path to its data directory found at built time. The default theme for Elementary currently has no theme for WebKit, so it will be always using the default, which doesn't exactly match the looks of the rest of the toolkit. It would be nice to have a theme using the same graphics as the rest of the toolkit, to make things a bit more integrated.

• Panning, scrolling, thumb dragging... all of these are implemented by handling the events coming from the Ewk_View object, and not integrating with the scroller widget in Elementary. The reason being that the view object is not just one simple object with a defined size that can be freely moved around, but a container for an unknown number of elements that can be scrollable themselves.

• JavaScript dialogs have their default implementation and users can override them by providing function callbacks to handle the creation and managing of said dialogs. However, to completely disable them, an implementation of them returning NULL for the object is needed. Maybe it would be a good thing to have a flag to have the widget ignore their requests entirely.

• Your idea here.