Just for the fun of it I wrote a 132 LOC python script that takes the output of a perforce client and produces input for git-fast-import. I just wanted to see how git would perform on a big repository like Qt’s. Git is a decentralized revision control system (check out the Wikipedia page for more information). I have to say I quite like the results

I decided to import //depot/qt/main/…, which is the entire mainline of Qt, excluding branches but of course including all changes in the branches integrated into the mainline (which basically all). That’s about 94000 changes. The import took around 3 hours and resulted in a total of 736774 git objects.

The really cool thing is that git compressed this entire lot of data, 13 years of history, down to 500 Megabytes! Just to put this into relation: An entire checkout of the Qt mainline right now takes up 330 Mb.

This might turn out to be useful when working off-line during traveling, without a fast network connection. I can surely spare the 500MB on my harddisk, and I get the /entire/ Qt history with it. Needless to say that commits and other operations remain instantly fast.

Yes, you too can write an application for the Greenphone without actually owning one! (and join the qtcentre.org developer contest)

It’s easy! How?

Grab the Greenphone SDK. Once you have it running:
source devel-x86.sh
This sets up the compiler environment for natively compiling, which you do to initially develop you application.

You can run your test in the QVFb (Qt Virtual Framebuffer). This is not an emulator, and only simulates the button presses through the use of the Greenphone skin. Other than that, it has nothing really to do with the Greenphone hardware at all.

After you have it running nice and well there, you can then:
make clean
source devel-greenphone.sh
qtopiamake
make
make package

Whew, finally!

Users of Qt/MinGW have been restricted to compiling and using Qt with the Windows shell cmd.exe. Compilation of Qt would fail even with the presence of the MSYS shell sh.exe in the PATH. This caveat, has over the years, resulted in very many user complaints including this, this, this, this, this and not to mention lots of support requests.

The problem is that the MinGW make mingw32-make starts spawning processes through sh.exe instead of cmd.exe when a sh.exe is found in the PATH. sh.exe, of course, does not understand Windows shell built-in commands and expects the unix path separator / causing compilation to fail.

For 4.3, we have enhanced qmake to detect sh.exe in the PATH and write out a makefile that mingw32-make/sh.exe likes. This means that you can now compile Qt and your programs using the shell of your choice. Other advantages include usage of built-in sh commands and autoconf scripts. It also turns out compilation using sh is way faster than using cmd.exe.

On a more technical note, the new QMAKE_SH variable provides the path to sh.exe (even if you are using MSVC) and MINGW_IN_SHELL is set to “1″ if you are using MinGW inside a shell. If you switch shells, all you need to do is to rerun qmake.

A few of you may have seen my prior posts about
GPL vs. LGPL

ya just gotta love it when people go on about how the LGPL is “more free” than GPL, and then almost in the same sentence, ballyhoo proprietary software and how it’s bad that some distributions offer it in their repositories.

If you look at the big picture, the real problem with the LGPL is the consequences of it. It naturally leads to more non-free proprietary software. The LGPL is not about free software. It’s about non free software, otherwise they’d use GPL.

I’ve been working on a lot of things at once over the last week but I just remembered that I never mentioned something that I should have. In the beginning of the Qt 4.3 development phase I added a class called QSvgGenerator to QtSvg. QSvgGenerator is a paint device, meaning you can open QPainter on it and yes, that’s right, you’ll get an SVG XML stream back that you can save to a file or manipulate.

So now you can redirect your widget/window and have a snapshot of your application dumped to SVG format… Come on that’s pretty cool. The generator still needs a lot of work, especially when it comes to complex text. But here’s a weird, example. I made Qt render a simple animating bezier curve, then loaded html with Qt documentation and rendered that with opacity of .75 (which is why it looks very blend) and finally redirected to a painter opened on a QSvgGenerator. As a result I get a SVG (viewed, of course with, svgviewer) looking like this:

And the full output is here. So yeah, the concept of being able to load simple html and then save it as SVG is pretty neat.

Also boolean ops on paths are now in Qt. You’ll find them in QPainterPath’s. Since I already had the code and Andreas asked me for it, I added QPainterPath::intersects(const QPainterPath &other) and QPainterPath::contains(const QPainterPath &other) that can be used to check whether two paths intersect or whether one path fully contains the other. I still want to do some heavy optimisations on it, but I’d like to implement “Snap Rounding of Bezier Curves” instead of trying to find the right shortcuts to use reduced-predicates for the intersection finding algorithm.

If you want to see IAccessible2 based accessibility via D-Bus on your desktop, you can download the
ia2-demo and start playing with it. Note that this is still work in progress, but feel free to send me your comments.

Creating a decent animation, albeit a lot of fun, is quite complex. Besides being able to create the content (and therefore exhibiting basic artistic skills) one has to go through the mundane process of trying to figure out what exactly should be on every frame.

SVG, as a format, is absolutely atrocious at expressing animations. KDE 4 is moving more towards dynamic metaphors, where animations will be used to convey a lot more information. Now the question is how do we let people who inherently have no artistic skills create animations that look and behave correctly. While “look correctly” is pretty simply defined as: it’s visually appealing. Then “behave correctly” has a more complex definition that will depend on many factors. We’ll define a “well behaved animation” as one which simply doesn’t irritate or inhibit the work flow of the users.

While the latter is mostly a challenge for usability engineers I’d like to help people create animations - quickly, with minimal amount of artistic skills and no mundane tasks. So ideally I’d like to be able to say “this is what I’m starting with” and “this is what I’d like to end up with” and see computer animate this process. The technique is known under “shape interpolation”, “shape blending”, “image morphing” and many other names. There was a lot of research done on this topic but so far no one used this technique to do real-time animations on desktop.

The most popular research papers related to this problem include “As-Rigid-As-Possible Shape Interpolation”, “A physically based approach to 2-D shape blending” and finally “As-Rigid-As-Possible Shape Manipulation”. If you haven’t seen it, you definitely want to look at the last one, there’s a short movie on that site showcasing some of the things one can do utilising their algorithm. Some of the examples from the above research follows:

I think that shape interpolation together with as-rigid-as-possible shape manipulation done on QPainterPath’s, or whole SVG’s in fact, could potentially be the answer to our animation woes. The pain, once again, is that people always work on polygons in those papers so I’d need to spend a bit of time to figure out how to mix it in with paths and inject curves into the algorithm.

Oh, and yesterday was the “World Hug Day” so if you haven’t hugged anyone yet, go right ahead.

One of the many benefits Qtopia has from using such an awesome base library as Qt is dynamic layouts.

What this means for Qtopia is that any application written, and Qtopia itself, is automatically configured for any screen size. The same binary run on 176×240 will most likely have 100% functionality if run on 640×480, or even 1600×1280. It makes no difference to Qtopia or your application what screen size is used. You can even set QWS_SIZE to a smaller resolution if you want to test your app in smaller resolution. QVFb can also be configured and run to show various screen sizes, so you can see for yourself.
Of course, you have to consider, if using very small screen resolutions, just exactly what you want on the screen. As putting thousands of widgets on a screen of 176×240 wont exactly look good.

In Qtopia 4.2, we now have support for setting the screen DPI:
QWS_DISPLAY=LinuxFb:mmWidth35:mmHeight55:0

Last summer, while we were finishing up 4.2, there was a great deal of activity on the mailing lists we set up for the 4.2 technical preview (http://lists.trolltech.com/). Some people kept on asking for support for “untransformable” items, that is, special QGraphicsItem items that don’t follow the parent’s or view’s transformations. Like the text labels in Google Earth, they stay horizontal when you rotate, and don’t change their size when you zoom.

Because of the risk of destabilizing the base behavior, we decided to postpone such a feature, and it was moved into research.

Good news, it looks like we will be adding this feature to 4.3. It’s still in research, but working quite well. There are some minor details to iron out, but mostly under the hood and they will not affect the API or behavior in any way.

Click to see a short animation.

To trigger this special behavior, you set a flag: ItemIgnoresViewTransformations (, or something like that). Then you can add the item as a regular child of another item. Its position will then show where the item is “anchored” to its parent. And the item is rendered without any rotation or scaling imposed by the view. For example:

QLinearGradient gradient(-100, -100, 0, 100);
gradient.setColorAt(0, QColor(128, 255, 192));
gradient.setColorAt(1, QColor(63, 255, 63));

// Create a scene, add the main ellipse.
QGraphicsScene scene;
QGraphicsEllipseItem *ellipse
= scene.addEllipse(QRectF(-100, -100, 200, 200),
QPen(Qt::black, 2), gradient);

// Add two child lines that cross over the ellipse.
QGraphicsLineItem *line1 = new QGraphicsLineItem(-100, 0, 100, 0, ellipse);
line1->setPen(QPen(Qt::black, 3));
QGraphicsLineItem *line2 = new QGraphicsLineItem(0, -100, 0, 100, ellipse);
line2->setPen(QPen(Qt::black, 3));

// Add five _untransformable_ text items around the ellipse.
for (int i = 0; i setParentItem(ellipse);
text->setFlag(QGraphicsItem::ItemIgnoresViewTransformations);
text->setPos(100 * cos((6.28 * i) / 5.0), 100 * sin((6.28 * i) / 5.0));

QFont font;
font.setPixelSize(20);
text->setFont(font);
}

The items still follow regular items’ rendering constraints (e.g., the stacking order is the same as with normal items). You can also rotate or scale the item itself; that still works. It just doesn’t inherit any transformations.

PS: The Hell Wyrm has been defeated! It took me a good 1.5 hrs of continuous struggle to nail this mark. Can you believe that it’s got 6 million HP??

In (more or less) 5 easy steps.

1. Download, burn to cd, install and run the Greenphone SDK.
Greenphone SDK ISO
2. Open KDevelop
3. Project->New Project->C++->Embedded->Qtopia 4 Application
4. Open konsole and run these commands in your projects directory:
$source devel-x86.sh
$qtopiamake
5. Edit code and compile.

If you want to use the newer version of Open Source Qtopia,

6. (inside the sdk) Download Qtopia Open Source edition 4.2.0
Qtopia 4.2.0 OpenSource
7. Unpack to /devel
$cd /devel
$tar -xvpzf qtopia-opensource-src-4.2.0.tar.gz
8. ./configure
9. make
10. make install