Embedding a GtkWidget into a HTML page

Embedding a GtkWidget into a HTML page

In the last few days I have suprisingly (actually not, it comes natural when resigning from a job) more time to do stuff that I really want to do. For the last months my webkit involvement has been mostly been reviewing patches created by other people but now I have done something I wanted to add for quite a long time…

I think one of the benefits of having a native web renderer widget in the toolkit is the integration that is possible. You can embed it into other native widgets and you should be able to embed native widgets into the web renderer. I have been working on the second part and the result can be seein in this bug. The attached example is putting the Gtk Scribble example into every plugin.

In the arora web browser this feature is used to implement ClickToFlash and I plan to still this idea too.

Long overdue…

Long overdue…

A long overdue blog post… I’m currently in Taipei… canceled my original flight back to Germany, instead I will go to Hong Kong and then probably back to Taipei. So if you are in this area and would like to talk about WebKit, Linux, KDE, OpenBSC, OpenEmbedded… drop me a mail.

Geo Clue for WebKit/Gtk+

Geo Clue for WebKit/Gtk+

Apple was adding support for the W3C Geolocation API, I started with a implementation using Gypsy, then after some comments moved on to Geoclue. Then Aurelian Maga was more lucky getting geoclue to emit something useful and fixed my logic errors and then it was about time to put the code into the repository.

The next things will be adding API to control the privacy settings, enabling/disabling support for it and so on..

FOSS.IN and the need for more events

FOSS.IN and the need for more events

I have sadly missed this years FOSS.in. The goal of this conference is to turn India into a nation of FOSS contributors. There are plenty of people, awesome food!, there is a huge software industry, companies like Tata Consulting are even on Level 5 five of the CMMI model. This means there is a huge potential! But when I get my daily mail on webkit-dev I recognize that it is still a long way from simply consuming, to try to attempt to think, to contributing. And that many more events like FOSS.in need to occur until there is a noticeable difference.

On the other hand with people like Girish, Prashant, pradeepto, Shreyas I have high hopes that the goal will be reached.

API Reference Manual for WebKit/Gtk+

API Reference Manual for WebKit/Gtk+

As of two days ago the Gtk+ buildbot is finally running the test suite after every build. And today we even have the first regressions that we need to address/understand. The short-, mid- and long term goal is now to get as many tests running as possible and keep them running. There are quite some bugs to be fixed in WebKit/Gtk+, our base libraries, our testing tools so there is plenty of fun left for everyone.

In the webkit IRC channel we sometimes get questions regarding the API of the WebKit/Gtk+ port and if there are examples. On the one hand we are pretty strong. We have the GtkLauncher, some early adopters, when adding API many people made sure that we have API documentation. On the other hand we are weak as there is no introduction, no generated reference manual, no downloadable samples. So I got a bit sidetracked from the regression work and started to integrate gtk-doc and to cut a long story short: You can find an initial version here.

On to the gory details. Integrating gtk-doc requires recursive make due the way the gtk-doc.make rules are written. This file is copied in from gtkdocize. When dealing with documentation you can not have srcdir != builddir. The html result will be put in the source directory and if you try to squeeze in the @VERSION@ you will need srcdir == builddir. Starting from GtkDoc in live.gnome.org and Florian’s GPE guide one finds pretty much everything one needs to find. Some things needed some look at the tool sourcecode (perl, eeek!) but are clear now.

WEBKIT_API type
function_name (function*…);

To make gtkdoc-scan parse the above as a function you will need to pass –ignore-decorators=”WEBKIT_API” to the tool. Magically plenty of symbols turned up in the -unused.txt file and I was able to copy them into the -sections.txt. Now the tool refused to find any documentation. So remember WebKit/Gtk+ is mostly written in C++ and gtkdoc-mkdb simply does not know about the “.cpp” file extension. So pass –source-suffixes=c,cpp to gtkdoc-mkdb and it will find the sourcecode. Ah functions and their documentation, almost perfect. The last undocumented bit is for -sections.txt. E.g. you have the various _get_type(void) methods and there is little benefit of having them pop up in the API. Inside your “<SECTION>” you can put them into a “<SUBSECTION Private>” and they will be ignored.

The next thing is to get it actually merged into WebKit and integrate having uptodate API reference in the release process.

Link WebKit/Gtk+ faster

Link WebKit/Gtk+ faster

Last year in India Simon showed me an ancient and well hidden qmake feature. With this hidden feature you can easily move some files to a new library.

Why is this good? Well, the new library only contains the files you are currently working on. In most of the cases this will be only a hand full. You will get blazing fast linking and round trip times if you do so.

So today I worked on a issue with SVGFont.cpp and my roundtrip time was way too slow. So I decided to apply this hack to our superb autotools based buildsystem!

So I have a hacky patch which is turning noinst libraries to normal libraries to avoid the running of ar/ranlib. I have created a libWebCoreHack.la, GtkLauncher and DumpRenderTree link to that library now. And you have to move the sources you work on from webcore_sources to webcorehack_sources. With this hack I have almost instant turn around times again.

How to use it: Whenever you work on a area move the usual suspects to the webcorehack_sources, relink once and then you can benefit from the fast link times.

*happy*

Pushing things forward

Pushing things forward

There is one thing of Tiny SVG1.2 that I really like. It is the possibility to embed audio and video. For video you can do transformations, filters and the usual stuff of SVG. TinySVG1.2 is popping up in more specs and recently I began to read DIMS again and well and thanks to the support of GMIT I had a go at it.

This shows parts of the TinySVG spec and the video was replaced with Code Rush. It is dog slow and needs some refactoring to SVGSMILElement and parts of the SVG RenderObjects to be merge able. The code should popup in my holger/dims branch soon.

Hacking on the WebKit codebase is so much fun that I seriously wonder if I want more of that…

svg12_video

Acid3, make QtWebKit catch up

Acid3, make QtWebKit catch up

qtwebkit-acid3

The Mac, Windows and Gtk+ port get 100/100 and pixel perfection for the acid3 test for quite a while but the Qt port was stuck somewhere else. How can this happen? For QtWebKit we decided to use as much of Qt as possible. So instead of relying on ICU we used the Qt Unicode support, instead of relying on libxml2 we used the QXmlStreamReader, instead of doing font matching and font/glyph caching we solely rely on QFont and QTextLayout to do the job. One had to apply some minor fixes to the Qt version of classes such as XMLTokenizer or TextCodec, or integrate SVGFonts into the Qt port as well…

What is next? We will have to get the rendering to be pixel perfect as well and then can merge the changes chunk by chunk. I’m going to sleep now, enjoy the screenshot.

QtWebKit in action

QtWebKit in action

Following up Simon’s QtWebKit in Action and to answer some comments from previous blog posts. Yes with QtWebKit you can embed QWidgets into HTML, you can control their position, size, etc. with JavaScript and apply CSS, invoke slots and such things. Lars, Simon and Girish created a demo for the DevDays it can be seen in action on the site Simon mentioned and you can grab the source from svn://labs.trolltech.com/svn/webkit/demo.

QtWebkit Status update

QtWebkit Status update

  • Simon and Jasmin went through the API of QtWebKit. Most of the changes where changing names and parameters of methods, signals and slots. And some minor but important behaviour changes. The Plugin API is probably the only remaining feature for Qt4.4 and Lars and Simon have already progressed nicely.
  • Simon went ahead and integrated QtWebKit into the Assistant on the way finding/marking of text was added to the QWebView and QWebPage API.
  • Benjamin (icefox) continues adding the basic features to our demo browser. It is an awesome testbed to test QtWebKit, see what APIs is missing and what pages need work.
  • We (this means mostly Simon) have fixed some rendering bugs of control/form elements with certain styles. Interesting remark. QCommonStyle::drawComplex is drawing PE_FrameLineEdit if you ask it to draw PE_PanelLineEdit, but only if your lineedit has a frame. Most of the styles assume a pristine/virgin QPainter when painting. In QtWebKit this is not true so we have created a StylePainter which will set a Qt::NoBrush and probably other things in the future. We know that painting scrollbars need a tweak when topLeft() is not equal to (0,0) on some styles. Note to myself if you see a drawRect call, the rect will be filled with the brush…
  • We (see above for the actual meaning of we) have enabled the PageCache. The result is that you can go back and forth without waiting minutes. At least I had to wait minutes as I’m on a GPRS line. For other the effect is not too noticable as they will have broadband and because we are likely to not properly cache the ResourceRequest/ResourceHandle and do a real request on going back. More investigation is needed.
  • I have been doing some cosmetic changes, I liked the Safari3 feature to resize multiline text edits. I made sure that it is working in QtWebKit as well. I didn’t see the sizegrip icon and started to poke WebCore, RenderLayer and wondered why I can’t resize. After a while I found a call to WebCore::Settings (each WebCore::Page has a WebCore::Settings and we wrap around it with QWebSettings) in the CSSParser which defines if certain things are resizable, so I set this to true in QWebSettings and still didn’t see the icon (after adding a bunch of them to our WebKit qrc). It turned out that the way we used BitmapImage to show PlatformResources wasn’t too clever, we stuffed a QPixmap in there but didn’t use the size or the content of it.
  • I have started to look into image usage, both QPixmap and QImage in WebKit and started to look for other areas where we leak, keep a reference too many and such things. Candidates of memory waste are keeping both a QPixmap and QImage of the same image, caching the downloaded data (in the WebCore::DocumentLoader). At this point I would like to find a guide to script gdb, I want to print the last three frames everytime ::ref and ::deref of a DocumentLoader or SharedBuffer gets called. Alternatively I will have to toy with VirtualBox to install Solaris, or get OSX Server and try to legally run it in a VM to get access to DTrace.
  • Memory usage. I have started to profile QtWebKit. I have used examp console of o-hand.com and massif a valgrind tool. I have to get used to the new reporting of massif. It is not generating a postscript file anymore but you have to use a tool called ms_print to look at the snapshots. I hope some one is writing a cool gui for it soon(tm).