Picking (a) Company

Picking (a) Company

Many people don’t know what my nickname means even german speaking ones. The direct translation would be tick, these animals that sit on leaves, bite people and suck the blood, the ones that can cary scary deseases. But there is another side to the word, a political one. In my youth this word was used to refer to punks and similar associates by right wing people, I was labeled this way. And this is nothing to be ashamed off, the view of kids with weird haircuts (or none), not washed hairs, broken and dirty clothes probably disrupted their lovely right wing world, but their world deserves disruption, change.

When joining irc I had to pick a nick and the most often used word for me not equal to holger or freyther was zecke so I settled with that. And looking at it now, as a discordian pope, it was a good choice.

Like many hackers I started to work from home, communiciated through irc, started to work on projects, collaborated, learned (thanks to a guy named tronical willing to answer any question), grew, got better, continued to make stupid mistakes. Saw Mr. Eilers and Lauer finishing their PhD. I believed an ideal FLOSS career would be to work remotely from home, little did I know, little do I know.

I started university, joined the RoboCup team, started internships and got hooked to the power of teams in one physical place. Having many brilliant people at the same place working together, sharing success and helping each other to recover from failure is the best way of working. At least I have not witnessed something better than an awesome team.

In december I decided to resign from my current part time job, we/they are an awesome team, because I wanted to work on FLOSS again. So my constraints for finding a new job are now FLOSS + awesome team.

I had the opportunity to visit the Oslo trolls (they do not live caves, in contrast they are close to the sky, the 5th floor to be exact) and it is an awesome team. Brilliant, international people, there is little more you can ask for. And even if you do ask, there are soft drinks (no Club Mate though), food and vegetables, and some people have chocolate… I started to verify if the requirements of FLOSS and awesome team are fulfilled and oh my god, they are. The only downer was. Oslo trolls live in Oslo, and I’m in Berlin (at least 2 to 4 more terms). After a lot of flirting, tears and counseling (or eating spaghetti at Berlin based usability experts) I was forced to accept that Oslo trolls live in Oslo and even with the power of the mind of fooling myself applied, Oslo is not another name for Berlin and is really not referring to the same place. Looking at the size of the universe the difference from Berlin to Oslo is really minor, but if you happen to be in one of the two cities you recognize that even this minor difference is significant. Specially working with simon would have been ueber cool, it looks like it has to wait some more years. So yes Trolltech has the simon factor and its weight is really really heavy.

To keep a long story short, there are two other companies that I really like because of doing FLOSS and having an awesome team and these are o-hand.com and OpenMoko. To stop the flirting and crying tears I’m going to do a project for OpenMoko, I want to see them finish the GTA02, ship it to the people and want to see OpenVG capable hardware with open drivers coming.

Harald Welte helped in drafting the NDA of OpenMoko and at no surprise there are exceptions for FLOSS. I agree with rms that NDAs have victims, like he was victim of a donated Xerox printer and not able to fix the driver for ITS (awesome book, a must read), this NDA is going to have victims as well, victims that need to know the pricing of hardware, business plans, and all the stuff I do not care about. There is no doubt that the software I write will be FLOSS, will be released on day one and I can talk and discuss about it as much as I want as it is definately not covered by the NDA! You certainly know when not to argue. Oh and on to the team. I had the pleasure to listen to a discussion of Werner Almesberger and raster yesterday, a bit disturbing but totally awesome! I’m looking forward to meet some of you after FOSDEM in Taipei! So let there be Qtopia, Qtopia on X11, next to Java,Gtk+,FLTK+,EFL,FooToolkit and any other Free Toolkit all buildable from OpenEmbedded!

Let us be productive, innovative and provide prior art for mobile computing for years to come! With all the cool people working at OpenMoko it is a pleasure to say… “Hello Moko” as well.

PS: Ironically almost one year after I considered joining initially.

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).
The Joys of debugging WebKit

The Joys of debugging WebKit

When working on WebKit and the platform layer you come to a point where your primary browser is going to be WebKit based (or already is because you use Safari, OmniWeb,…). If you happen to use a platform that is not developed by Apple (Qt, Gtk+, Wx) you are going to be the first to see certain issues. I’m currently in this fantastic situation and have issues to see, understand and resolve.

This is a brief summary of two issues Simon and me were looking into at the wonderful 24C3 this year. We have looked into GMail and Yahoo Mail.

The Yahoo issue started with the attempt to sign into my ancient account, and this time the issue wasn’t to remember my password. Our Qt Demo Browser went into a infinite loop of redirections. So what was wrong? The obvious thing to blame is our networking implementation and the brand new QNetworkAccessManager and related classes. And yes some issues were found in our networking implementation. For redirections we have told WebCore more than once that a redirection is happening, we have missed one redirection code. To cut a long story short, this didn’t fix the issue. Cookies are always important so we checked them, fall victim of wireshark as it is truncating the decoded HTTP header and it looked like we didn’t send the full cookie string. It fooled us for a second or two and then we remembered our HTTP and Cookie implementation must be perfect as Thiago wrote most of it. So I started to find out where this redirection gets triggered, joy it came from a timer, so who started it? And we saw that it was coming from JS, so it was something embedded into the site. We signed in with https://mail.yahoo.com, got redirectred to a US server, then to a German one and then sent back to http://mail.yahoo.com. Note that the last redirection is going from http to https. So once again the WebKit Web Inspector came to rescue and we searched for “http://mail.yahoo.com” in the sourcecode view and two hits where revealed, after not starting the redirection timer when it is going to http://mail.yahoo.com. The second hit was interesting as it pointed to a piece of javascript code that was asking the DOM for cookies. Our CookieJar implementation was a bit selfish as it didn’t want to share all relevant cookies with the DOM but only one, after convincing it to return all relevant Cookies the login and sending mails finally worked!

The Gmail issue. You can sign in to Gmail as we pass the google cookie test, you see the full version of Gmail and we were not able to click any links. The JS Code google is sending is highly obfusicated so debugging is no fun at all, we went for the easy solution and updated our User Agent string, magic happened and we were served another version of it and it made our browser terminate in an assert in WebCore::FrameLoader. The next easy thing was to git merge the Safari-3-Branch into QtWebKit, recompiling, login, ASSERT, *joy*. With the usual and fantastic help of the apple folk I got pointed to #15765 and yes we were hitting this bug. I can tell you reducing Gmail to a test case that is actually exposing the bug is no fun, actually it is because it is challenging and something totally new for me. So after understanding and proposing a solution for this common issue, I have to fix the DumpRenderTool/run-webkit-tests relationship and I can then probably land this fix as well. With it you can go to gmail, browser your mail, see your chat logs but we still have some unimportant issues left like being able to send mails…

So QtWebKit is improving day by day, we mostly implement and fix code in the platform layer, sometimes go to other parts of WebCore and do fixes there.I think it is only a matter of time before we start doing fixes and improvements in the HTML, SVG and rendering implementation.

WebKit is highly addictive, try it out 🙂

PS: I’m going to leave my friends at GMIT at the end of the month, do the math.

WebKit Demos for Qt4.4

WebKit Demos for Qt4.4

The Qt4.4 Technology Preview 1 is out and webkit is integrated into it. It is the same code as on the public WebKit.git repository, actually the copy in Qt is always a bit behind as we do the development in the public git repository.

After integrating QtWebKit into Qt we needed a small demo application. So we wrote a small browser and the result can be found in demos/browser, an older snapshot can be seen below, and the rsync copy of Qt has a newer and better version. It makes a really good test case for our API and implementation. We see what bits are missing when doing interesting stuff, when trying to login and use webservices we see what is broken. So we started eating our own dog food and most of us enjoy it. This post gets written using this browser and a fully working gmail, flickr is quite near.

I hope you enjoy this small demo application and we will continue to improve this browser, QtWebKit and our Qt4.4 networking stack. So make sure to watch the rsync versions of Qt as it is highly addictive.

Old Demo Browser