ettrich
Qt
Posted by ettrich
 in Qt
 on Wednesday, February 28, 2007 @ 16:54

Snapshot users have seen them already: with QXmlStreamReader and QXmlStreamWriter, Qt 4.3 will feature two new classes for reading and writing XML.

QXmlStreamReader is a faster and more convenient replacement for Qt’s own SAX parser, and in some cases also for applications that would previously use a DOM tree.

The basic concept of a stream reader is to report an XML document as a stream of tokens, similar to SAX. The main difference between QXmlStreamReader and SAX is how these XML tokens are reported. With SAX, the application must provide handlers that receive so-called XML events from the parser at the parser’s convenience. With QXmlStreamReader, the application code itself drives the loop and pulls tokens from the reader one after another as it needs them. This is done by calling readNext(), which makes the reader read from the input stream until it has completed a new token, and then returns its tokenType(). A set of convenient functions like isStartElement() or text() then allows to examine this token, and to obtain information about what has been read. The big advantage of the pulling approach is the possibility to build recursive decent parsers, meaning you can split your XML parsing code easily into different methods or classes. This makes it easy to keep track of the application’s own state when parsing XML.

The streaming concept is not new, it’s what other APIs use as well, e.g. Java’s StAX or libxml’s TextReader approach. In fact, it’s pretty much the straight-forward and intuitive approach to reading tokens. The weird thing was SAX and honestly I can’t remember what had driven us to implement SAX in Qt in the first place, other than lack of time to design something better. We had it on the list for a long time, now we finally got around doing it.

The streambookmarks example in the Qt snapshots shows how to use both classes. Here’s the typical main loop:

 QXmlStreamReader xml;
  ...
  while (!xml.atEnd()) {
        xml.readNext();
        ... // do processing
  }
  if (xml.error()) {
        ... // do error handling
  }

The parser is well-formed and also supports incremental parsing. And it’s a lot faster than Qt’s SAX and DOM implementations. If things work out well, we might base the SAX parser in future Qt versions on QXmlStreamReader, which would make our SAX implementation both faster and more compliant. But even then, QXmlStreamReader is the fastest and most convenient way to read XML data in Qt.

lars
Qt
KDE
Posted by lars
 in Qt, KDE
 on Wednesday, February 28, 2007 @ 15:26

As Zack already mentioned in his blog, we had George Staikos visiting us in our Oslo office last week. He, Andreas and myself sat down to hack on some rather big API additions to our networking module.

Some of these changes have been visible in the snapshots for a few days now, as the work I have done to add support for transparent HTTP proxies to Qt (up to now only Socks5 was supported). A new QAuthenticator class has been added, handling the most common authentication methods used with proxies and HTTP servers (Basic, Digest-Md5 and NTLM). In addition all our networking classes got signals to tell you when a server (or a proxy) requires authentication. Today I’ve also updated the http example in Qt adding one UI file and around 10 lines of code showing how to show an authentication dialog to the user if the web server requires it.

A side product of doing Digest-Md5 and NTLM authentication for Qt was a neat little class called QCryptographicHash, that can calculate Md4 (I know you shouldn’t use that, but NTLM requires it…), Md5 and Sha1 sums for you. The class is now part of QtCore.

The other big API addition that mainly Andreas (with help from George) has been working on is to add SSL support to QtNetwork. He submitted it to Qt about an hour ago, and you’ll be able to see the code and play around with it in tonight’s snapshots. We’ve done a few rounds on reviewing the API so we hope that the API is rather stable and includes most of the features required for doing SSL. The QSslSocket implementation is mostly done, but certificate and key handling still has quite a few rough edges in the implementation, which we’ll try iron out within the next week or two.

Anyone who’s ever tried to use the API of OpenSSL directly knows how hard it is. Opposed to that, we’ve tried hard to make it as simple as possible to use QSslSocket without compromising on security. In the end we came up with a design that should be trivial to use for anyone who ever used any of the Qt socket classes before. The whole design consists of 5 classes: QSslSocket, QSslCertificate, QSslCyper, QSslError and QSslKey.

QSslSocket derives from QTcpSocket and all you have in addition is a few methods to to the following:

  • key and certificate handling
  • start the server or client SSL handshake
  • one signal reporting errors
  • a slot to tell QSslSocket not to abort the connection after the error
  • some signals and properties for status reporting
  • and a convenience method to connect to a host and immediately enter SSL mode

We hope that the other classes are mostly self explanatory, but we hope to have enough time until 4.3 comes out to write a few nice examples.

For now, you can find a small example using QSslSocket here. It basically connects to an arbitrary server and port and will give a telnet alike command line after connecting to the server. Andreas states that the UI is ugly, so you better use the app with your eyes closed ;-)

Andreas
Qt
Labs
Graphics View
Graphics Items
Posted by Andreas
 in Qt, Labs, Graphics View, Graphics Items
 on Tuesday, February 27, 2007 @ 19:12

We’re in the process of closing up the features for 4.3, and I’ve had a little run-down of what’s changed in Graphics View.

In general, you will notice that the graphics run faster, (especially for complex polygons,) collisions are absolutely precise, the rubberband looks 100x better… I think most of our Graphics View followers will be very pleased with the upcoming Qt 4.3.

When the first beta is released, it’s nice if you as a Graphics View developer try out your Qt 4.2 app with 4.3, so that we can nail out any possible regressions (both behavior and speed) before the final version is out. So please, let us know :-).

Here are some of the new features:

  • QGraphicsView has some new properties.
    • viewportUpdateMode: Now you can fine-tune how the viewport reacts the changes in the scene.
    • rubberBandSelectionMode: For those who want to select items that are inside but don’t intersect with the rubberband…
    • optimizationFlags: If you want faster graphics, away goes the safety net… ;-)
  • All flicker in rubberband mode is gone.
  • You can also transform the view with a QTransform; this works best for small scenes, though. But the effect of seeing your scene with perspective transformations is pretty cool.
  • QGraphicsItem has some new flags.
    • ItemClipsToShape: All item rendering is clipped to its own shape
    • ItemClipsChildrenToShape: Like widgets, the parent item clips all its descendents.
    • ItemIgnoresTransformations: The lovable item that just won’t transform… well.

There’s been some under-the-hood changes too. Where before, if you moved an item, it would always get continuously reindexed (for each mouse move event), now it goes into an intermediate state that keeps the item outside the index until you leave it for a while. When moving a lot of items together, this makes a huge difference. It also means you don’t have to use NoIndex for scenes that combine animated and static items! It’ll still be pretty fast.

Check out the chip demo, or run the Colliding Mice example in one window, and top/Task Manager in the other; it’s faster in Qt 4.3 snapshots!

[no carrier] - /me waits for the first comment going “Hey, it’s not fast at all!” ;-)

eskil
Qt Jambi
Posted by eskil
 in Qt Jambi
 on Tuesday, February 27, 2007 @ 12:58

One of the most annoying things about developing Qt Jambi has so far been the Java Virtual Machine’s tendency to intercept exceptions in the native code, thus disabling any mechanism installed in the OS serving to handle these. Instead of your application crashing violently, it outputs a message to the console apologizing intently that such an awful thing would ever occur, and it also dumps a helpful .log file to the disk, containing stack traces and environment details that can be helpful in debugging the problem.

The problem is, however, that Windows users of tools such as Visual Studio are used to having a debugger registered with the operating system, so that, in cases where an application crashes, they can simply hit the “Debug” button in the default dialog that pops up, attach to the process, and jump directly into the source code at the exact location where the problem occurred. There are no limits to how useful this mechanism is, and I suspect it literally saves me hours of work every week.

When writing JNI-based applications that run on top of the virtual machine, however, this is simply not supported. Apparently, Sun made an attempt to fix this themselves, but there were some problems in the integration process [edit: The URL seems to have gone dead. Here’s a cached version.]

Having complained about the problem for much too long, I finally had some extra time last week, and decided to fix the problem myself. I set out to patch the JVM. My goals were: 1. Keep the current logging facility. 2. Get back the default exception handler. 3. Do as little work as possible.

Since you’re supposed to have screen shots in these blog-things, here’s how it looks when it’s done:

Yeeh!

Patching and building the JVM is suprisingly simple. The code is well-organized, and the build system is as good as fool proof. So kudos to the developers for that :-)

My patch is by no means elegant. In fact, it’s downright stupid. I also make no guarantee that it won’t break earth or anything. However, I thought there might be other people out there who would like to do this, so here it is in case you’re interested:

--- src\share\vm\utilities\vmError.cpp-backup   2007-02-16 15:39:41.760875000 +0100
+++ src\share\vm\utilities\vmError.cpp  2007-02-16 16:01:57.104625000 +0100
@@ -664,10 +664,11 @@
     } else {
       if (recursive_error_count++ > 30) {
         out.print_raw_cr("[Too many errors, abort]");
-        os::die();
+        //os::die();
+        return ;
       }
 
-      jio_snprintf(buffer, sizeof(buffer),
+      /*jio_snprintf(buffer, sizeof(buffer),
                    "[error occurred during error reporting, step %d, id 0x%x]",
                    first_error ? first_error->_current_step : -1,
                    _id);
@@ -679,7 +680,7 @@
         out.cr();
         out.print_raw_cr(buffer);
         out.cr();
-      }
+      }*/
     }
   }
 
@@ -791,11 +792,11 @@
   static bool skip_os_abort = false;
   if (!skip_os_abort) {
     skip_os_abort = true;
-    os::abort();
+    //os::abort();
   }
 
   // if os::abort() doesn't abort, try os::die();
-  os::die();
+  //os::die();
 }
Comments Off
harald
Qt
Qtopia
Posted by harald
 in Qt, Qtopia
 on Monday, February 26, 2007 @ 14:35

Since dynamic_cast doesn’t reliably work between library boundaries, Qt introduced qobject_cast to safely cast between QObject subclasses. There’s just one requirement - the class you want to cast to must contain a Q_OBJECT macro. Without the macro, qobject_cast would fail at runtime, which makes it tedious to debug.

Qt 4.3 now includes a compile check that makes sure the Q_OBJECT macro is present when casting objects. If you get a compile error in a function called qYouForgotTheQ_OBJECT_Macro, just add the Q_OBJECT macro to the class and lean back knowing that you just saved yourself some debugging time.

Comments Off
zack
WebKit
Aggregated
Posted by zack
 in WebKit, Aggregated
 on Sunday, February 25, 2007 @ 21:29

This week I beat WebKit Qt’s rendering into shape. I rewrote the theming and canvas code.
It works so nicely that I’m actually pretty happy with it. The rewrite helped me fix issues with statically positioned elements (which just didn’t work on a scrollview/canvas combination I did before). Due to which my blog finally looks and behaves correctly as seen on the screenshot above. That plus scrolling is about 10x faster and you never see gray areas on scrolling as you did before.
This week George Staikos has been here in Oslo to work with us on the networking code. George and I have been friends for five or six years and he has this nasty habit that forces me to start an intervention and try to get him off it. What I’m referring to is the fact that George has been Canadian for, well his entire life, and it is my professional opinion (but I’m not a doctor) that he needs to move on. I’m not sure in which culture it is customary to bring Snapple ice-tea to your friends when you come to see them but we need to change him to that because he definitely didn’t bring me any this time and that’s just rude.
Going back to work, I’m sure Lars will blog about the networking magic they did so I’ll keep my mouth shut. Once the code they were working on will be ready (which should happen within next week or two) and we’ll start using in WebKit, we’ll make the transition and start using WebKit Qt based browser on a daily basis. So we’re close which is pretty exciting.

We have also started optimization run for Qt 4.3. My grand plan is to make sure Qt 4.3 is 2x faster in general rendering code than Qt 4.2 was. I have a list of algorithms to shave and rewrite over the next few weeks which will be rather challenging.
By the way of performance some people noticed that Qt OpenGL in recent snapshots with Antialiasing turned on is actually slower than it was in Qt 4.2. It’s because of an experiment that we’re trying on. We’re now using GLSL to antialias primitives. Of course it’s a lot slower than the old code but produces very high quality results. I don’t really like it though because the performance hit is just too big.

Morten
Labs
Threads
Qt Concurrent
Posted by Morten
 in Labs, Threads, Qt Concurrent
 on Friday, February 23, 2007 @ 10:57

As a part of Trolltech Labs, I’m adding the Qt Concurrent project. Qt Concurrent is a high-level threading framework for writing code that automatically scales on multi-core systems.

For example, to make thumbnails of a list of images you can do this:

QImage scaled(const QImage &image)
{
    return image.scaled(QSize(100, 100));
}

...

const QList<QImage> images = ...
const QList<QImage> thumbnails = QtConcurrent::mapped(images, scaled);

QtConcurrent::mapped() runs scaled() on each image in the list, using as many threads as there are CPU cores on the system.

In addition to this Qt Concurrent also provides a MapReduce implementation for shared-memory systems and support for making asynchronous function calls using futures.

You can get the source code at the labs pages, and there is also a forum for questions and general feedback.

lorn
Qt
KDE
Posted by lorn
 in Qt, KDE
 on Sunday, February 18, 2007 @ 00:19

Linus fires latest shot in GNOME Wars

“the reason I find GNOME limiting is BECAUSE IT IS.” - Linus Torvalds.

’nuff said…

lorn
Qt
Qtopia
KDE
Posted by lorn
 in Qt, Qtopia, KDE
 on Saturday, February 17, 2007 @ 17:54

QVFb is the “emulator” that Qtopia gets developed in. The power in this, is that it constrains your “screen” to specific display sizes, gives you control over what bit depths your display uses, and simulates buttons presses, through the use of a skin. This helps produce applications that are dynamically resizing, look good and actually work correctly in screens sizes as small as 176×220.

We don’t need X!
Of course, you don’t need to use X to display Qtopia apps. If your device or desktop machine has a framebuffer device, you can display it there (if you are using X, try Ctl-Alt F2 and Ctl-Alt F7 to get back!). You can constrain the display size using QWS_SIZE. Of course, if you use this method, you will need to configure with -no-qvfb.

Developing apps in a virtual framebuffer is no more difficult to use that any X program. In fact, it’s beneficial for developing properly behaving embedded applications for Phones and Pda’s. Not to mention being able to get ’screen movies’ easily.

Comments Off
lorn
Qt
Qtopia
KDE
Posted by lorn
 in Qt, Qtopia, KDE
 on Thursday, February 15, 2007 @ 08:17

I have been the Qtopia Community Liaison since I started working here in Brisbane, Australia at Trolltech. It has been three great years in this position. A great many things has happened since then. I found an awesome Australian wife (I am from the US), had a son (17.5 months old now) (and another bub in the oven!) who likes singing, dancing, climbing, swimming and (literally) drools over any handheld device I might have, also likes to bang on the keyboard(s) (computer and musical) and play with the scroll wheel on the mouse, and especially loves it when he can bang on my laptop.. so, he is a lot like me.

Many things have happened in the handheld world… pda’s melted into smartphones, big companies such as Motorola and Nokia have released handheld devices that run Linux, Opie has had developers come and go (Trolltech has even hired a few developers who have worked on Opie in the past).

Linux looks like it is entering a new phase on handhelds, and growing more mainstream all the time. hooray!

In the past, at Trolltech, I was on a 4 year temporary business sponsored visa, and could not switch jobs even if I had to. But since my personal life has become more permanent here, I thought it only right to seek a more permanent visa. So now I am a permanent resident here, which allows me to change jobs, and do other things such as live in sunny, warm Queensland a bit longer.

So, I have switched from being a “difficult to explain exactly what I do” Community Manager, to Software Engineer in the hardware group here in Trolltech south. I will still be acting as community liaison (but less and less so) and will remain actively involved in the linux developer community, perhaps even becoming involved more with KDE development, who knows! I get to help develop the Greenphone and friends even more than I have been. Which, by the way, is actually currently available, for you to hack on!