If you’ve looked through the Qt Jambi API, you’ll see that we don’t
make use of the Java 5 feature of enumerators for mapping Qt/C++
enums. Since we’re already using generics, auto-boxing and other Java 5
features it probably seems a bit strange that we don’t use enums for
mapping enums in Qt.

The reason in short was: “We didn’t see a way how we could…”

Why? Enums in Qt are used in a number of different ways. Some of them
are bit flags that are passed to a QFlags< ...>, some are a list of
special number and some are extensible id’s such as QEvent::Type, where
we provide x number of default events and then users can define their
own if they specify the event type to be higher than
QEvent::User. Java enums on the other hand are _only_ enumerators, a
list of named values from 0 to number_of_entries.

We could easily solve the numbered enums used as bitmasks and special
numbers, even a generics based QFlags which made typesafe flags. The
problem of QEvent::Type and the extensible enum was a different
issue. Java does not allow the programmer to create enums outside the
enum declaration. However… After some hours of testing and
prototyping we came up with a means to do this, of course while still
preserving the use of the == operator and the possibility to use enums
in switch statements.

So from Tech Preview 3 of Qt Jambi you’ll start seeing support for real
enums and real QFlags. To give you some idea, here’s how it will look:

// Checking for enum values:
switch (event.type()) {
case MouseButtonPress: ...
case MouseButtonRelease: ...
case MouseMove: ...
}

// Custom event:
QEvent.Type myEventType = QEvent.Type.resolve(QEvent.Type.User.value() + 1);

// Creating, setting and unsetting bits in a QFlags
QPainter.RenderHints hints = new QPainter.RenderHints();
hints.set(QPainter.RenderHint.Antialiasing);
hints.set(QPainter.RenderHint.SmoothPixmapTransform);
painter.setRenderHints(hints);
hints.unset(QPainter.RenderHint.SmoothPixmapTransform);
graphicsView.setRenderHints(hints);

That was a small update from the Java team, now its back to working
with the JavaDoc support…

A really neat feature that Arthur in Qt4 was lacking was support for perspective transformations. QMatrix is an affine transformation class. Even though our docs advertise it as a 3×3 matrix it’s actually 2×3. I’ve been wanting to do perspective transformations in Qt for a while. With Qt 4.2 frozen I had a chance to sit down and work in the main branch for the last two days. As a result I have a very basic support for perspective transformations in Qt. I added a QTransform class which is a true 3×3 matrix and gutted most of Qt where I replaced QMatrix with QTransform. Now it’s possible to do projections of any kind of Qt element. That includes images like Konqy here:



but also all other Qt elements, like here a button with a label and icon:

All of which allows one to create a really nice looking 3D like looking effects in all Qt apps.

During this summer of pre-4.2 testing, we got many feature requests from you all, customers and Open Source’rs, and I’d like to pull out one of the things we decided to implement as a result of this. Item obscurity: being able to determine whether an item is obscured, or not.

The idea is that any item can report which parts of its drawable area are completely opaque, and also whether their own bounding rect is obscured by another item. It’s pretty neat! And here’s how to do it. First, reimplement QGraphicsItem::opaqueArea():

  QPainterPath OpaqueEllipseItem::opaqueArea() const
  {
      // returns the opaque area in local coordinates. in this
      // case, the entire ellipse item is opaque.
      return shape();
  }

Now, if you’ve got some item that’s very expensive to draw, you can check a simple precondition from inside paint():

  void ComplexItem::paint(QPainter *painter, ..., QWidget *)
  {
      if (isObscured())
          return;
      ...
  }

QGraphicsItem::isObscured() checks to see if your item’s bounding rect is completely covered by any item on top of it.

Sweet?

For the moment, QGraphicsView itself doesn’t use this feature by default, but this certainly opens possibilities for us. For example, partial obscurity would be really cool (being able to determine if /parts/ of your item are obscured), and we could also use the opaque area to determine the item’s exposed areas. Hohoho.

I really need to get into the habit of this blog thing. Anyway, I needed a small break from what I was doing before I head up to the cafeteriafor lunch.

I somehow managed to volunteer for giving 3 presentations during Trolltech Developer Days 2006. I’m mostly done with the multi-threading presentation; I just have to add some code examples. Once I’m done with the Qt in depth presentation, I’ll add a little “bonus” material to the multi-threading presentation (so that I have something to talk about if we get some extra time). The hardest one to write is going to be the application development on Linux for Windows developers presentation. I’ve been using xemacs for so long, that I’ll have to teach myself how to use some of the other editors.

So, I’ve got lots to do, but I’m really looking forward to DevDays this year. I didn’t go last year, which I regret. Guess that’s why I over-compenstated this year

Finally! The Greenphone Qtopia 4 developer SDK pricing is
announced and for sale.

Now the fun begins!

Some people think QFile in Qt 4 is slow[*]. Compared to Qt 3, the noticable difference lies in QIODevice::getChar(), and to some extent, QIODevice::putChar(). But there’s good news: With Qt 4.2, we’ve managed to improve QIODevice’s performance by 4-5x when reading small blocks at a time, especially so for getChar() :-).

So something has changed with QIODevice in the upcoming Qt 4.2, and for those of you who write QIODevice subclasses, this write-up could be worth reading.

For existing subclasses of QIODevice in Qt, such as QBuffer, QFile, QTcpSocket, and QProcess, you won’t notice any difference (other than the speed-up). Reading character by character is now mostly on par with Qt 3. The cost of this optimization is a change in behavior for custom device authors.

We’ve upgraded the unget-buffer in QIODevice to a general purpose buffer. When in 4.0 and 4.1, a getChar() or readLine() call used to access QIODevice::readData() directly, these calls can now read blocks from an internal buffer instead. The speed-up is very noticable; especially so for QFile, which forwards readData() calls to its file engine, rendering the compiler helpless with regards to optimizations.

The behavioral change only affects custom QIODevice subclasses that didn’t handle unget before. Because unget is a fairly rare operation, though, you could easily get away with this in 4.0 and 4.1. Let’s take an example. You may find the following construct familiar:

bool SpeedDevice::atEnd()
{
    return index == data.size();
}

An unget operation on such a device breaks atEnd(), because there’s a character in QIODevice’s unget buffer that SpeedDevice doesn’t know of:

if (speedDevice.atEnd())
{
    speedDevice.ungetChar('a');
    if (speedDevice.atEnd()) { /* still true */ }
}

To avoid the problem with atEnd() falling out of sync, you would improve the first call by calling the base implementation:

bool SpeedDevice::atEnd()
{
    return index == data.size() && QIODevice::atEnd();
}

There, now it works fine. If you did this consistently in 4.1, you won’t have any problem with 4.2. With the first implementation, however, your subclass will stop working; in this example, atEnd() is likely to return false negatives.

The following functions are affected by QIODevice’s buffer:

    QIODevice::atEnd()
    QIODevice::bytesAvailable()
    QIODevice::size()
    QIODevice::canReadLine()

And the fix is: call the base implementation after checking your own conditions. It’s the only way to keep QIODevice’s buffer in on the deal.

Here’s a couple of special ones:

    QIODevice::pos()
    QIODevice::seek()

You shouldn’t have to reimplement QIODevice::pos() ever - if you do, it should end up calling QIODevice::pos()’s base implementation. QIODevice maintains your device’s position for you. Your device is always in sync as long as you reimplement QIODevice::seek(). And recall that you should also call QIODevice::seek()’s base implementation after syncing your own device.

QIODevice itself guarantees that when readData() or writeData() are called, your device will be in sync (so you don’t ever have to call seek() inside those virtual functions).

So there you have it! These changes will also be described in the 4.2 change log.

:bibr

PS: IO devices opened in QIODevice::Unbuffered mode are unaffected by the changes to QIODevice in 4.2.

PPS: This change renders my trick from QQ17 (TCP Traffic Control) unusable; instead, the rate-controlled socket has to proxy an internal QTcpSocket instance. The examples/network/torrent example in Qt 4.2 will demonstrate what changes were necessary.

[*]: Our usual response is: Either you can read large blocks at a time, or you can use QTextStream - both are very fast.

Trolltech is inviting free software and open source developers to the
annual Developer Day Conference[1]. One of the talks in the San Jose,
CA venue is by Dr. Bjarne Stroustrup, designer and original
implementer of C++. There will be talks ranging from 3D Graphics
Development with Qt and OpenGL to demonstrations of the Qtopia
Greenphone. There will be over 30 interesting presentations. Please
take a look at the whole program:

http://www.trolltech.com/devdays2006

Trolltech is offering free attendance to the annual Developer Day
Conference for active open source developers. It’s open to any
software developer who is currently contributing on an free software
project.

How to attend:

Send an e-mail to opensource@trolltech.com. Use “DevDays” in the
subject.

Include:

- your name

- the active project you are working on. A URL to the project would
be great too.

- whether you’d like to attend Munich, Germany (October 11 & 12) or
San Jose, CA (October 26 & 27)

Some logistics:

Attend 1 day or 2 days at either location. Each location will also
have an open source birds-of-a-feather gathering hosted by Knut
Yrvin, Trolltech’s Community Manager.

This offer is limited to conference attendance and does not include
hotel accommodations, airfare or other related expenses.

More information on Trolltech’s Developer Day conference can be found
at:

www.trolltech.com/devdays2006

I have been in Australia for 3 years. My parents are visiting for a few weeks. and wouldn’t you know it… the day before we had planned to visit Beerwah (Australia Zoo), Steve Irwin dies. Needless to say, the Zoo won’t be open, and it wouldn’t be a good place to be anyway, after yesterdays events.

I know a lot of aussies think of him as annoying, but they probably don’t realize how many lives he touched, and how much attention he brought to Australia wildlife and animal conservation in general.

…