Inner Qt

Lately I have played a lot with Qt. Generally it's nice and I think it's easy to adapt and get things done. Also the development of Qt have been blazingly fast, new features are implemented and it's going into good direction.

I have taken a closer look to the inner design of Qt. First note was that Qt is just one big collection of code. Of course it's divided into modules like QtCore, QtGui, QtNetwork, QtOpenGL, etc. But when you look the sources you'll see one big drawback: you really can't compile one module without compiling first almost all other modules. Also compiling only few classes or widgets is not possible.

The main reason for Qt being just a big pile of code is heavy usage of private members. In generally private members and classes are good. But somebody has led this into very wrong direction. Totally separated Qt classes uses each others private members/classes directly. That achieved by making the private members protected and listing other classes as friend classes. This leads to degeneration of the code. An extreme example is that QWidget, the very basic class in Qt. Let's see it's sources: qwidget.h. Total number of friend statements in qwidget.h is about 50. However not all of them are really used, but 50? Are you kidding? Then it hits me, what the heck does implementation of QPixmap::fill in qwidget.cpp ?

Another thing that does not fit in my mind is use of QApplicationPrivate. There's lot of use of it in qwidget.cpp. And I really don't get the point why? Why are these not public functions and members in QApplication or QCoreApplication? Of course there's some aspects which supports this kind of approach, but this was just an example. Such usages of private classes and members can be found all over the Qt. For example there's clean cases where private is used even if there's public member which does the same thing.

My point was that Qt is great, but could be even better if the inner design is reviewed and proper modifications made. I mean: using public members, avoiding usage of privates and friend classes and cleaning off all the stupidity. A good test could be: if you take a source files of a widget and compile it outside Qt source tree (compile with public API), does it compile without modifications? For most widgets and classes this should be true. Currently most of the classes fails this test. Of course using privates is ok when it's really needed. But I see no reason using privates so heavily as Qt currently uses.

Drafting a browser

After my latest post about Google Chrome, I was pondering how to use the process separating system on other projects or making a own browser with the same idea. Fortunately I found that there's GtkSocket and GtkPlug. With them you can easily embed other processes on a main process.

So we need a main application, which creates tabs and takes care of handling them. Quite easy job to do. When creating a new tab showing a new GtkSocket inside it. Socket id is passed to a new process, for example by launching a new process with exec and passing socket id (numeric value) as a command line agument. That's about the minimal required functionality for the main process. It just handles tabs and launches other processes.

The client application reads the numeric socket id from it's command line arguments, creates a new GtkPlug with gtk_plug_new (socket id as a parameter). Now it can just draw any Gtk+ widgets on that GtkPlug widget and show them. So now we can draw, let's say, a URL bar and for example WebKit/Gtk on that GtkPlug widget. And let's define some signals that when typing URL on the URL bar the URL will be opened on the WebKit/GTK. Now the client app is ready.

And what do we have now? A main app, which opens tabs, launches a client app and passes GtkSocket id for it. Client shows URL bar and WebKit. The contents of client app is shown inside the main app's tab view. Isn't that now a simple web browser, where every tab is running it's own, separate process? Somebody could now catch the idea and continue working on this kind of approach. And that's not just browsers. The GtkSocket is normat Gtk+ widget, which can be used like any other widget. One could make very interesting apps where one main app embeds other processes inside it and showing their content. Now anybody got some ideas? At least I do...

Google Chrome

Recently Google announced their web browser project called Chrome. They also released beta version for Windows. It seems to be a interesting project. Especially when they say that it's released as open source.

The main renderer of Chrome is based on Webkit. Webkit is quite good browser engine used for example by Apple Safari, Nokia S60 web browser and Google Android. On top of that Google has made it's own JavaScript engine, which seems to be faster than any other JavaScript engine on the market.

One good idea on Chrome is that every tab is it's own process. Also JavaScript runs on it's own thread making the web experience more better. Since traditional browser runs all tasks in queue it means that when one task is taking a long time, others must wait for it.

My first impressions about Google Chrome is that it includes great innovations and ideas, but I have also my doubts. There been also criticism about the EULA. What I'm waiting is that other browsers adapts ideas from Google Chrome and so everybody would benefit even if they don't want to use the Google's browser. I'm sure that Mozilla Firefox project will react soon. Better browsing times are about to come...

Ubuntu on Asus EeePC

I installed Ubuntu Eee on my Asus EeePC 900 some time ago and have been using it since then. I really like it. Screen resolution is ok, all my favourite apps are working and I can perform all the task I usually do.

The install process itself was painless, I made a bootable live USB stick from the Ubuntu Eee image, booted from it and installed it. After reboot Ubuntu started, and for example WLAN was working out of the box. First thing I noticed was that the touchpad was unconfigurable. I was unable to run gsynaptics. So I installed array.org kernel and enabled the elantech synaptics driver. Also xorg.conf needed some tweak in order to make gsynaptics to run. Shutdown had also a problem but unloading snd-hda-intel module on halt fix this problem.

Another thing was the sound volume buttons but fortunately there was good instructions on Eee User wiki. Another annoying problem was evolution launching every time when power cord was plugged in. Resolution was to remove /etc/acpi/events/asus-mail. After that there was one more problem: webcam. Resolution was to use ucview and to make some module tweaking.

Now I'm quite satisfied with my configuration. This is way more better than the default distibution. The performance is quite good, and there's enough memory for my use. I didn't even set up a swap partition, however it could be useful in for more powerful use. For light net surfing and desktop use I'll be just fine without swap. I doubt if I'll try another system since I'm too happy now for the Ubuntu.

Asus Eee PC

Recently I visited London. The trip was nice and I enjoyed the atmosphere, nice people and the feel of a big city. However I was lucky enough to get one Asus Eee PC 900 with 8.9" display, 900 MHz CPU, 1 GB memory and 20 GB SSD hard drive. It didn't cost too much, and got even extra warranty. It's UK version so no finnish key layout, and the power plug is also UK so got to purchase also a converter to make it work on european standard outlet.

Now I'm using the default Xandros distribution, got terminal (ctrl+alt+t) and I'm able to use apt-get. Nice system but I think I want more. Next thing is to try Eeebuntu and see if I like it better.

But I'll report more when I know better. Have a great summer...

Some tricks with N810

Recently I got Nokia N810. Of course I installed Handhelds Mojo "grumpy" on it. The installation process was not painless. Some struggling around and it booted to the login prompt. I was wise enought to set up a normal user and a password for it so I was able to login (N810 includes a keyboard, nice).

But that was just not enough. I wanted X. Easiest way seemed to be to compile Xomap package for the grumpy system. For my surprise it was quite easy job, some tweaking of course, but I got X running quite easily.

I got even touchscreen working, but HW keys just didn't want to work. There is quite a same situation, but unfortunately didn't find solution for that. Also mailed a question to the author of the post but got no reply from him.

However I'm quite glad to get this all working (grumpy + Xomap) on N810. It just proves that the Handhelds Mojo project is a piece of great work

Mojo on N800

Recently a port of Ubuntu for ARM processors was released. The project is named Mojo, and currently they've released distributions called Frisky (Feisty based) and Grumpy (Gutsy based). The first thought I had was to make it work on a real hardware. This time I chose my Nokia N800 tablet.

At the beginning I made a simple system with debootstrap. I was using a qemu based ARM system to install debootstrap to create the system for a specific directory. For simplicity I put resulted contents from the directory to a MMC card. I just made one EXT3 partition and copied (or really I used tar) everything there. I put the MMC card inside my N800 and used flasher to select boot from MMC. Booted and nothing seems to happen. Weird.

First I thought there's some problem with my system. After a thought find out that my system might boot but it won't show anything on the screen. The solution was to follow instructions how to disable boot splash screen and enable console on framebuffer. Now I was able to boot the device, startup messages from kernel begun to run, and finally the system from the MMC booted and show it's login prompt. Fortunately there was no keyboard available so I was just pressing the enter key to see that system really reacts for something.

Next I'd like to try to make real system working on the device. Meaning X and some apps running. Also want to try this process on my FIC Neo1973. But the greatest thing is that now I can use Ubuntu as my system on the ARM. Previously I was using Debian, but Ubuntu brings some benefit. I will certainly continue to play with these repositories and probably get something nice working...