Andreas
Qt
KDE
Labs
Graphics View
Posted by Andreas
 in Qt, KDE, Labs, Graphics View
 on Tuesday, October 30, 2007 @ 20:52

Feature freeze for 4.4 is closing in. The offices in the dev department are awfully quiet. A bit… too quiet. The snippety-snapping sound of brilliant minds tapping in code, merging changes, polishing APIs, writing tests, reviewing patches. An incredible atmosphere, you would have to just be there to sense it. This is the period of Qt development when most of the building blocks are assembled, and awesome features and improvements emerge like glowing fresh steel from the furnace. This is the most busy, the most stressful, and by far the most fascinating phase.

Today in particular, I almost felt emotional. Together with Jan-Arve, Jo, Bjørn Erik, Benjamin, Girish, all brilliant developers, and everyone else who has participated in the Widgets on Graphics View project, I had the sensation that things were fitting so well together that you’d almost think we hadn’t invented these APIs, but rather uncovered ancient APIs from a past civilization. ;-) The pieces of the Widgets on Graphics View project are coming together. In very few weeks, they will be in your hands to test.

Early on, I was worried about many things. Prior to 4.2, I was almost convinced that adding embedded widget support to Graphics View would be an insane operation. Undoable. I think I was right. I’ll just list some of the problems we foresaw then, here:

  • QWidget cannot render itself onto an arbitrary painter like QGraphicsItem can… :-((
  • QPen is cosmetic by default. Will all styled widgets look strange when transformed?
  • Will the styles’ implicit pixmap caching slow everything down to the state of it being useless?
  • How does scroll optimization (QWidget::scroll) work for a transformed widget?
  • Qt already has widgets, do we have to clone all the APIs into separate Graphics Widgets with a duplicated implementation?
  • How can graphics items be part of the tab focus chain when they aren’t based on QWidget? (QWidget::setTabOrder…)
  • Do we need support for window flags? How about window activation? When is a Graphics Window activated?
  • Is there a concept of top-level window decorations in Graphics View, similar to QMdiSubArea?
  • How can we fool a QWidget into embedding itself into QGraphicsScene without it interfering with other widgets as if it wasn’t embedded? (Think about QuitOnLastWindowClosed, and so on…)

Sigh. Looking back, I don’t quite understand how we’ve made it. After numerous discussions with the guys directly involved in the project, and Lars, Brad (thanks for those long discussions in the car!), Paul, Jasmin, and many many other trolls, we’ve found solutions to almost every single problem that we foresaw. And we even uncovered more problems. And solved those too. And what we got, what we have, and what we’re honing, stabilizing, testing and reviewing these days, makes me emotional.

#include "mainwindow.h"
#include <QtGui>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QGraphicsScene scene;
    scene.addWidget(new MainWindow); // embed the whole thing

    QGraphicsView view(&scene);
    view.show();

    return app.exec();
}

I can’t wait to merge our stuff into Qt/main. When we do, it’ll be in the Qt/main snapshots. And then, you can all have a go. Give it a try. Embed your entire QMainWindow based app, with a QMdiArea central widget that embeds a QGraphicsView inside a QMdiSubWindow, and see it fly. When you do, you’ll get emotional too. I swear.

Simon
KDE
WebKit
Posted by Simon
 in KDE, WebKit
 on Monday, October 29, 2007 @ 10:05

Politics aside I’d like to summarize a bit what happened during the development of the Qt port of WebKit in the last weeks. I like technical details, so I’ll concentrate on those :)

  • Lars has worked like crazy to implement support for editing in the layout tests. That means we pass now a whole lot of tests that verify that the on-the-fly editing of web pages works. You can use the contenteditable attribute on HTML elements and they are fully editable in QtWebKit now.
  • Holger has reworked the network job handling introducing priorities. Based on that he fixed support for synchronous downloads and ensured that during a synchronous download no async jobs are served. This is used for example for synchronous XMLHttpRequests.
  • We have started going through the public API again and making comments to things we want to change and fix, in the api-changes branch in our public Git repository
  • I’m reworking the context menu implementation and combining it with a nice API to retrieve QAction objects from a QWebPage. The state of these actions is maintained and you can plug them into toolbars, menus, etc. That will make it easier for developers to customize features like the context menu. Also it simplifies the KDE integration to apply KDE settings such as icons because it’s just one webPage->webAction(QWebPage::Reload)->setIcon(…); call and the action will have the right icon in the toolbar or the context menu.
  • We’ve finally set up a buildbot for the Qt/Windows build of WebKit. This will make sure that compilation always works.
mkalinow
Qt
Posted by mkalinow
 in Qt
 on Friday, October 26, 2007 @ 09:10

As most of you know Espen went back to Oslo a few months ago after he helped out setting up the Berlin office.

Since then, the Qt/WinCE project has been split up between Oslo and Berlin, which caused no problem at all due to modern communication ways like voice-over-ip, video-conferencing, Email, IRC and (place-your-favorite-protocol-here). But since one week the team has been reunited in Oslo.

 

The mission: Integrate our work back into the main development branch.

The result: Achieved on Thursday afternoon.

 

From now on we can follow up much easier the overall development process and catch up with all the neat features, which are supposed to come for the next release.

 

For those of you, who are curious about how the commit log looks like, take a short look here:

 

Change 281657 by espenr@espenr-radeberger on 2007/10/25 15:58:00

 

Fixes: complation error on Windows CE

 

Task: port Qt to Windows CE

 

AutoTest: probably borked ;)

 

Details:

 

One year in the making. Trying hard to brake the main branch. Works for us ;)

 

 

During the following weeks we are trying to get some of the features work, which has been made available for the other platforms already. I am currently investigating on how to get the Patternist done by Frans ported to Windows CE, while Thomas takes care of namespace issues.

So stay tuned for the next exciting news about Qt/WinCE.

 

Comments Off
englich
Qt
Aggregated
Patternist
Posted by englich
 in Qt, Aggregated, Patternist
 on Tuesday, October 23, 2007 @ 09:26

Attention to details is ok, but compiler messages has historically not received it. Here’s an example of GCC’s output:

qt/src/xml/query/expr/qcastingplatform.cpp: In member function 'bool CastingPlatform::prepareCasting():
qt/src/xml/query/expr/qcastas.cpp:117: instantiated from here
qt/src/xml/query/expr/qcastingplatform.cpp:85: error: no matching function for call to ‘locateCaster(int)’
qt/src/xml/query/expr/qcastingplatform.cpp:93: note: candidates are: locateCaster(const bool&)

Typically compiler messages have been subject to crude printf approaches and dignity has been left out: localization, translation, consistency in quoting style (for instance), adapting language to users (e.g, to not phrase things preferred by compiler engineers), good English, and just generally looking sensible.

To solve that it requires quite some work, and that’s probably the explanation to why it often is left out. To have line numbers, error codes, names of functions, and whatever available and flowing through the system requires quite some plumbing and room in the design.

Another thing is that nowadays we really should expect that compiler messages within IDEs or other graphical applications should be sanely typeset. If not, we’ve lost ourselves in all this UNIX stuff. Keywords and important phrases should be italic, emphasized, colorized depending on the GUI style.

For shuffling compiler messages around it is customary to pass a set of properties: a URI, line number, column number, a descriptive string, and possibly an error code. Apart from that it falls short reaching the goals outlined in this text, it encounters a problem which I think is illustrated in the above example with GCC. What does one do if the message involves several locations?

Even if a message involves several locations, it is still one message and should be treated so, and presented as so. The approach of using a struct with properties falls short here, and chops the message into as many parts as it has locations.

For Patternist I wanted to make an attempt at improving messages. So far it is an improvement at least. For instance, for this message that the command line tool patternist outputs:

cli.png

the installed QAbstractMessageHandler was passed a QSourceLocation and a message which read:

<p>Operator <span class='XQuery-keyword'>+</span> is not available between atomic values of type <span class='XQuery-type'>xs:integer</span> and <span class='XQuery-type'>xs:string</span>.</p>

It was subsequently converted to local encoding and formatted with ECMA-48 color codes. (The format is not spec’d yet, it will probably be XHTML with specified class ids.)

While using markup for the message is a big improvement, it opens the door for formatting and all, this API still has the problem of dealing with multiple locations.

What is the solution to that?

Striking the balance between programmatic interpretation(such that for instance source document navigation is doable) and that the message reads naturally as one coherent unit is to… maybe duplicate the information, but each time tailored for a particular consumer?

<p xmlns:l="http://example.com/">In my <l:location href="myDocument.xml" line="57" column="3">myQuery.xq at line 57, column 3</l:location>, function <span class="XQuery-keyword">fn:doc()</span> failed with code <span class="XQuery-keyword">XPTY0004</span>: the file <l:location href="myDocument.xml" line="93" column="9">myDocument.xml failed to parse at line 93, column 9</l:location>: unexpected token <span class="XQuery-keyword">&</span>.</p>

This is complicated by that language strings cannot be concatenated together since that prevents translation. But I think the above paragraph is possible to implement. As above, the message reads coherently, but still allows programmatic extraction. A language string and formatted data sits in opposite corners of extremity, and maybe markup is the balance between them.

Would this give good compiler messages and allow slick IDE integration? If not, what would?

espenr
Uncategorized
Posted by espenr
 in Uncategorized
 on Friday, October 19, 2007 @ 12:46

So the second and final installment of DevDays2007, namely DevDays 2007 II: Münich - Revenge of the Ratskeller is over. We all had a great time, and it was packed with over 500 attendees which made all of TT very happy. Here you see some of them during a lunch break:

Lunch break during DevDays 2007 in Münich

I’m happy with all my talks (Release management, Undo/Redo and Qt/WinCE) and would like to thank you all for listening and asking questions and providing suggestions. I’ll write it all down here and let the rest of the guys in dev know about what you had to say.

As promised, I said OpenGL support was just around the corner, and as you can see from Thomas Hs blog, we already have a video of it running! Great job there.

I would like to congratulate the winners of the Nerds vs Geek competition, and I have to say I really envy the 3rd place runner for his prize. It was a USB tape-dispenser. I mean, how cool is that!

After two days of presentations and workshops, we went out to party. Only the trolls. Which is a good thing, because any impression you had of us as professional and sensible people would surely be destroyed after 10 minutes of drinking with us. I’ll just give some kewords:

  • Break-dancing
  • Beer-coaster throwing
  • Table-lifting
  • Stripping-on-table-while-table-being-lifted-almost-falling-while-giggling
  • Schnaps-shots
  • Headache
  • Missing-the-bus

For the record, most of those keywords do not necessarily describe my behavior that night.

I’ll have you know though, that being a presenter is very fun and I’d do it again. But, and here is the but. At the end of the week, you’re gonna look like this:

Thierry, Morten and Andreas looking sharp

eskil
Qt
KDE
Qt Jambi
Posted by eskil
 in Qt, KDE, Qt Jambi
 on Thursday, October 18, 2007 @ 16:12

For a while now, I’ve been spending my non-bug-fixing time on the Qt Jambi AWT Bridge, an integration layer which will make it possible for you to place your favorite AWT and Swing component hierarchies inside your Qt windows and the other way around. This should hopefully prove to be at least a very convenient tool for anyone who wishes to port their Swing applications to Qt Jambi (which is something I, with the best of intentions, encourage people to do on a regular basis.) It should also allow you to use any of the GUI components out there which were written to be used together with AWT or Swing.

The Qt Jambi AWT Bridge began its life in a hotel bar in San Francisco during JavaOne 2007, almost like a game of chicken. Gunnar started writing the QComponentHost, I started writing the QWidgetHost, and at least for my part the primary goal of this was to see if he’d give up before I did. It was fun and the code was an awful mess, which is a side effect of fun.

Hey, here’s proof of how much fun we had and also an example of QWidgetHost in use (I’ve used this screenshot before, but it’s so much more relevant this time):
Proof of funcept
(click for big)

Then, at some point, Gunnar must have decided it was a good idea to formalize it, because it suddenly showed up as a scheduled task in my task manager. I started working on it, and then product management started asking me on a regular basis whether it was done, which means it had become serious business, and, more importantly, that Gunnar chickened out before me.

So, long story short, I just made some finishing touches on the focus handling today, and I decided it was time to let people try it out, so that we can catch the bugs early. This means, of course, that it’s a far from a perfect solution at the moment, but it works pretty well for the examples I have, and I’d like feedback to know where to proceed. See the project page for a list of known issues.

Technically, it’s not very complicated. The current incarnation consists of a few lines of OS specific code which reparents a native window handle, thus placing it inside another native window without the toolkit’s interference. This takes care of showing the widgets in the right place on screen, and the OS takes care of most of the other stuff, like delivering the correct events to the correct event queue. The most challenging thing was to connect the Qt and AWT focus subsystems, because, quite frankly, the latter is a complete and utter mystery to me, and I don’t know if I’ll ever fully understand that immense and intricate collection of concepts and awesome method names which are synonyms. I sincerely hope I have something which works now, though, but I anticipate getting a lot of bug reports for this particular part, so if you want to help out, please try navigating through your application with the keyboard and see if the tab order makes any sense at all. If it doesn’t, let me know, and please send me a compilable example if you can.

Questions and feedback can be addressed to our Qt Jambi Interest mailing list and the project page is right here. Have fun with it and let us know how it went.

(PS. Samuel came up with the title of this post, and it sums everything up perfectly so I stole it.)

Comments Off
Thomas Hartmann
Qt
News
Painting
Posted by Thomas Hartmann
 in Qt, News, Painting
 on Tuesday, October 16, 2007 @ 13:46

Since we just released the Qt/WinCE Technology Preview and it has been quite some time since our last Qt/WinCE blog, I think it is time for another chapter on how our brave Qt framework is discovering the land of Windows CE.

Those of you who downloaded Qt/WinCE and tested the technology preview might know that Qt/WinCE supports all Qt modules except Qt3Support and OpenGL.

Actually right now I am working on support for OpenGL ES for Qt/WinCE.

OpenGL ES is a specialized version of OpenGL for embedded devices. But it is still powerful enough for some really impressive demos and examples if you look at the SDK by PowerVR.

This is a small demo showing off OpenGL on the Dell Axim. For such a small device the OpenGL rendering is pretty fast I think. In this demo we already use QGLWidget for general rendering and QGLPainter for text rendering and the bubbles. So if everything works as planned our next Qt/WinCE release may contain support for OpenGL (ES).

In the meantime we are integrating Qt 4.4 into our Qt/WinCE branch.

Scribble screenshot

Finally a few days ago I realized that our scribble example is really cool on a handheld, because it allows you to draw directly with a pen on the screen. To bad I have no real artistic talent.

I hope you guys will have as much fun developing cool and useful applications for Windows CE devices as we have porting the awesome Qt to Windows CE.

Thomas Zander
KDE
Posted by Thomas Zander
 in KDE
 on Tuesday, October 16, 2007 @ 11:54

I think Jesper has one answer to that here. He forgot to mention it was a Saturday night, though!

And, yes, I’ll happily link to your on-topic blog. When there is a photo I’m in, looking reasonably cute, that helps ;)

Thiago Macieira
Qt
KDE
Posted by Thiago Macieira
 in Qt, KDE
 on Monday, October 15, 2007 @ 11:20

For a while now we’ve been plagued with a side-effect of the module separation in Qt 4: some of the goodies are “downstream” from the module we’re developing code on. This is the case for XML: it’s been in its own module (QtXml) and we have been left with no good XML parsing class in QtCore and QtGui.

As XML seems to be in use everywhere now, we felt that we needed to fix the issue: the light-weight QXmlStreamReader and QXmlStreamWriter classes that Matthias added to Qt 4.3 have been moved “upstream” from QtXml to QtCore. The DOM- and SAX-style classes will remain in QtXml since they have specific uses, while Patternist will probably get a module of its own.

The changes will be available in tonight’s snapshot.

This opens up the way for more moves, if we feel that some functionality is needed. We had been afraid of doing that before because of binary compatibility issues: that is, how do our supported platforms handle the symbols being moved from one library to another? To find that out, I wrote a tester program along with four libraries (DLLs) and ran it in each of our platforms. The results were encouraging:

  • all platforms allow the symbols to appear in QtCore
  • 3 platforms required the symbols to be in both libraries (QtXml as well as QtCore): Windows, MacOS X and AIX
  • all platforms link new programs without errors (apparently AIX generates warnings)

Interestingly, the platforms that allowed pure symbol moving (as opposed to duplicating) are using ELF as the format for their executables. This shows the power of this format, which is unfortunately also one of its major drawbacks: the symbol import table doesn’t say which library the symbol should come from, so the dynamic linker has to search all loaded libraries. MacOS X uses its own format called Mach-O, AIX uses XCOFF and Windows uses a modified version of COFF called Portable Executable.

PS: we have not tested community-supported platforms. If you have access to one such platform, we’re interested in knowing if this latest change affects you in any way.

Benjamin Meyer
Qt
Posted by Benjamin Meyer
 in Qt
 on Monday, October 15, 2007 @ 08:39

Traditionally when you wanted to map a file into memory on Unix this was done using mmap and on Windows with CreateFileMapping. Continuing the tradition of simple, consistent API’s, in 4.4 QFile will have two new functions: map() and unmap() that provide the ability to map files into memory.

An quick example:

QFile file("foo");
file.open(QFile::ReadOnly);
uchar *memory = file.map(0, file.size());
if (memory) {
// have some fun with the data
file.unmap();
}

You can check out more in the
map and unmap documentation.