Earlier this month, we released the single, largest release of Qt since the 4.0.0 release two years ago. Qt 4.4.0 is the result of 10 months of hard work by the Trolls, including numerous distractions. And while it’s being digested by our clients and users, we’re working on Qt 4.4.1, which will include fixes for bugs that were already known at the time of the 4.4.0 release, as well as some that people have reported.

In the meantime, we take two steps back, to the 4.3.x series, and then one step forward: we’re releasing today Qt version 4.3.5. This release is meant for those who cannot upgrade to Qt 4.4.0 yet, but need fixes for some important issues. All of the changes done for 4.3.5 will be present in 4.4.1 and some are even part of 4.4.0 already.

This is the first time ever we’re doing a public release of the previous minor series. In the past, we’ve always stopped development of the previous minor series when the next one came out. Sure, we’ve done security fixes when needed and Trolltech Support continued to support clients using them, but we’ve never made a public release. So this is news for us too.

One of the main reasons that made us decide to release 4.3.5 was the sheer size of the 4.4.0 upgrade. Many customers are scared to take the leap. Not that 4.4.0 is a bad release — no, far from it, all indications so far are that it is a great release. (At least, the Trolltech head of Support hasn’t tried to kill me yet for it!) But nonetheless, we decided we would reassert our commitment to all clients and users despite all distractions, by providing them with one more 4.3 release.

If this proves to be a good thing, we may repeat it for the 4.4.x branch when Qt 4.5.0 is released, although we’re not expecting anything as groundbreaking for that release as 4.4.0 was. We also have two or three bugfixes up our sleeves in the 4.3 branch, which may lead to a 4.3.6 release if necessary.

Including the pictures of the Qt developer team again, since a few more people have been patched in.

Oslo team	Berlin team

Its been a while since I introduced ‘Vng’. Vng is still under production and innovation is happening

As a quick intro can be read here, which will tell you that vng is a version control system made to be usable by humans.

So, what has happened since my last blog. Well, I’ve been polishing a lot. This means that I have added various options to the major commands. Like adding all files in a dir recursively to the repository. Which you really miss if you need it.
Another thing I added was a matcher. The most obvious place where this is visible is in watching past changes. The changes command will naturally list things like commit-message, author etc. Using the various matchers it becomes trivial to do some more intelligent interrogation of your repository.
vng changes --match zander #show all the records which ‘zander’ made.
vng changes --last 10 #show 10 records
vng changes --from-match 'fix assert' #Find the record with ‘fix assert’ in the message and start showing changes from there.
vng changes --to-patch 'Add.*Command' # show only changes until one that matches the regular expression.
Naturally you can combine all those without problems.

Most of these things you probable just have to try out to see how it works for you. I’m someone that really cares about the tiny details so you’ll find things like showing when you changed whitespace at the end of the line with a colored marker, or being able to type ‘vng what’ instead of the full command ‘vng whatsnew’ since, well, vng knows you must have meant the full one, naturally.

Back to the “what happened” point. I always get a bit excited when I have a tool that is just smart in visualization etc. But I actually started writing this blog for a reason;
The main complaint I have heard from people trying git on the Qt repository (specifically on Windows) is that its slow. Now, we know that git has some scalability problems on Windows, and the git people are working on that. But in my interviews with various perforce users that actually made the above claim I noticed a very different problem.
The way that perforce works is that your checkout has all files checked out as read-only. Whenever you want to edit a file you have to tell perforce. Which tells the server you are editing this file.
The effect of this is that doing a ‘p4 diff’ will first ask the server which files you have opened and then do a compare of only those files with your local copy. This is substantially different from git or darcs or many others which all use the file-date to check if you have edited a file. Using a filedate has the big disadvantage that for a repository the size of Qt (or KDE) you have to stat 30000 files if you ask your app to give you a diff. This is disk-access and thus slow.

So, no matter how much the file-access is optimized and duplicate statting is reduced, the concept of making the user keep track of which files to diff will always be faster then letting the tool auto-detect this.

This conclusion then lead me to investigate in what manner it would be practical to re-use this concept for the people that now have very good reason to complain about slowness. I mean; instantaneous diff, or waiting 30 seconds on cold caches to do a diff of Qt…
I have used my creative-Friday today to work on this in vng and have for the most part finished the implementation. I have added ‘vng edit’ and ‘vng opened’. Edit will ask the user if he wants to switch to the way of working that he has to mark files for editing. After which any whatsnew / record etc will only happen on the files that are being edited. The biggest change, naturally, is the speedup. The results will be on screen instantaneously since we already know which files are changed and we avoid any file listing or statting.
Next step is to make the perforce integration that virtually all tools have work for vng. This integration is in most editors, in diff and various other tools already. They will detect a file that is read-only and will call p4 edit on the file prior to writing out your changes. If we can fool those tools into doing the same but then call vng edit instead we get a huge speedup virtually for free.

Are you interrested in trying out vng; see vng.googlecode.com or just download the sources from repo.or.cz/w/vng.git. Note that the speedups are not in the downloadable executable posted on the projectpage. I’ll have to rebuild that one soon.

Have a good weekend!

That’s the moment we’ve all been waiting for… or dreading. We’ve worked for long months getting it done and you’ve all been asking for it. Some of you even realised it has already been available for a few days, unannounced… And now it’s finally, at last, there!

Qt 4.4.0 is released

Last week, we had a sneak release to current customers. And now it’s on the Trolltech homepage for the world to see. To make your life easier, here’s a download button:

We’re quite proud of this release. It’s the most feature-packed release of Qt ever and certainly the largest release since Qt 4.0.0 itself. This release adds:

• The Windows CE platform
• The Phonon new module: multimedia integration
• The QtWebKit new module: web integration
• The QtXmlPatterns new module: powerful XML support
• The QtHelp new module: flexible help support
• The QtConcurrent framework: parallel programming
• A new network resource access stack
• Support for regular widgets on Graphics View
• Support for non-native windows
• Support for shared memory
• Support for inter-process semaphores
• Support for painting on auxiliary threads
• Support for atomic operations on integers and pointers
• Improved printing support
• A new Qt Assistant
• And much more, since I will never be able to remember everything we’ve done

Not happy with all of that, we’re also bringing you:

• A video showing our demos
• A downloadable version of the pre-built demos (Windows only)
• White papers on embedded development, web support, XML, user interface styling

Continuing with the tradition started with the past minor release, we bring you those who did the work:

Oslo team	Berlin team

Trivia: there’s someone on both pictures. Can you spot who?

Hello,

Some of you might know the generic geographical map widget Marble that is part of KDE 4.
As already stated in Torsten Rahns’s Blog I started porting Marble to Windows CE.
Since Marble is a pure Qt application and does not rely on OpenGL the port is pretty straightforward.
The main problems were memory constrains, because Windows CE 5 only supports 32MB virtual memory. And of course speed is another issue. I had to reduce the complexity of the vector data set, because there is no tiling implemented, yet, and all the vector data has to fit into memory. The bump map is also significantly smaller than in the desktop version.

And now Marble runs on Windows CE as you can clearly see:

Marble on Windows Mobile 6.0 (America)

The Marble port proves that Qt really allows to port fairly complex application easily from the desktop to embedded devices. In this case the new Windows CE platform. It is also a good test case for stability of Qt for Windows CE.

Marble on Windows Mobile 6.0 (North Pole)

Marble on Windows Mobile 6.0 (Afrika)

Marble running on a ViewSonic Windows CE 5.0 tablet, also powered by an ARM cpu.

Marble in full action on a Dell Axim

Another video of Marble running on a Dell Axim.

Marble running on a Fujitsu Siemens Futro A220 (x86)

The Futro has a 400Mhz x86 processor, which is the reason that Marble runs really fast even on a high resolution.

nice weekend.

It been almost two years now, that Trolltech decided to open a Berlin office in Adlershof.
When we started (I include myself as Karsten and I were the first freshly hired guys),
there was a lot of build-it-up spirit. You can find early Trolltech Labs entries by Espen showing you how it all started.

Since then the staffing grew and grew, Berlin started to grew up its culture, while still feeling connected to Oslo.
We have made it up to 17 people by now, which is an insane increase rate compared to most other companies in Europe or even worldwide.

But after latest happenings this has changed. I guess most of you heard already some rumors, that things weren’t working out very well for us.
Less and less space for us to grow. More and more pressure on us to get along with the situation. Endless discussions between developers, managers (you know these guys that seem to know best about developers), developers with managers and managers with developers.

In the end it has been decided by management (once again these strange people), that the office will have to close and that it is time for the Trolls to move on…

Read the rest of this entry »

Programming in groups requires you to use a source revision system. Its a fact; not doing it would be like crossing the north pole in your sunday clothes, it won’t be very successful. This shows; as long as people have collaborated in writing software, there have been systems to support this. I count 32 such systems on wikipedia .
Up until 2001 or so I used cvs exclusively. It did the job, more or less without loosing too much work. I started looking into distributed source revision systems, which looked a really cool idea that may give each individual programmer a lot more control over how he works, and how he can collaborate with his peers.
I went through TLA, got frustrated by the complexity, searched on and found Darcs. Fell in love quite quickly. Great idea, even better user interface. Unfortunately written in a language I never had the patience to go out an learn (haskell). Perfect romance setting, gives me what I need and I can never hope to fully understand it

Darcs was started initially with the idea that a distributed system doesn’t have to be more complex to use, just different from a centralized system. I have been part of the development of Darcs to the extend of working on user interface issues, writing clear language in the UI and other simple things like that.
Darcs has its share of technical problem, though. It doesn’t scale up well. Its basically unusable for bigger projects.

Flash back to the present. It feels like git is going to be the winner in this battle of programmer mindshare; on a technical level it certainly is the best there is. It scales up without effort and it is incredibly fast. Here at Trolltech various people are already using it every day. There is ongoing research to make it the default system in KDE as well.
Git, in my eyes, is the absolute opposite from Darcs, where one is bad the other rocks and vice versa. Git is technically superior; its basically the next generation in its field. Its got more features then you can wave a stick at, and its got mindshare and active development. The bad is that its reinvented the user interface, the in-line documentation is weak. The choice of command names arcane and inconsistent. Discoverability of features is basically a hit-and-miss.
Darcs, on the other hand, has not been strong technically but it has been developing a user interface (command line) over the last 4 years that is coherent+consistent, easy to learn, has lots of textual feedback while still being very feature rich.

Now, what to do! I like parts of both, but using either gives me headaces. The sum of the parts is a negative number in this case

So, like any good hacker, I started a new project to marry the two components. My project, which I call ‘VNG’ uses a normal git repository and expects git to be installed but using ‘vng’ you will find an interface designed much more coherently. Darcs users will feel right at home.
The project is very much in alpha right now; what is there works, but you’ll be using git for more advanced things. (and some not so advanced things).
I did find it time to make a nice announcement and call for developers that want to help out work on vng.

A short tutorial to get you started;

  $ mkdir ~/myproject
  $ cd ~/myproject
  $ vng init

You now have a Vng repository! Let’s do something with it:

    $ touch myfile
    $ vng add *
    $ vng  record -am "Initial import."
    Finished recording patch `Initial import.'

A simple ‘vng’ will give you the help output, which I’ll just paste here as a good overview what I already have;

Usage: vng COMMAND ...

vng version 0.22 (>2008-03-28)
Commands:
  help          Display help for vng or a single commands.
Changing and querying the working copy:
  add           Add one or more new files or directories.
  revert        Revert to the recorded version (safe the first time only).
  unrevert      Undo the last revert (may fail if changes after the revert).
  whatsnew      Display unrecorded changes in the working copy.
Copying changes between the working copy and the repository:
  record        Save changes in the working copy to the repository as a patch.
  unrecord      Remove recorded patches without changing the working copy.
Copying patches between repositories with working copy update:
  push          Copy and apply patches from this repository to another one.
Administrating repositories:
  initialize    Initialize a new source tree as a vng repository.

Want to help or try vng? The sources are on; http://repo.or.cz/w/vng.git
Either send me patches or upload them to the ‘mob’ branch (which requires no password) on repo.

Looking forward to your flames!

You may have remembered that in the past I’ve talked about some of the development of 64-bit applications on Mac OS X. The gist of it is that Apple changed their position on supporting 64-bit Carbon, the library we depend on for running Qt GUI applications. It became obvious early on that Apple wasn’t going to change their position on this, so it left us with two choices:

1. Keep Qt Carbon-only and forego 64-bit support.
2. Create a port of Qt that used Cocoa as its backend.

Naturally, since we already support 64-bit on the other platforms and since the idea of using Qt is to help insulate you from changes such as this, we decided on the latter option. It did mean that we had a bit of work ahead of us, since we had to re-write some of the internals of Qt (particularly widgets and events), but most of the other modules were already there.

I’m happy to say after a bit of work, we’ve made progress and we’re proud to offer an alpha for curious people that want to try 64-bit applications on Mac OS X 10.5. It is based off a fairly recent snapshot of 4.4.0, so it will have all the bugs and features of 4.4. There still is a lot that doesn’t work and there’s a way to go (hence the term “alpha”). On the other hand, having more people try it out will help us find bugs and will make it much better (there’s only so much we can test locally).

Here are the links for the
open source package and the commercial package.

The official press release is here (along with an ouroboros link back to this blog post).

The place to offer feedback is on the qt4-preview-feedback mailing list. Please consider putting something about Cocoa in the subject so that it gets to the right people.

By default, the package is built in 32-bit (in case you happen to not have a 64-bit machine). To build in 64-bit pass -arch ppc64 or -arch x86_64 (if you want to build 64-bit universal, pass both). I would also recommend passing -prefix $PWD so that it is not necessary to run make install. I’m not sure make install works in this package.

Since we aren’t putting up the documentation for the alpha up (it’s pretty much the same docs as 4.4), I’m reproducing the known issues for this package here:

This document explains the current list of features in the Qt/Mac Cocoa port that are currently not working. Most of the issues will be addressed in upcoming snapshots and beta releases. We hope that all the issues should be addressed by the time the of the final 4.5.0 release.

• What Works
• Current Known Issues
• Things We Don’t Expect to Support

What Works

Here are the things that we can say about the current state of the Qt/Mac Cocoa port.

• 64-bit Support: The Qt libraries currently do build and link as 64-bit frameworks and it is possible to build and run many of the Qt examples as 64-bit.
• HIViews are now NSViews: Every QWidget is now backed by an NSView pointer instead of an HIViewRef. QWidget::winId() will return an NSView pointer that can be used in other Cocoa technologies (e.g., Core Animation).
• Some Native Dialogs Work: QFileDialog and QColorDialog have been ported to use NSOpen-/NSSavePanel and NSColorPanel respectively. QPrintDialog and QPageSetupDialog are not in this release, but are on their way. Currently, none of these dialogs show up as sheets pending the creation of an asynchronous API.
• Painting, Printing, and Styles: Since printing and painting used Quartz 2D and styling used HITheme, these sub-systems work without any changes.
• OpenGL: OpenGL is fully supported,including pixel buffers and framebuffer objects.
• Clipboard: Using QClipboard to copy and paste data works as expected.
• Mouse, Keyboard, and Wheel events: Mouse, keyboard, and wheel events are dispatched to the proper widget. The Qt/Mac Cocoa port respects Cocoa’s idea of a "First Responder."

Current Known Issues

The following are items that don’t currently work, but that we plan to have resolved before the final release of the Qt/Mac Cocoa port. Please do not file bugs on these.

• Carbon Support: The current source tree for the Qt/Mac Cocoa port contains source for building Qt/Mac with Cocoa. It contains some of the source code that is used for the Carbon port, but it is currently not set up to build the Carbon Qt/Mac libraries. Please use a normal release or snapshot if you want to use Carbon.
• Drag and Drop Support: Drag and Drop is currently not implemented and needs to be ported to Cocoa, but using the clipboard does work at this time.
• Accessibility: Accessibility support is not implemented and needs to be ported to Cocoa.
• Text: Most text rendering works fine for Latin-1 characters. However, rendering non-Latin-1 characters has not been tested.
• Input Methods: Input methods also need to be ported to Cocoa.
• Shortcuts: Shortcuts that exist outside of the menu bar may not be dispatched.
• Tablet Support: The tablet support has not been ported from Carbon yet. However, it should still be possible to use the tablet as a mouse.
• Phonon: Phonon uses the QuickTime backend that is only available on 32-bit. Using Phonon in 64-bit requires a QTKit-based backend and has not been done.
• Unified Toolbar: The QMainWindow::setUnifiedTitleAndToolBarOnMac() method currently does nothing.
• Dialogs, Tool Windows, Sheets, and Drawers: At the moment, all windows are subclasses of NSWindow. This means that window types like drawers and sheets do not work and tool windows do not get the right decorations. Modal dialogs do show up at the correct window level, but are not yet considered "panels." Many window flags are not recognized.

Things We Don’t Expect to Support

The following items that we do not plan on spending any resources on unless there is monumental outcry for their inclusion.

• Qt3Support: At this time we have no plans for making the Qt3Support module work with the Qt/Mac Cocoa port in 64-bit mode. Following in footsteps of Apple, we would like to encourage you to consider the time of going Cocoa and 64-bit as a chance to jettison Qt 3 constructs and classes.
• Support for versions of Mac OS X below 10.5: We are using methods and classes that are only available in 10.5 and higher. Most of these functions don’t have any equivalent on earlier versions. We recommend using the Carbon version for earlier versions of Mac OS X. We anticipate keeping the Carbon port supported at least for the lifetime of 4.5.
• Support for -no-framework or -static: Cocoa requires that we load a nib in order to properly access the global menu bar. This nib has to reside on disk somewhere. The most logical place for it to reside is inside the QtGui framework. For this reason, building Qt as standard "dylibs" or statically is no longer supported.

Its been some time since my last blog; I’ve been quite busy and didn’t have a whole lot of time for KDE/KOffice and other fun things. I have been following Norwegian courses in the evenings and the little spare time I had left went to doing non-computer things. (Snowboarding is even more fun if its just an hour travel)
I’m slowly getting back to having time again for fun computer things, and I’ve been working out some ideas, among others a human-friendly front-end (not graphical for now) to Git.

One question I’ve had from several people was where they could actually find this Kids-Office stuff I blogged about a little while ago.
The thing is; KOffice2 is very modular and you can take away the default dialogs and dock-widgets and enable alternatives on a per-user basis.
In practice this means that if you have run any alpha version of KOffice you would have already had the kids-office components on your computer, just not on screen.
So, here the 3 step list of how to turn your KWord into a kids-friendly-KWord;
1) Start KWord from a KOffice2-alpha release (or current svn).
2) Go to the Settings menu, submenu ‘Dockers’ and disable all dockers.
3) In the same menu; enable the “Format” docker.

I am fully aware this is not really user-friendly and could do with some usability features. I’d love to have a kids-kword icon that started KWord with the above configuration. But, yeah, there are a lot of things I’d love to see

I have not been the only one that has been off the web for some time; and I was very happy to get back in touch with Evangelia Berdou. She graduated late 2007 with, which to me is some successstory of how FOSS affects real lives. Some may recall that she conducted research a few years ago on certain aspects of KDE, including a survey of KDE e.V. members. Her thesis, which is titled: ‘Managing the bazaar: Commercialization and peripheral participation in mature, community-led F/OS projects’ is now available online. The thesis used GNOME and KDE as the primary case studies.
You can download a copy  either from the MIT F/OS paper repository (PDF) or from her website . The latter provides some more details on the overall context of the research. The chapter that presents the analysis of the data from the survey of the KDE e.V. members is Chapter 6.
I mostly read the paper some time ago, and I already realized how fast KDE moves, the research uses a lot of data that after the KDE4 cleanups are not really accurate anymore. I have the suspician that the core argumetns are not really affected by that, though. I understand she is really interested in hearing what the community thinks of her research.

I promise more coherent rambling for a next blog

As you might have seen, Nokia has announced to acquire Trolltech. An open letter to the open-source community can be found here.

This is exciting news for everyone. As you can see in the letter, our commitment to the community will not be affected by this. Qt development will continue in the same way as we’ve always done it.

If you read Planet KDE or the news at all, you must be already aware that KDE 4.0.0 has been released. It’s all people are blogging about, so I think I should give my contribution to the crowd and congratulate everyone who has participated. Trolltech also sends its regards with this press release.

KDE 4 is the product of hundreds or thousands of contributors: developers, artists, technical writers, usability experts, beta testers, promotion people and, why not, users too. All of those who downloaded and ran one of the alphas, betas or RC and came to one of our IRC channels contributed to making it possible. It’s the result of two and a half years of work on top of KDE 3.5 — adding to the 9 years of KDE 1.x, 2.x and 3.x work.

I was a developer already when KDE 3.0 came out, but I was away from KDE at the time, tending to other businesses. Besides, the KDE 4.0 release is more closely related to the 2.0 release, when I was still playing around with KDE code. And when our codebase was much, much smaller.

Really… there’s no comparison to the KDE 4.0 release. Do you realise how many applications have just been released? How many lines of code that is? (Coverity says it’s 4.7 million, but it’s including apps not released today — by the way, we have one of the lowest defect/LOC ratio and by far the lowest in the >1 million line-of-code range).

We at Trolltech are very pleased to see it happening, not only because many of us are KDE developers too (about 15, I guess). KDE is the largest and most visible product (or, should I say, “suite of products”) made with Qt, which means we get a lot of feedback from KDE developers. The development of KDE version 4 has been no exception with thousands of suggestions sent to us. What’s more, Phonon and WebKit, major new features for the next version of Qt, are innovations that originate from the KDE Project.

Our developers on the Unix/X11 platform are all using KDE (with a few exceptions). Some have already migrated to KDE 4, others will follow soon, as soon as Linux distributions start providing packages. This is great for us, because we can readily see the effects of our changes in the KDE applications. With KDE 4 also going even more cross-platform, onto Windows and Mac, all our developers will be able to play this game.

We are also a bit afraid now… Can you imagine the flood of reports we’ll get? The rest of the KDE 3 applications will be ported soon, generating queries, suggestions and bug reports to our support engineers and development team.

I’m sure it’ll be fun. I’m glad I’m here to witness this happening and to be part of the dream coming true.

Congratulations everyone!

PS: the #kde4-devel IRC channel is now gone. Long live #kde-devel!