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.

Two months passed, and with them the documentation project sponsored by Samsung came to an end. During this time, ProFUSION guys Jonas Gastal, Rafael Antognolli, Gustavo Lima, Bruno Dilly, Flávio Ceolin and yours truly, covered several aspects of the EFL adding documentation where it was missing, expanding when it was not enough and writing examples of each component to help make sense out of them.

A summary of what was done:

•  Eina
  • List and Inlist
  • Hash
  • Array
  • Stringshare, strbuf and str
  • Log, Magic and Error
  • Iterator and Accessor
  • File
  • Tiler

•  Eet
  • Basic file operations
  • Serialization of user structures
  • Image saving and loading

•  Evas
  • Canvas functions, creation and basic handling
  • General manipulation of Evas_Object's
  • Functions specific to each type of object: Image, Text, Box, Table
  • Smart Objects
  • Map
  • Size hints

•  Ecore
  • The main loop
  • Timers, animators and pollers
  • Threads pool
  • Pipe
  • File handlers
  • Events, jobs and idlers
  • Ecore_Con and Ecore_Con_Url
  • Ecore_Evas

•  Edje
  • The entire C API (sorry, no Edc tutorials this time around)

•  Emotion (Yes! It is documented now!)
  • Creation, play and seek controls
  • Audio controls
  • Other media info

•  Elementary
  • Errr... a lot really.
  • There's a widget list now in the docs with a preview screenshot of each.

A lot of good work has been done, but in no way this means it's perfect. It's up to users and developers now to use these weird new things we were not used to before (the docs, get it?). Read them when you know what you want but are not sure of how to use it. Browse them when you don't know what to use and discover a world of possibilities (I'm getting a bit cheesy here).

And report back any problems. Things are not entirely clear? Something documented doesn't match the program's result? Is that a bug in the documentation or in the code? Just like any other piece of code written, it will improve as people uses it and the rough edges get polished. The project may have ended, but the work itself goes on.

This week's report begins with some sad news for everyone. Elm_Toolbar was causing Efreet to call  stat(2) a bit too much and instead of killing the widget, an icon cache for Efreet was implemented. So if you build Efreet with --enable-icon-cache, we are faster. This option will be turned on by default after the 1.0 release.

Speaking of releases, there's a beta3 yet to be announced, but you can find the tarballs  here and some snapshots to go along  here.

And now, the happenings of the last seven days:

• We jumped into December, it's almost Christmas already.
• Efreet not only got its new cache, but it now follows the Freedesktop's specifications about it more closely, storing its files in the right place (that would be ~/.cache) or whatever XDG_CACHE_HOME is pointing at.
• Not only Efreet got faster, but also Eet, who got some of its internals redone to make better use of memory and improve overall performance.
• Ecore's handling of file handlers saw a revamp as well. Normal users won't notice much of an improvement here, but if you have an application using it to manage around 25k file descriptors, we are glad to tell you that you won't see your speed get massively hit anymore.
• Lots of fixes here and there to build cleanly on OpenBSD and MacOS X.
• Elementary Entry's item system to insert emoticons can now reference image files in your harddrive, by using the same ol' file:// syntax everyone knows.
• Hoverlist and Magnetslider in Elementary got renamed to Ctxpopup and Actionslider, respectively.
• Editje saw some work to support key modifiers in its mouse handling of object edition. You can play with Ctrl, Alt and Shift while dragging parts around.
• Edje_Edit is now capable of keeping your Embryo scripts in the generated source, if the Edje file edited was built with a recent enough edje_cc. It can also recompile the script and update the running VM with the new bytecode.

And to close, some Azy news from discomfitor:

• Spec file added (thanks to Rui Miguel Silva Seabra)
• distcheck now passes!
• 100% documentation coverage
• Client helper function added to make error checking and callback setting one call
• XML support is now OPTIONAL
• openssl dependency dropped
• Server module data is now correctly exposed for use in .azy code
• MYSQL example added to test code

Hello Monday, ProFUSION already writes internal progress reports and some developers, including Rasterman, found it could be useful for the community as a whole. If you want your news to be published, you can always contribute it or even help with the weekly news as we used to have before.

Highlights from the last couple of weeks (since I've been putting this off longer than I was supposed to)

• Elementary began to support textclasses. This means it's possible to change font and style for the widgets that support them. What widgets they are takes us to...
• elementary_config has received some more love and it can now change the cache settings for Elementary, as well as the textclasses for those widgets that support them, provided the chosen theme uses them.
• Following on the config thing, choosing the Standard profile, as opposed to default, will use a desktop oriented theme. As of now, the only difference to it is the scroller (and related widgets) having clickable scrollbars, which in turn are now affected by fingersize.
• Other changes in the scroller were made in the way it treats the contained object. This was done mostly so items in gengrid would be properly aligned, even when they are bigger than the shown area.
• The usual assorted fixes here and there include clearing the set image from elm_bg when calling elm_bg_file_set() with a NULL file argument; more hooks for more widgets, specifically signal_hooks to interact with the internal Edje objects; lists can now be disabled; and more.
• k-s (barbieri) added 2 new programs in Edje: edje_inspector and edje_external_inspector. These tools help developers see what is described in compiled edje files (edj) and external modules respectively. The first tool (edje_inspector) is useful to list groups and their parts, being able to filter based on name globs or even just those with 'api:' property, making easier for theme makers and application developers to establish a contract of what should be accessed. The second tool (edje_external_inspector) will list known modules (emotion, elementary...) and their registered types and parameters expected by these types, aiding those writing EDC files that use "type: EXTERNAL". Both tools have human or machine-readable output, helping tools to parse the output and produce some easier interaction or automation of processes (like tab-completion).

And in the not-core EFL front, contributed by acidx and abgrilo, respectively:

Enjoy

The past few weeks were pretty busy on the Enjoy front. The simple media player is almost ready for public consumption. Some highlights of what happened in november, in chronological order:

• MPRIS support has been added; MPRIS is a DBUS interface that lets a media player be controlled remotely.
• Elm_Toolbar is being used instead of our homecooked one. This means Enjoy won't look alien with a theme other than Efenniht.
• Shuffling now uses a better algorithm. Songs now won't repeat whenever the current playlist is in shuffle mode, and it'll be possible to go back to a previously-played song.
• Cover art is now downloaded from LastFM whenever they're not available locally. These images are cached locally so bandwidth won't be wasted.
• Resized cover art is now cached locally -- no more resizing them every time they're requested from the disk.
• Some themes were moved from Enjoy to the Black&White and Efenniht Elementary themes, mainly the list item stuff.
• Some bugfixes and small optimizations were performed as well.

There are more things on the works, like a user interface for the Library Manager -- so no more fiddling around with the command line just to add some songs to the database.

WebKit-EFL

Last week we had Tiled Backing Store for EFL port of WebKit upstreamed. With it, instead of rendering a single image buffer that is later displayed, it does in a matrix of image buffers. Then, with EFL Tiled Backing Store implementation, scroll and zoom operations can be done faster. For more info, please take a look at this Changelog entry  http://trac.webkit.org/changeset/72579.

We also test daily if WebKit-EFL upstream with EFL-SDK latest versions and correct the problems caused by API changes.

That's all for this week. Coming up next: More Elementary stuff and Edje_Edit will know what scripts are. Stay tuned.