Qt, GLWidgets, and the Hardware!

Hi guys!
Its been some time now, since my previous post. And a LOT has happened since!

Two of the most important events have been the release of Qt 4.6 and obtaining the Hardware platforms we will be using for further development.

One of the big questions has been the performance of Qt applications on a mobile device. This is something we obviously haven't tested yet, as the operating system package for flashing is only being compiled as I write, but I am hopeful that if our HW vendor can get its driver act together, we'll have a beautiful and smooth UI in the making here.

A month ago I, as the project's architect, went through a slightly stressy phase related to the graphics. You see, there are really two ways of doing the graphics: OpenGL+Qt drawing within a GLWidget, or by using the OpenGL graphics system for the entire Qt drawing. The GLWidget route has been the plan from the beginning, but some team members expressed their grave concern over the smoothness of graphics (they have since changed their minds, and accepted the architecture allows for great graphics), but in any case, I had to go thought the options.

What I did, then, was go through the options...

Using GLWidget has a strange feature, or maybe it should be called a bug: transparency does not work from GLWidget to GLWidget. The workaround is to implement draw and interaction event passing yourself, and draw into the same (top level widget's) QPainter. This allows for fast graphics, but not really the kind of programming experience that you would like.

Getting back to the team on this, we decided to stick with Qt's opengl rendering via "-graphicssystem opengl". This seemed like a great idea, especially since Qt 4.6 became final that same day!

The tension mounts, as we wait for good HW drivers for the hardware. This pretty much makes or brakes the whole system, as far as graphics are concerned.

Dialer UI & First Actual Phone Calls

Hello again guys!
Winter is slowly setting in, with the first sporadic snowflakes falling as I write this.
Telephony now works! We have the entire software stack ready to use, and with the dialer UI I have now seen for myself.

The architecture allows for very simple usage of system routines, for example:
1) Dialer UI has SLOT "Dial", Which is Called When the User Clicks on "Call"

void Dialer::Dial( QString aNumber )
{
gsmService->dial( aNumber );
}


2) The "dial"-Function Sends a Message via TCP/IP to the Service Process in Question
This is where the service-specific stuff lives - the "service adaptation" layer. For each service there is an actual service process, and a client service class, such as "GsmService", that the client application can use. Simple, no?

3) The Service Process uses the System's Actual Service
In many cases this involves doing platform-specific things, such as using a service via D-Bus, as is the case in GsmService. If we want to port the system onto another platform, such as Symbian OS, we only have to rewrite this part

4) Yes, it can be this simple :-P

Anyhoo, I can now make phone calls directly from the "Dialer UI", using ofonod running on the system and a phone attached via USB. Very encouraging! Hopefully I'll be able to post pictures of this later on...

October... UI design, UI development, Hardware RFQs, Trying to tie widgets to services spanning TCP/IP, D-Bus and BEYOND!

Ok, ok, lets turn down the dramatics here. But the truth remains that this project currently feels like a point-and-click adventure game.

As most of my architectural drawings have already been finished, I've had time to work on some GUI implementation issues... such as the dialer UI. The dialer UI goes into the GUI framework, which in turn goes into the app system via TCP/IP. This way the application can use services provided by the "Central", without worrying too much about the underlying "core" implementation.

Currently, due to an epic.. err... chain of events, I have to wait some hours before I can use the dialer system from my beautiful dialer UI.

'nuff said, stay tuned for some swashbuckling UI-imagery later on... this year.

Qt tests

UI design is banging away at their molten iron, and we are busy trying to keep up with them :-) Ideas are being tossed both ways, and the final (G)UI is on its way!

I can't reveal any secrets, even about my own ideas, at this point, but stay tuned.

Mikael Laine's Qt drawing test:


Timo Holopainen's Qt/OpenGL motion blur effects:

Back from the holidays

Ok, the last part of my summer holidays is now over, and its back to work for me. This week has been full of meetings, most notably our UI-design people!

Currently we don't have the UI-design yet, but we will have a draft ready in about a week! Right now, the project has been split into two teams/projects: the so-called "core" team, and the "gui" team, of which the graphical designers are a part.

The CORE team is (obviously) very much involved in implementing the below architecture, with its low-level services and other doodads...

The GUI team, on the other hand, is brainstorming the design and figuring out how to actually draw the Qt-widgets etc. using HW acceleration and different effects.

All kinds of demos, protos and other neat graphical stuff abounds, I'll try to post something concrete later on - stay tuned :-)

Desktop widgets

After some holidays, a move to moblin, and some days at work:


The above image says it all... well, maybe not quite :-)

The architecture is coming along little detail by little detail. Here is one more.

Previously we've had the "Central", which is responsible for launching other apps, and the other apps themselves are pretty much normal qt-apps.

So what I've done now, is I've added the possibility for apps to have a "widget presence" on the "Central's" desktop (the weather icon in this case). This allows for at-a-glance information to be sent to the main view by all applications.

Some kind of priorization/permission system needs yet to be conceived, but as it is, its looking quite nice! I guess the user could be in charge of desktop widgets...

Long time no post. We had a frantic sprint planning session last week, and the result was that we ended up dumping PokyLinux and moved to moblin!

Voila! There it is. We're five days into our first sprint (the first sprint is much shorter than normally, for several reasons), and we've pretty much met all our requirements already. "Hello World!" has been touted loud and clear on many a qemu-screen, and all is advancing well!

The above figure illustrates the current architecture draft. In many ways the system needs to be reconsidered, but essentially the architecture is final.

One interesting feature of the architecture (not shown on the screen) is an application lifecycle model, which is built into the base class of all apps on the platform. This should make work easier for the developer.

1st Sprint And the Spirits are High!

Hello World!
Those are precisely the words our new mobile linux platform should be able to say after this first sprint. Its not that we haven't done that before, but its just that a new project with new requirements and a whole new bunch of people needs a starting point.

A little history: we had a project back in 2007 that created a mobile Linux platform with several applications (DVD-H tv app, email, SMS, browser, dialer/GSM, etc.) but somehow the results just evaporated into the air. A lot of good work was done, but it was not really leveraged. We are now set to change that!

After 6 months, we're going to have a mind-blowing GUI with all the services running that a mobile phone can need. All this will be done on top of a highly portable and modular UI/services platform that will catch the attention of the world.

My name is Mikael Laine, and I'm the chief architect of this secrect project. I'll be letting you in on how everything advances, with screenshots and links to various projects we use and/or modify to our needs.