Youtube on the N900

After my implementation of local rendering, Flash plays quite well on the N900. In fact, with a plain Qt flash loader (npploader – git://, I get ~70fps. With a QWebView, the fps goes down to around ~50fps. With a QGraphicsWebView, the fps goes to around 55fps. Tested with fps tester.

This is not so bad but youtube was still rendering very badly compared to Fennec. With help from Nokia folks, I found out that the codec being served for Fennec is H.263 Sorenson and Qt/WebKit was being served H.264. The difference in quality would have been blindingly obvious had I paid more attention ūüôā On the n900, Sorenson Spark is the fast codec that is hardware accelerated (Documented here). If you use N900 to watch Youtube, append &fmt=5 to the Youtube url for better viewing.

Youtube serves sorenson based on the UA and I did some elaborate tests to figure what exactly it was looking for in the UA so we can add the same to Qt/WebKit for Maemo5. The long result is below. The short result is that it expects “Firefox/3.5” and “Maemo Browser” in the UA. Unfortunately, we cannot add “Firefox/3.5” as that would mean Qt/WebKit might get served Fennec optimized sites ūüôĀ

One options, of course, is to contact Youtube and ask them to serve a different codec for Qt/WebKit’s UA but we are not pursuing this because this is really not important ūüôā I have a patch to Qt/WebKit that adds “Firefox/3.5 Maemo Browser” to our UA for * by extending the existing QWebPage::userAgentForUrl(). Simon and Harald are brooding over whether we should bother adding this change. Time will tell whether we will apply it.

Results of the test:

Current Qt/WebKit UA – Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3
Current Fennec UA – Mozilla/5.0 (X11; U; Linux armv7l; en-US; rv: Gecko/20100126 Firefox/3.5 Maemo Browser RX=51 N900

H.264 desktop UI
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox Maemo

Mobile UI (same ui as – 3gp/rtsp)
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser RX=51
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Maemo Browser RX=51 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 N900/Maemo Browser

Sorenson + desktop UI
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser RX=51
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 Maemo Browser RX=51 N900
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox/3.5 N900/Maemo Browser
Mozilla/5.0 (X11; U; Linux; en-US) AppleWebKit/533.3 (KHTML, like Gecko) Qt/4.7.0 Mobile Safari/533.3 Firefox Maemo Browser


NPAPI/X11 : Plugin Visibility

For the past week or two, I have been working on getting Flash to work on Maemo5/N900. Read more about it here.

Today, I fixed a part of 44594. For mobile, it would be very efficient if Flash gets notified when it goes out of view or when the browser is minimized. There has been some discussion about this but no no consensus. We have to move on and so we have decided to set an empty clip rect in the NPWindow struct to notify the plugin about it’s invisibility (I don’t like this, I prefer explicit notifications on what is happenning but oh well).

ATM, clip rect is always set to 0 in windowless mode which breaks the above mechanism. So, I set out to find out it’s meaning. I found that Flash doesn’t care about the value of clipRect at all which made is quite hard to figure what exactly it’s meaning is. A note from an Adobe person in the above thread seems to indicate clipRect is actually respected only on the Mac for Flash!

I now set the clipRect based on my understanding of NPWindow. If reading specs is your thing, please read the spec and see if your understanding matches with mine.

Read the spec? Ok, Quiz time.
1. In windowless mode, if NPWindow.x, y = (10, 10) and if the clipRect is (20, 20, 50×50) in _plugin_ coordinates, what should we set NPWindow.clipRect to?
2. In windowed mode, if a plugin of size 100×100 is at position 50, 50 wrt to the page, and we scroll 60 pixels in either direction, what is NPWindow.x,y and clipRect.

1. clipRect = (30, 30, 50×50). Atleast as per the doc, the clip rect is wrt to drawable and not the plugin’s origin.
2. NPWindow.x,y = -10, -10. clipRect = (0, 0, 90×90). The value of x,y is not debatable ūüôā It has to be set to -10, -10 based on empirical data and it’s actually wrt the viewport and not the page as the doc suggestes. So, I made clipRect also wrt the viewport.

Good news is even if your answers to the above are different, it doesn’t matter because Flash ignores clipRect ūüôā

66095 is the commit in webkit.


Flash on the N900

I have been working on getting Flash working well in Qt/Webkit on the N900. The hard work is done, you can find all patches here.

1. XEmbed support for the Flash on the N900 does not work very well. So, we just force windowless mode on all Flash.
2. Transparent flash is not supported and behaves the same as in opaque mode.
3. Opaque mode is implemented using the local rendering extension.

There’s some optimization work to be done which I plan to do next week.


Installing Maemo5 PR1.2 on the N900

Maemo5 PR1.2 for the N900 was released a couple of weeks back. You can see the features and bug list here – the most interesting for me being Qt 4.6.2 is now shipped as part of Maemo and Skype supports video calls and multiuser chat.

There are many tutorials on how to install but they drop terms like NAND, eMMC, FIASCO which made little or no sense to me. What better way to make the web a better place ™ than by writing yet another tutorial :-) So, here’s how you go about manually installing PR 1.2.

0. I like to understand what I am doing, so here’s what I found :-) The N900 has a 256 MB NAND Flash which contains the rootfs (of type ubifs). The boot loader and kernel goes into this NAND flash. The N900 also has a 32GB built-in eMMC. It contains a 2GB /home partition (ext3), 27GB /home/user/MyDocs (vfat) and swap. Installed apps go into /home/opt and thus the user is limited to 2GB of apps. /home/user/MyDocs is what you see when you usb mount your N900 on your PC. The N900 also has a external micro SDHC slot (remove the cover to see). This ‘external’ card remains unaffected by what we are about to do (it’s at /media/mmc1).

What we are going to do now is to reflash the NAND flash with the new PR 1.2 OS. We will then flash the eMMC. It’s optional to flash the eMMC. It’s only required when some new program that gets installed in the NAND misbehaves with old configuration files in the eMMC. I went ahead and flashed the eMMC too (for the heck of it). Important : The N900 will move content from rootfs to the eMMC’s /home/opt on it’s first boot. This means that you have to power on the N900 only after you are done flashing both of them.

Lastly, the term FIASCO stands for “Fractal Image And Sequence Codec” which I found after some very intense googling. It is just a compressions method (like gzip) used for the images.

Charge your n900’s battery so it will atleast last for 30 mins before you begin. Actually, it’s only a 5 min process but why take the risk.

1. If you plan to flash the eMMC, first back things up. There is no complete backup/restore utility on the N900.¬†There is a ‘backup’ utility under applications. Use this to create a backup of your contacts/calendar, bookmarks and some apps. Very important : this backup resides in eMMC itself (under /home/user/MyDocs/Backups). This means that unless you copy this backup folder to your PC, your backup is lost.¬†I don’t have any apps installed; if you do now is a good time to make note of the custom repos you added and list of custom apps. I just usb-mounted and copied over all my pictures ¬†and the Backups folder.

2. Get the flasher from (maemo_flasher-3.5_2.5.2.2.tar.gz). Works just fine on 64-bit linux too.

3. Get the images to be flashed from RX-51_2009SE_10.2010.19-1_PR_COMBINED_MR0_ARM.bin (for the rootfs on NAND) and RX-51_2009SE_10.2010.13-2.VANILLA_PR_EMMC_MR0_ARM.bin (for the eMMC). Important РI used the Global release instead of India since some reports suggest that Indian release does not have Skype Video.

The IMEI of your phone is under Settings->About (or power off and look under the battery).

4. Switch off n900. Press and hold the u key and connect usb to PC. You will see a usb sign on the top-right. Now run flasher,

flasher-3.5 -F RX-51_2009SE_10.2010.19-1_PR_COMBINED_MR0_ARM.bin -f

<success message>

flasher-3.5 -F RX-51_2009SE_10.2010.13-2.VANILLA_PR_EMMC_MR0_ARM.bin -f -R

<more success>

That’s it!

Reboot the N900. Dialing *#0000# will tell you the firmware version. If you go to a skype contact, you will see ‘video call’ :-) What about Qt? It’s all under /usr/lib. Here are the sizes (2.8M), (611.5k), (81.1k), (176.8k), (1.3M), (468.5k), (259.9k), (396.1k), (325.6k), (336.2k)

I guess they were concerned about using too much space in rootfs :-) So, the QtGui, WebKit and XmlPatterns are actually in /home/opt/lib (probably got moved from the rootfs on first boot) (10.7M), (17.5M), (5.5M)


maemo-bangalore N900 contest

I managed to get my hands on the N900 after a long long wait. But the path to getting the device was long and tragic. Here’s the story.

Back at (Dec 1st week 2009), I heard of a contest held by the Nokia maemo-bangalore team.  The sexy 3d pic on the blog got me all excited. So, at, including all my customer commitments, I worked 3 days/nights at a stretch to write a youtube video browser, cilantro (anagram of the irc nick of a good friend and lead of qt/webkit team to whom the app is dedicated to :-) ).  In all honestly, I put myself under some pressure to participate in the contest РI was already overloaded with work but I thought that if I can get my hands on the device I can improve QtWebKit Flash performance  since I was working on that at that point. So, you can understand my excitement when awaiting for the results.

Except it was not announced (we were told informally that it will be announced at end of We were told it was postponed to be on the 8 Dec 2009. Minor disappointment. But, fine. That didn’t happen either. After a few tweets and poking a nokia friend, the results were announced on 11 Dec 2009. No mail to winners, no notification on when we will get the devices. Just the blog. ¬†I mean no “thanks for participating, we will announce winners on xx date” even. Oh well. I forgive,¬†only because I won. But my joy wasn’t long lived.

To my shock, the winners had folks who had not written their app for the contest. Atleast following the links on the blog suggests that the apps were published way back. Surely, one expects code to be written around the time of the contest? I must be wrong, so to make a more judicious decision, I went around looking for the source. Except, with all my googling powers, I cannot find the source for any (except one which had a commit long before contest announcement). Still convinced that my assumptions were just wrong, I left a comment on the blog asking for the code. No response. I sent a mail asking for the code. No response. So, I poked the Nokia friend yet again. This time I got a response saying they *cannot* publish the code and they will send a mail to just let people upload code to maemo garage if they care. HUH!? So, here we have a contest for where the winners have been adjudged with no published code. Sad, really sad.

On dec 18, I was told it *might* take a month for the device to arrive (and only after I asked them). 1 month!? I mean I wrote this app to get my hands on it immediately. Maybe I am expecting too much. I wait. On Jan 8, I asked them what the status was. No response (see the trend?). So I poked Nokia friend again and I got a response on Jan 14, saying they will intimate me by phone. As, you can guess, nothing was heard from them ever again. On Feb 3, I mailed them again. No response as usual. This time I didn’t ask my Nokia friend. I had given up on the people running the contest and I was going to take this outrageous behavior public.

Amazingly on Feb 16 2009, I got contacted by the maemo team for the first time ever (i.e first time initiated by them). And I did end up getting the N900 but the whole thing was such a sorry experience that I will never enter a contest that involves the maemo-bangalore team. I am not even sure if I deserve the award and if the contest was a FOSS contest (we can never know until we see the source). I had given them the link to my source but they haven’t bothered updating the blog post.

@maemo-bangaloreyou¬†need to learn to communicate and in the least, atleast respond when asked questions. You should be ashamed of treating the community and contest winners this way. If you don’t have resources to do a good job, just don’t run contests. What you have done is a mockery of FOSS. I am not actually upset with the late delivery of the device but the way you ran the contest.

If I were Nokia, I would fire the incompetent person who ran the contest.


Flash in QGraphicsView

Over the past couple of months, I have been working losing sleep over getting Flash to work in QGraphicsView on all platforms.  The good news is that flash now works in QGV on all platforms. Yes, that means that not only can QGV display Flash but can also rotate and transform flash when using QGraphicsWebView. IMPORTANT: Flash embedded in a QWebView using QGraphicsProxyWidget is NOT supported.

Youtube in QGVLauncher
Youtube in QGVLauncher

What follows is a brief summary of my work and the list of patches that you will need to get Flash working with Qt 4.6.0. Note that when I say plugin below, I mean NPAPI plugins like Flash. They have nothing to do with QWidget based plugins. QWidget based plugins should work in Qt 4.6.0 when using QGraphicsWebView. I have also simplified the concepts (in favor of being completely correct) in the post below so that it is readable.

Windowed and Windowless plugins

Flash gets embedded into web pages using an API called NPAPI (Netscape Plugin API). NPAPI provides two mechanisms to embed plugins into a web page РWindowed mode and Windowless mode.

Windowed mode – the idea is that the plugin gets a native widget handle and does it’s own mouse, keyboard processing. For example, on Windows, we give the plugin a HWND. The plugin will install a window proc and process events directly (i.e the events are never seen by the browser). On X11, the plugin embeds itself into the Window using XEmbed. When the browser scrolls, the browser moves the native window appropriately. Mac doesn’t support windowed mode.

Windowed mode should have been enough but it has a limitation that it interferes with the z-ordering of html elements. ¬†Some sites like to put html _over_ their flash content (for example, menus). This can be achieved by making the menu html have a higher z-order than the plugin. Can you spot the conflict interest here between z-ordering of native widgets and z-ordering of HTML elements? The plugin native window is a child of the browser’s window and we have a situation where the browser wants to paint HTML¬†after the child has painted itself! This is not possible since a parent window always draw before it’s child. There are other disadvantages too – it is also impossible to¬†transform plugins (native widgets are rectangular), making them¬†transparent is tricky and printing plugins requires lots of hacks.

Windowless mode – The idea here is that plugins just paint to a pixmap – platform’s graphics context to be more precise (HDC on Windows, Pixmap on X11, ContextRef on Mac). It is now the browser’s responsibility to pass (forward) mouse and keyboard events to the plugin. Since the browser now contains a screenshot/snapshot/pixmap of the plugin, the browser can transform plugins, draw it in the correct z-order, make is transparent even. The main disadvantage here is that it can tend to be a bit slow.

Evan has a¬†better explanation of the modes. There’s also one by¬†Robert from which I originally learnt about these modes but I cannot find the link anymore).


I keep saying Plugin but really we care only about Flash ;-) At least, for the moment that is our priority. All version of Flash supports Windowed mode. Only Flash 10 supports windowless mode on linux.

Flash lets the html/plugin author control the mode of operation using the wmode parameter (i.e pass it as part of html <object> tag). By default, it operates in windowed mode. Setting wmode to ‘transparent’¬† makes the html below visible through the flash. If wmode is set it to ‘opaque’, the html will not be seen through and the flash will have some solid background color (think of it as Qt::WA_OpaquePaintEvent, it allows for optimizations). transparent and opaque mode are implemented using ‘windowless’ mode. Here’s a¬†great site to test out these modes in action.

Important: When in windowed mode, Flash expects a native window handle/id. A browser cannot force windowless mode – the mode is decided by the plugin. A browser can, in theory, say that it supports only windowless mode but this makes Flash crash (at least) on Linux. Hence, when we have a site like youtube (which uses Flash in windowed mode) in QGV, we need to come up with a way of providing flash with a window handle. There are two ways to deal with this problem – we can either give Flash a fake native window, we then grab the contents of this fake native window and paint it wherever we want OR we can inject the wmode ‘opaque’ parameter when loading flash in QGV. The former approach is platform specific and requires lots of work. The latter is a 10 line patch.

Plugins in QGraphicsView

Items inside QGraphicsView are not native widgets. They are just items on a canvas that can be transformed and visualized using multiple views. This means that windowed mode of plugins is not feasible (apart from the fact that we have no native widget handle for items on canvas). To make plugins work in QGV, we need to implement windowless mode.

X11 (Linux)

Windowed mode on Linux has already been implemented in Qt 4.5. What was missing is the windowless mode support. One nice feature is that Flash is able to fall back windowed mode when the browser says it cannot support windowless mode (vice versa crashes as I noted before). This is the reason that sites that use windowless mode work in QWebView with Qt 4.5.

To support Flash in QGV, I started out adding windowless mode support. In theory, implementing windowless mode is a matter of passing a X Pixmap to the plugin, but there were lots of problems. The entire history is on bugzilla bug 20081.

  • Flash uses a different X Display connection – the default one provided by gtk/gdk and not the one that Qt provides it. Ouch. This means that when flash paints something, we have to XSync to get changes reflected in the Qt connection and vice versa. The uglier part is that Qt somehow needs to get hold of gdk’s Display without linking to gdk. It’s all very hairy. (r49158).
  • Flash uses a different X Visual (the default system visual) rather than the one provided by Qt. This means that even if we created a 32-bit pixmap, Flash won’t be able to draw into it because it uses a 24-bit visual. Since people really wanted transparency to work, the solution is to grab the contents of the backing store to fake transparency. Very hairy stuff. This solution works in QWebView but not with QGraphicsWebView (r49169). We have¬†turned off transparency in QGVuntil this Flash bug is fixed.
  • The NPAPI requires X Pixmap. QPixmap may or may not be backed by a X Pixmap depending on thegraphicssystem.
  • Print preview implementation of Qt holds a reference to the X Pixmap (because of QPicture). This meant that when the user prints we have to ‘let go’ of the X Pixmap because the print preview has to remain unaffected by on screen changes. At the same time, someone needs to destroy this X Pixmap when the print preview dialog close. This one was very tricky to solve. Actually, I didn’t solve it,¬†Samuel did :-) (r50123)

All windowless mode changes for Linux are part of Qt/WebKit 4.6. QGV on linux can display Flash¬†only in windowless mode. If Flash is in windowed mode (like in youtube), it does¬†not work.¬† As mentioned there are two methods to fix windowed mode in QGV . Method 1 – we create a fake window and grab it’s contents. This can be achieved using X Composite and X Damage (as done in¬†Fennec). I have a patch at¬†31232 but it requires more work. Method 2 – we can inject wmode opaque. This has been committed as part of¬†32059. If you need youtube to work in QGV, you need to apply that the patch¬†r51759 on top of Qt 4.6.0.

Mac OS X

On the Mac, plugins operate in Windowless mode _always_.¬† There is no such thing as windowed mode on the Mac. NPAPI¬† on Mac supports various¬†event models and¬†painting models. Event model dictates how we pass the mouse/keyboard events to Flash (i.e which data structure is used to report events – NSEvent or the classic EventRecord).¬†¬†Qt/WebKit only supports only the carbon event model and the CoreGraphics drawing model (there’s a open gl drawing model, core animation and a QuickDraw drawing model). ATM, only Carbon based apps can display flash.¬†Qt/Cocoa apps (32 or 64 bit) cannot display Flash in QWebView or QGV. (Confusingly, this has nothing do with Qt/WebKit not supporting cocoa event model. It is possible for Qt/Cocoa apps to display using the carbon event model. This is tracked using 32376)

Now to the carbon event model – how it works is that the browser provides the plugin it’s window handle (a WindowRef), a ContextRef and the position (a rectangle) inside the window and Flash draws itself there.

Simple, no? You wish :-) Unlike in QWebView, one cannot provide a rectangle as the position of Flash since the Flash could be transformed. For those new to Mac, ContextRef is like a QPainter (it can be over any paint device – a widget, pixmap, image). What we do is to get the ContextRef of a QPixmap and pass the position as (0, 0, width, height). Unfortunately, Flash requires the WindowRef parameter to be valid because it seems to be using it to detect if the window is ‘active’ for processing mouse move events. To workaround, we create a fake hidden window. In addition, we also fake the fact that this fake hidden window is the active window (else Flash won’t process mouse move events)! If you thought this was insane, you should check out what the¬†chrome devs do (they intercept carbon calls of Flash by injecting a library using DYLD_INSERT_LIBRARY at runtime). See¬†31183 ,¬†31794,¬†31979 for more history.

None of the patches are in Qt 4.6.0. You need to apply  r51234 for painting; r51105, r51412 for mouse handling andr51485 for context menu position. Currently, printing does not work on the Mac. This is tracked at 31975. Flash transparency works fine in QGV.


Windows has always supported Windowed and Windowless mode (Thanks to Apple). Printing already works thanks to some awesome hacks. Flash transparency works in QGV. However, the problem (as mentioned above) is that Flash expects a HWND when in windowed mode. So, youtube inside QGV requires a HWND. Fix is to inject wmode opaque. You need to apply r51979 on Qt 4.6.0


The hardwork here was done by Yael. See 29302 for more details.


I have done the necessary cherry-picking and published a branch (based of 4.6.0) at With that branch, Qt should support Flash in QGV on all platforms in all modes.

More information

If you need more information on internal working of plugins, Yael, Torarne and I have written Drop by on irc channel #qtwebkit on freenode for any clarification. Performance needs some love, we are working on it.

My work would not have been possible without the tireless reviews of¬†Simon,¬†Holger,¬†Kenneth. Thanks guys! Simon, in particular, who¬† kept pushing me to try out various possibilities/hacks. I cannot thank him enough! And it’s a matter of great pride that I am now a¬†webkit commiter! :-)

The guys at Linden Lab have made ubrowser support Qt/WebKit (llqtwebkit). With the above changes, flash works in ubrowser.

Qt/WebKit in ubrowser


Qt DevDays 2009 SFO

(A very late update on DevDays 2009 SFO. I am one lazy blogger)

In an unexpected twist of events, I ended up attending Qt Developer Days at SFO. I had just one week to get my visa, flight and hotel bookings in place, so I wasn’t too hopeful. Amazingly, I got my visa interview appointment in 2 days¬† and received the passport by courier in another 2 days! Also, the chennai embassy didn’t have any long queues that every indian so dreads. Either the U.S.A visa process has made giant leaps or it’s the downturn .

1. Sebastian Nystr√∂m talked about Qt being everywhere and that it was being used by Google, Skype et al. One of the slides showed a screenshot mashup of ‘cool’ Qt applications. I was pleasantly surprised to see Hyves Photo Uploader in there :-) Slides here (slide 11, we have the highest z-order even)

2. Tapani Mikola mentioned the ‘death of widgets’ in one his slides when presenting QML. QML is awesome and the talk was excellent but I am a bit saddened by the ‘death of widgets’ phrase – as much as I like all the new developments, qgv is no where near providing all the ui elements required to develop applications on the desktop. Ask an app developer, he will give you many examples of widgets that Qt lacks. When was the last new widget that was added to Qt, that made you go ‘nice!’ or ‘finally!’? Maybe I am reading too much into the phrase ;)

3. Meeting up with old friends made me really miss Norway and the oslo development team :(

4. Major shortage of Qt developers РI lost count of the number of people looking for Qt developers and consultants. The interest in Qt has exploded after Nokia has taken over. I have been in 2 dev days as Trolltech employee before and it was nothing like this. It was crazy, a few people had signed up for the conference only to hire more developers/consultants. Funnily, I even ended up getting two job offers with no interview! If you are a Qt developer and out of job, you are not looking at the right places. On the topic, we are still hiring.

5. Qt Certification at SFO didn’t see as much participation as munich, but Vladmir thought it was up to a great start. Roop and I are Qt Certified even :)

If you missed Dev Days, be sure to plan on being there the next time (the munich event was even bigger and had 700 delegates). If you want to keep up with the trends in Qt development, there is nothing like meeting the people who are making the change. You just cannot afford to miss these events.


~/research cleanup (part 2)

Final part of my ~/research cleanup

1. slidelistviewselection – A widget in which item selection moves with animation from one item to another. I made this initially for an embedded device on which itemviews was too heavy.

2. skinnable mediaplayer – An example that shows how to create a skinnable Qt app (see my old blog post).

3. bubblelist РAn example of how one can create a scrollable item in graphicsview (like QScrollArea which scrolls  i.e positions a big widget)

4. lineeditwithclearbutton – Line edit with clear button (see my old blog post)

~/research cleanup

A habit that I picked up from my job at Trolltech was to put all my experimental code in a directory called research. Each project gets its own sub-directory there. We used to also have a similarly named folder in p4 depot and it was totally unmanageable. I wonder what happened to all that code after they moved to git – there were hundreds of very interesting code samples there.

Back to me, over the years (yeah, like past 4-5 years), I have abused my research directory for examples, bug reports, writeups, screenshots/videos, blog posts and I thought it’s about time I clean it up :) . I have been cleaning up 10-15 subdirectories a day for the past week (I have ~100 more to go) and I have to admit I grossly overestimated the value of the stuff in there :) . But here’s what I found worth sharing so far (all of them are Qt examples, of course):

  • customfont – How to load and use custom fonts.
  • mplayerembed – How to embed mplayer into your app and control movie play (X11 only)
  • customnetworkreply – This lets you create custom url’s inside qt/webkit. For example, you can embed a myapp://give/me/some/stuff or a http://myapp/foo.png. Code inspired from assistant.
  • textlayoutprimer – I wrote this one when I was trying to understand how laying out text works inside QTextEdit (using QTextLayout). More didactic than an usable example.
  • translucentbackground – Translucent background example (Uses ARGB visuals, requires composition manager)
  • clipboardwatcher – Displays content of clipboard/selection as they change. Very useful to test dnd. I think I stole initial parts of the code from a similar Qt example.

I am still figuring what is a good way to maintain all this sample/throw away code. I also have ~/tmp where I have code that I can nuke without any thought. Any suggestions? What do you do? A problem I have had is I never manage to find the right code samples when I need them. I have already found many dups when cleaning up!


Displaying html with animated gifs

When consulting for Hyves, we wanted a light-weight widget that displays html and animated gifs (for smileys) for the chat client and for tooltips. The option to use Qt/WebKit was out since we intended to create numerous instances of this widget (it consumed lots of memory) and the rendering was not as fast we would like. QLabel does not support animated gifs, so that was not an option either.

Instead of writing a basic html parser, layouter and renderer, I thought I can somehow trick QTextDocument into displaying animated gifs. You can see the basic idea in this kb but to get it working with animations¬†wasn’t easy. One good thing about adding the feature to QTextDocument is that you can set it on QTextBrowser and QTextEdit.

Without further ado, get the code here. Label is a richtext label that does not support links or selection. TextBrowser is a browser that supports selection and links. TextEdit is an editor with support for undo/redo.

P.S. Thanks to Hyves for making it possible to actually publish this code; they released most of their code as GPL.