Trolltech, Qtopia and the Neo. Welcome to the Challenge.

Trolltech, Qtopia and the Neo. Welcome to the Challenge.

I have bashed Trolltech publically and privately a lot but I can do the opposite as well. Last November I have celebrated a birthday for Trolltech for going proprietary. But some things have changed. They have released Qtopia as GPL but in contrast to previous releases they publish maintenance releases in time as GPL as well. So this is really awesome and I hope this continues with the next major release.

It is true that certain features such as SXE, Phone library and probably more is missing. But for SXE there is the BitFrost replacment of OLPC, for the Phone library one could implement it using the Moko libgsm. So technically there is no obstacle in porting Qtopia to your device and fix the bugs on the way. Politically I would like to see Trolltech to get more involved with the community.

Trolltech is facing several challenges. No community project is actively working on getting Qtopia on a real device with the aim to make it usable. It is one thing to see the home screen but it is a totally different story to create a usable, working product. So the two challenges are to find some one integrating Qtopia in the public and bringing it to product quality. The other is Trolltech being capable to listen to feedback and to incorporating patches.

The other related challenge is exposure to the community. You can go to a shop and buy a GNOME Mobile and Embedded device. You are able to write your own applications, you are able to synchronize it with your desktop. Sadly there is no Qtopia product you can buy in shops, none you can reprogram or write third party applications for. (Same applies to Windows Mobile and Symbian as well)

Integrating into the community. There is a lot of focus on Mobile and Embedded systems within GNOME. Technology such as Evolution Data Server, Telepathy, Tinymail, GStreamer looks well done, can run on consumer electronic and provides value to a system integrator, developers and end-users. Trolltech, while Qt can integrate into the glib mainloop, is not integrating with such efforts but is creating non interoperable island solutions.

E.g. if you compare Evolution-Data-Server for PIM with Qtopias solution. AFAIK it is using vCard/vCal/iCal compatible model. This is a pretty good idea as it easily allows synchronisation with Evolution, Kontact, Outlook and iCal on OSX. Qtopia is using an incompatible subset. If Qtopia would have interfaces for synchronizing (it lacks them) it would not be easy to synchronize using iSync, OpenSync, etc. Is there any reason not to use a iCal compatible model? I don’t think so.

Max brought this issue up on qtopia-interest and the answers were not satisfying. It looks like there are difficulties to abstract the Model of an Event, Contact and its visual Representation.

But there are more issues with the developers. I have the impression some of the publically speaking engineers don’t understand the domain of embedded/mobile, low powered devices. Before powertop was released I spent some time stracing Qtopia. In contrast to Qtopia2 there are a lot less timers running, actually the only timer running is responsible for polling /etc/mtab for changes. What is wrong with polling on a 2.6.21 linux system? The list is long but let me highlight inotify and hotplug/hal.
The lame excuse to not use modern features is that Trolltech still targets linux1.3 and gcc1.4 devices. Qt is famous for abstracting API that work on any platform. So they are not able to use inotify on a inotify capable and poll on linux2.4? Ironically Qt is able to do so. It provides a QFileSystemWatcher to do this. It works on Windows, OSX, BSD, Linux. It can use operating system assisted technologies like inotify or fallback to polling. So why doesn’t Qtopia use this functionality? There lame answer is because they can poll better in Qtopia.

To summarize this larger post let me hightlight the points

  • The Qtopia Team gets little feedback from paying customers as they have interest in selling patches back to Trolltech

  • No OpenSource project is doing the hard work on integrating Qtopia to a device. So Trolltech is not receiving feedback from us.

  • The Qtopia Team is not looking at current technology and falls behind.

  • The Qtopia Team isn’t winning OpenSource developers to port their applications to Qtopia, or to make them integrate Qtopia based devices with their applications (as Trolltech has no interface for that).

I don’t know if this is due your ROADMAP, the size of the team, the time you have available but finding this is left to the reader…

I think the key is a device in the hand of every user and developer. The Neo1973 promises to be this device. Provide Qtopia for that device? Create a project on labs.trolltech.com, integrate on linux2.6 and provide full GPLed root filesystems. E.g. by releasing your phone library or using Moko’s libgsm.

WebKit Gdk port

WebKit Gdk port

Wow, I decided to work on WebKit in the public for OpenMoko as I thought the interest in WebKit was quite low. That is luckily not the case. There are a lot of people interested, some of them are allowed to work full-time and some part-time on it. From an Embedded Linux point of view the main obstacle of WebKit is storage size. It is doing million times better than Gecko but there are still some issues.

  • Require libicu for Unicode handling. This weights almost 4MB of storage

  • libxml2 just for XML tokenizing

  • XPath and XQuery support in webkit

But these can be omitted and WebKit can be slimmed easily. But it needs to be done.

RSS Reader updates

RSS Reader updates

The RSS reader is capable of caching feeds. Inspired by reading the “Mythical Man Month” this winter I have created a MokoCache to control the storage size of the feeds. Well the API is present but there is enforcement on the size yet but it would be easy to add. Caching of images and displaying of HTML is still not implemented.
I’m busy hacking on WebKit/Gdk, keeping it compiling, making it work and slowly improving it. I have finally mailed Sean and asked him to contact the designers to give answers to some of the remaining questions.

  • What do we want to configure and how should the configuration dialog look like?

  • Should one remember which posts have been read, should one be able to see the remaining unread ones?

  • Should one store posts automatically, should one only store important posts?

  • How should one forward a feed entry?

So hopefully while Sean and his designers find these things out and specify them I will be able to clean up the code a bit. This was my first piece of Gtk+ from scratch and I did lousy on some parts. Luckily I have a list of things I did wrong and can concentrate on them.

I hope to hook up WebKit to it soon and then we have best-in-class rendering of these feeds. The only obstacle for a real release is slimming WebKit a bit. But more on this on another topic.

human crisis? I don’t get people

human crisis? I don’t get people

  • I don’t get it why people refuse to read NEWS and UPDATING files and instead start randomly deleting files and directories on their disk.

  • I don’t get it why people refuse to read NEWS and UPDATING and waste hours of their time compiling and recompiling applications and libraries.

  • I don’t get it why people refuse to read NEWS and UPDATING and mess up their system by randomly moving and copying files around

  • I don’t get people who scream for recipes can’t follow them. And instead of looking at the error messages chaotically copy, delete and move files around. Where the solution is to just follow the recipe.

  • I don’t get people with the habbit not to think and instead randomly doing chaotic stuff messing up things completely. It just feels wrong if you need to cd tmp/work/foo. Don’t do that until you know what you do…

I should switch to sociology to understand people better…

RSS Reader updates

RSS Reader updates

I’m still happy with libmrss as it allows me to completely focus on the representation and management of the data. Today I finally found the time to work on the application again and progressed nicely. My RSS RFC822 date parser was finished, I looked into check the unit testing framework and wrote unit tests for my parser. I added check to the build process, fixed the internationalisation of the reader and made use of the GtkTreeModelSort to allow sorting by Subject and now by time. The time sorting uses my RFC822 date class.

Yesterday I found lcov which means I can throw my own tools to generate these information away and instead improve the perl based tools where needed.
Looking at one of my blackbox unit-tests I recognize how fragile it is. Don’t ever run make check on a day switch as this violates the invariant of the check.

Hopefully GtkTreeModelFilter will be used by tomorrow. I hope to find at least some spare minutes to look into it.

good night, happy easter, I’m tired…
z.

OpenGL videos

OpenGL videos

As promised check http://www.openembedded.org/~zecke/opengl/ for my first compiz and OpenGL expierence. This simple plugin gets the texture of one of the active top level windows and either draws it on a cube or draws many many rotating and scaled rectangles using this texture. The ambilight effect is due me not unbinging the texture after I’m done drawing.
I really can’t wait untl OpenGL ES gets common on mobile devices.

PS: Mallum I think I have found video-cube.c code in one of the OpenGL tutorials on the net. 🙂

Blogs as Open TodoList?!

Blogs as Open TodoList?!

Things to do

  • Take more tests/exams…

  • Make sugar run on Feisty and use exmap and massif to compare the WebKit/Qt to Mozilla. Somehow only the sample/test app is working and the webactivity is not. I really need to do this and ping danimo and send a mail to laptop.org

  • Setup automatic builds and coverage generation for KDE. But KDE4 on FreeBSD needs some work

  • Find some more time to spend on dolphin

  • Finish the new BitBake parser

  • Finish my tinderbox efforts

  • Much more… 🙂

OpenEmbedded and SHA256,MD5

OpenEmbedded and SHA256,MD5

Well,
another feature we have talked about and people should start to use. OpenEmbedded has a new file it is called conf/checksums.ini and can contain MD5 and SHA256 sums for the files OpenEmbedded will use. This can be checksums of TARBALL_STASHS, local files or the usual ftp/wget. IMHO we should make this file as complete as possible and strictly require sums for http/ftp downloads. Currently this file only contains one single entry file-native 4.20.

And as people like screenshots here is an example

[file-native-4.20-ftp://ftp.astron.com/pub/file/file-4.20.tar.gz]
md5=402bdb26356791bd5d277099adacc006
sha256=c0810fb3ddb6cb73c9ff045965e542af6e3eaa7f2995b3037181766d26d5e6e7

So please extend this file!

Writing Compiz plugins

Writing Compiz plugins

Compiz is a really promising thing. Together with AIGL/XGL it basicly allows you to get any XWindow as a OpenGL 2D Texture. This includes Gecko, SDL games, ancient apps, videos. So you really get everything as a 2D Texture. Using this texture allows you to do funny things. I just returned home after doing one of the many cool things. So what we do is grab the texture of the currently active window and draw many many rotated quads, triangles, polygones (X,Y,Z axis rotate). So we had like 1000 quads rotating and spinning on your desktop. After doing that we started drawing rotating cubes with the content of your running applications. So I think DoKu and I had some fun doing that but how did we get there?

Well Compiz is badly docuemtated, actually there are no comments at all and the plugins contain some weird code that really deserves an explanation, specially as some routines are complicated and could be written with less lines in a more clean way. Writing plugins is not documented at all, how to load plugins is not documented at all. But our goal was to write a plugin so we started writing a skeleton that just gets dlopened and everything is fine. Well we thought we wouldn’t need a lot of time. Change the Makefile.am, add your plugin skeleton, get it dlopened. Well without editing a one million line huge unreadable GConf schema you have almost no chanche in getting your plugin loaded by Compiz. Well almost as there is a ini.c plugin, so we edited this plugin to get our new plugin loaded, we had to reorder the DEFAULT_PLUGIN string a bit to make it work but in contrast to gconf.c this is doable. This is required as compiz effectively only loads from plugin supplied on the command line.

Plugin loading works the usual way, there is one exported method that returns a struct you have to fill out. This struct contains ABI version and function pointers for certain operations. These include initializing and closing the Display, the Screens attached to the Display and the Windows attached to the Screen. Providing functions for the Screen and Display is mandantory otherwise your application will crash.

Compiz allows you to store private structs for CompScreen, CompDisplay and CompWindow. You have to request a privateIndex (there are three methods for that, a global one, one for Screen and one for Display) and then you are free to store stuff inside the private array at this index. So you will endup creating your FOO_DISPLAY, FOO_SECTION, FOO_WINDOW macros like every other compiz plugin has.

Initialization works the following way. First the normal Init method is called, then the one for the Display, then the one for the attached Screens (yes plural) and finally the ones for each registered X window (not only the toplevel ones you see).

There are several different painting and event routines you can hook into. Display allows you to recive events, Screen allows you to enter the rendering chain. This chain includes Prepare Screen Rendering, Doing the Screen Rendering and being Done with it. A window supports the PaintWindow method. To enter these chains there are WRAP and UNWRAP macros you can use. Normally you do WRAP in the Init methods and unwrap in the Fini methods. To call the base ‘class’ you temporarily UNWRAP call the function and WRAP it again. At least this is my explanation…

So to implement the cube you hook into the PrepareScreen method to update the animation numbers e.g. calculate the new coordinates. During the PaintScreen method you call the base implementation and then you can do whatever GL magic you want to. You have access to the used output device, can get the physical coordinates, CompScreen allows you to traverse over the active Windows and the good thing is, each Window has a CompTexture and as the screen was just painted all mapped Windows have valid ones. So you just have to ask compiz to bind the CompTexture and then make use of it. E.g. drop the cube example of the many online tutorials into the code path and you are already done.

The DonePaintScene Function is normally used to damage the screen and force repainting. This is used to keep the animation going.

What makes compiz hard to use is the lack of documentation, we gathered our information by looking at undocumented other plugins. E.g. the switcher to find the unhookWindowFromScreen method, I hope that this small introduction might motivate you to look into Compiz as well, or even helps you to write your own plugins.

A video will be created on monday and will be uploaded somewhere. Ah and this is my first OpenGL hack ever, I hope to be able to do more hacking using OpenGL ES and OpenVG in the future.

h.

PS: off to bed….

Hello OpenMoko

Hello OpenMoko

Hija Folks,
I know mickey from the Opie, OpenZaurus and OpenEmbedded project. I’m a Qt hacker, probably know Qtopia better than most of the devs working on it, am a proud member of the KDE e.V. and enjoy hacking stuff in C++. So how did I end up here doing Gtk+ and C? I hate closed systems as they really limit my freedom as identifying root causes (issues) and solving them is not possible and as a QA guy a closed system is just not an option if you are interested in quality. So with OpenMoko FIC grants us a possibility to create a usable, easy to use and well designed user interface people will love to use, it allows us to create a platform, base system in a proper and clean way which is likely to get copied by others. And yes I want people to copy and share as this will dramatically increase the quality of newly created linux platforms which will benefit us in the long run.

So let us free our communication (once again) and work on longterm goals to create a kick-ass product and platform.

sincerly yours
*build sheriff* *bitbake/OE hacker* *QA hacker* *app hacker* *ranter* *WebKit/OpenSync evangelist*

PS: I cross my fingers that this will land on planet.openmoko.org