The second annual Trolltech Developer Days took place last month in San Jose, USA and on last week in Munich, Germany. They featured keynotes and presentations from Eirik Chambe-Eng, Trolltech's co-founder and President; Matthias Ettrich, founder of KDE and Trolltech's Vice President Software Development; Aaron Seigo, KDE Core Contributor and many others. Read on for a summary of some of the keynotes and presentations given in Munich.

Eirik Chambe-Eng

The first keynote by Eirik Chambe-Eng, Trolltech's co-founder and president, gave an overview of the company's current situation and future plans:

Trolltech continues to grow at an impressive rate, they increased their staff from 80 to 140 employees in the last twelve months. A second round of fundraising, which brought $6.7 million of disposable money to the company, was recently completed. Trolltech has opened an office in China. And of course the long awaited Qt 4 was released. In the coming twelve months Trolltech will become a professional service organisation. They will develop new products that complement and expand the usage of Qt. A continued focus on making Qt easier to use, faster, leaner and better will be kept and it is expected that Qtopia will explode in the phone market.

One of the new products complementing and expanding the usage of Qt will be a thin client architecture called Qt/Coco, named after designer Coco Chanel who said one can never be too rich or too thin. It is targeted at enterprise users and it will allow server side Qt apps to be deployed on thin, universal clients in an organisation, with the goal to dramatically reduce administration costs. Currently, Qt/Coco is in the prototype stage and it already shows amazing performance (ten times faster than X11). Trolltech is also developing Java-bindings for Qt called Qt/Java, which will allow Java developers to use the Qt API. A prototype will be available in the first quarter of 2006.

Qtopia is another success story for Trolltech. The company currently has 85 customers using Qtopia, from which 30 are mobile phone builders. Linux is the disruptive force in the handset industry and Trolltech's goal is that 100 million handsets are sold using Qtopia by 2008. Qtopia 4, which is currently under development, will be based on Qt 4. Some of its highlights will be a native sandbox for safe execution of programs, an integrated SQL database on every device and advanced graphics due to the new Arthur painting subsystem in Qt4. Some of the advantages of Qtopia over .Net are: customisability of the user interface, lower memory consumption and the availability of the source code.

Matthias Ettrich

The second keynote by Matthias Ettrich, founder of KDE and Trolltech's Vice President of Software Development gave an overview of Qt 4:

The design goals of Qt 4 were to enhance the capabilities, to increase the flexibility and to lay a solid foundation for the future. Mostly Qt 4 turned out as an immediate success. The clean Qt 4 code base allows Trolltech to turn quickly and there are successful and fast ports from Qt 3. Qt 4 has also been quickly adopted in the open source world. However, some users are dissatisfied with the speed of certain painting operations and the qt3to4 porting tool and the Qt3Support library partly failed to deliver: some ported applications compiled, but looked very odd when running. Qt 4.1 brings many small bug fixes, based on customer feedback. Arthur, the painting subsystem of Qt 4, is optimised, including accelerations using OpenGL. It also included a highly improved and extended Qt3Support library and an enhanced Qt Designer with an action editor. Qt 4.1 also includes a new painting backend for Arthur: a SVG backend that renders SVGs either using the native rendering backend (e.g. Render on X11, core graphics on MacOSX) or OpenGL.

For the future, Trolltech is porting Qt 4 to Windows Vista and it is improving the embedded and the MacOSX version of Qt 4. Also the Qt 3 to Qt 4 migration experience will be further improved. New features according to customer needs will be integrated. Some examples could be: scripting in dialogues, printing (currently there is no cross platform preview function available), desktop integration (systray, mimetypes, help system), high-level mainwindow integration in native platforms (e.g. always use SDI on MacOSX), cross desktop IPC, improvements to the help system (currently there is no infrastructure for a context sensitive help system) and a component model.

Aaron Seigo

After lunch, Aaron Seigo talked about Qt and the Future of the KDE interface.

Aaron first summarised some facts about KDE 3. It is based on monolithic libraries, has an attractive interface which is limited by the current desktop imaging techniques, has lots of features and lots of applications. KDE 4's library layout will follow Qt 4's more modular approach. The libraries will be split into modular components and frameworks and the naming and API consistency will be improved.

Next Aaron discussed the merits of the single click interface. Single clicks are good because they are easier to learn and more predictable then double clicks. In addition they are quicker. The downsides are that it is not straight-forward how the user can select something. And single click actions still have to be learnt. An alternative approach that shares the advantages of the single click interface, but does not have the disadvantages, is a mouse-over based interface. The basic idea is that a (transparent) menu opens if the mouse is over an icon. This context menu presents options like select and activate that can be performed with an object. The image below shows a mockup of such a mouse-over based interface.

Subsequently, Aaron discussed how desktop usage has changed over the years and that the desktop itself has not follow this change. In 1984 users were typically running one application and only managed a few files. Thus it made sense to put those files on the desktop. Today most users run several applications at once and have thousands of files on their hard disks. Thus putting files on the desktop is not useful anymore. To accommodate this Konqueror will be reworked for KDE 4. It will offer a simple and direct interface to browse the web and a content manager to manage files, context and data. KDE will also make use of new X.org features to allow e.g. transparent menus as shown in the image above. Control centre and the workspace utilities will be reworked and, of course, kicker will be replaced by Plasma. Plasma aims at making the desktop useful again. It will use organic shapes to make the user experience more natural, e.g. widgets will have round corners. Widgets will be extendable, stackable and tearable. It will also introduce universal widgets which can be put everywhere on the desktop. There are numerous applications for such universal widgets: hotplug actions, messaging notifications and events. Such widgets will be easy to create using Javascript and SVG and it will be possible to use alpha blending to blend them with the desktop. Plasma will include a single click installation for such widgets. Finally, panels will be replaced by widgets. Plasma also aims to be a workflow enabler. It will allow the desktop to float and recede. Workflow is supported by following context, multiple custom layouts and networking widgets.

KDE will also feature an improved KDevelop and Kontact. The MDI mode and the toolbar configuration will be reworked and enhanced. KDE will also feature a new default icon theme called Oxygen.

I want to thank Matthias Ettrich who made it possible for me to attend the Trolltech developer days in Munich

Comments

I'm a huge BSD license advocate. But claiming the GPL is not "really free" is disingenuous.

This argument against Qt is a smokescreen. No matter what Trolltech does, the GNU/GTK/GNOME community finds some new argument to pollute the mindspace. When Qt was proprietary they said it should be free. When Qt was QPL they said it wasn't GPL compatible. Now that it's GPL they say it's not free enough. The lesson has been learned: the naysayers don't want a solution, they want to complain. Even if Qt were placed into the public domain, with absolutely zero restrictions, people will STILL bitch about it. All you need to do is to look at any Slashdot topic on KDE or Qt and see the silly arguments waiting in the wings.

I know several small proprietary firms who have decided on Qt for their development toolkit. I talked with a developer of one a couple of weeks ago, and he said that Qt pays for itself by speeding development. He said that even though .NET is a vast improvement over MFC, coding in Qt is still more efficient.

Nobody is bitching here. Face the facts: with Gtk you can develop commercial apps for free, with Qt you cannot. You get it?

Nobody can suspect the people here to be Gtk fans. And yes, we will be comming to this problem as long as it will persist. We do it because we like Qt and therefore we are bothered because we see the commercial licencing cost as an important disadvantage of Qt versus Gtk.

I agree that Trolltech needs the money to pay the bills and keep Qt on the top. But does the price really need to be that high?

"Face the facts: with Gtk you can develop commercial apps for free, with Qt you cannot."

And still you see nearly no commercial apps developed with GTK+, in that arena it's vastly outnumbered by Qt. This should tell you that people developing commercial applications are willing to pay for the advantages they get by using Qt, and for the support they don't get with the develop for free alternative.

Besides you should really talk to some commercial Qt customers about how they rate the value for money when buying Qt. And stop listening to the theories about those hypothetical commercial basement developers.

...about one months salary for a programmer. Is it REALLY unreasonable to invest some money on a quality set of tools? And in corporate-environment, the cost of Qt is peanuts. Yes it is. It's only a fraction of the cost of the employees salary, and the salary is only a fraction of the total-costs the employee causes to the employer. So cost of Qt is a fraction of a fraction :). And besides, there are some tools that can costs over 10.000e!

"look how Novell has chosen Gnome/Gtk as default desktop/toolkit. The main reason is money, off-course."

Please provide me with a link where Novell said that "we chose GTK/GNOME because commercial Qt is just too darn expensive". If you have no link, then you are merely making assumptions.

What I meant to say was that if qt was really free (BSD/LGPL) or at least very cheap from the begining, Novell would hardly ever had bought into Ximian and got infected with Miguel Icaza and Co :-)

I thing the same applies to RedHat and Sun. Choosing default toolkit is a strategic decision for years and choosing toolkit which is controlled by a private company was risk for them. People run to Linux to escape the vendor lock-in. Why do the same mistale again?

Yes, I know that the full GPL developers don't have to bother about it. But private companies see this differently. What if Trolltech goes mad and increases the prize 10 times? As a commercial developer you're doomed. With Gtk you avoid this risk regardless to how this toolkit sucks.

If Trolltech will increase the price 10 times, then Trolltech will be the doomed one. It will lose most of its clients.
But lets say, that it will not lose most of its clients and Trolltech will really profit from such move. Then Qt must be worth 10 times more than it costs now. Wow!

Official Java Bindings would be nice. But an SWT implementation, or better a solution of the licensing issues (GPL vs EPL) regarding SWT, and maybe a good AWT implementation would be much more useful. At least for KDE/Linux users. I know, it is unfortunately a licensing problem and for Trolltech it is difficult to solve, because they want sell their commercial licenses to Java developers too. But for Java developers it makes much more sense to use SWT instead the Qt API in Java directly.

> Did you ever use/program SWT?
Yes. I used some. You know Eclipse? Azureus? And yes I programmed SWT applications and at the moment I work on an Eclipse RCP based application.

> Did you ever try to create a cross platform GUI with SWT which does not look
> alien on all platforms?
In my opinion, SWT integrates well in the platform, because it uses the platform widget set where ever possible.

> If you ever did you would know that Qt has a lot more to offer to Java
> developers than SWT.
Sure. Qt can offer more. But that is not the point. SWT applications can still run without Qt, on Windows, Linux Motif / GTK, MacOS, .... and that ist the advantage. But a Qt based SWT would nice for some reasons:

- SWT and Eclipse RCP Applications would better integrate in a KDE environment.
- And, maybe more important, eSWT for Qt embedded would be possible. And this make it possible to write Java eSWT applications that can run for example on Pocket PC, Symbian, Qtopia and maybe Gtk based devices like the Nokia 770. eSWT is already available for Pocket PC and Symbian. For a Gtk based device, eSWT is likely only a matter of time, because SWT for GTK already exists. Ok, eSWT is afaik available in a commercial version from IBM for Qtopia too, but who wants to buy a license to develop or use open source programs?

> Qt/Java is easier to program (much nicer API) and provides a native look and
> feel on all supported platforms.
Yes, but SWT and eSWT supports more platforms. Nevertheless an official Qt Java Binding from Trolltech would be nice, but in my opinion a SWT version based on Qt would be more useful.

> Actually Qt/Java is solving the major problem of Java for GUI applications. In
> addition there is a reason why not even eclipse is using SWT.
Eclipse don't use SWT? This is new for me. And I think you should verify this. ;-) SWT is the Toolkit from Eclipse.

> Did you ever try to create a cross platform GUI with SWT
> which does not look alien on all platforms?

Eclipse is created with SWT and it only looks alien on linux :) (much is solved by gtk-qt, though)

Your problem is that you don't distinguish SWT from Swing. But then, why are you disinforming people?

> In addition there is a reason why not even eclipse is using SWT.

This is certainly entertaining to read, because Eclipse is precisely _the_ SWT thing.

And what do you mean by 'not even Eclipse'? That's like saying that a bad solution has got to be an Eclipse solution :) But Eclipse is the KDE of development tools, it's powerful, flexible and moderately easy to use.

> Qt/Java is easier to program

There is no Qt/Java as of yet.

> (much nicer API)

Yes. That is right, the Qt API is what makes Qt great. I'm a Java developer and I'd choose Qt anytime, if the API would outweigh C++'s aversion towards threads etc.

> and provides a native look and feel on all supported platforms.

SWT also does that, unless you're on Linux (yes, I hate that file dialog that Eclipse pops up :) . as a matter of fact, the GTK file dialog vastly beats the stupidity of reversing the buttons and 'spatializing' the file manager)

> Actually Qt/Java is solving the major problem of Java for GUI applications.

There is no Qt/Java today so it isn't solving anything now.

> It is funny to note though that initially Java was hyped for GUI applets in > the early nineties but won the hearts of the developers for server
> applications.

Yes. That's beacause the language is great, but Swing sucks. SWT is better, but Qt/Java will probably be even better.

i learned that:
SWT-Qt is not possilbe because of (GPL for Qt, CPL for SWT) licence issues, SWT-GTK has no problems because GTK is LGPL.

now i just read that that using gtk-qt (a gtk lib that uses qt to draw widgets) along with Eclipse it is possible to have a nicer looking Eclipse.

so can i conclude that:
with a bit of LGPL 'glue' code it is allowed hook SWT up with Qt?

an other question:
can i use a propietary GTK app with, a GPL licenced, gtk-qt lib?
that again would mean that:
with a bit of LGPL 'glue' code it is allowed hook my propietary code up with, a GPL licenced, Qt?!

Eclipse comes with SUSE 10, which ships gtk-qt enabled by default. Of course, this turns Eclipse into a friendlier thing.

> with a bit of LGPL 'glue' code it is allowed hook my propietary code up
> with, a GPL licenced, Qt?!

Nope. However, Eclipse is not proprietary code.

The FSF says:

"The Common Public License is incompatible with the GPL because it has various specific requirements that are not in the GPL.
For example, it requires certain patent licenses be given that the GPL does not require. (We don't think those patent license requirements are inherently a bad idea, but nonetheless they are incompatible with the GNU GPL.)"

GPL compability are not really important when it comes to Qt, as it's dual licensed GPL and QPL. The QPL are rather easygoing license, it has two simple requirements. The code is under a open source license and the code are freely available. So the Eclipse's CPL are no problem as long as the code are available.

Someone create the myth that it wouldn't be possible, a lot of people believed it and the remaining ones either have already enough to do elsewhere or do not want to invest time into something which is obviously worked against intentionally.

"But an SWT implementation, or better a solution of the licensing issues (GPL vs EPL)"

Java developments tend to have huge budgets with large numbers of programmers. I don't think toolkit license costs are much of an issue. The flexibility of being able to choose between a Free or Commercial license is a big plus point for Qt and not a negative at all.

"But for Java developers it makes much more sense to use SWT instead the Qt API in Java directly."

Please can you add some sort of argument to support your assertion. Do you think there is something wonderful about subclassing event listeners as opposed to connecting signals and slots. In what way do you think that clunky way of doing things is a good idea?

> "maybe a good AWT implementation would be much more useful"
> Don't Trolltech already sell a Qt version of AWT?
At least for Qtopia/Qt Embedded a AWT version exists. And AFAIK there is also some work done on a free AWT implementation based on Qt. So this "problem" might be solved over time.

> "But an SWT implementation, or better a solution of the licensing issues (GPL
> vs EPL)"
> Java developments tend to have huge budgets with large numbers of programmers.
> I don't think toolkit license costs are much of an issue. The flexibility of
> being able to choose between a Free or Commercial license is a big plus point
> for Qt and not a negative at all.
Yes, I also think the license costs for a commercial project wouldn't be the problem. But, there is no Qt based SWT available because AFAIK the licenses EPL and GPL are not compatible. I also think, that the choice between a free or commercial license for Qt isn't bad. But for SWT and the EPL this AFAIK prevents a Qt based SWT implementation.

> "But for Java developers it makes much more sense to use SWT instead the Qt
> API in Java directly."
>
> Please can you add some sort of argument to support your assertion. Do you
> think there is something wonderful about subclassing event listeners as
> opposed to connecting signals and slots. In what way do you think that clunky
> way of doing things is a good idea?
I don't think that a Qt Java binding would be bad. But I think a Qt based SWT implementation would be more useful. Please see my arguments in my reply to the other post.

I am not convinced of the mouse-over interface, as from the mockup I don't see how the default operation (open, run, ...) can be found (and triggered) _fast_. Maybe if the menu would only be the half with of the icon, so clicking the icon that is not under the menu triggers the default operation. And if the mouse "enters" the icon from the left, the menu is display on the right side and vice-versa.

Another idea would be to imitate the behaviour of KDE toolbars: if there are additional operations, open a menu if the thing is clicked for a "long" time.

Agreed that mouse-over doesn't seem to be interesting, disagreeing with using some kind of menu with the left click: what's wrong with right clicking??

With a mouseover, there is usually a delay between the mouse pointing to an icon and the apparition of the menu: if there is no or a small delay then it annoys the users when it moves the mouse and it makes an unwanted menu appearing, if there is a large one then it annoys the user because it takes too long to appear..

I agree that double-clicking icons is not good, but my question is still what's wrong with right clicking?
A single left click to activate the default action, a right click to select another action, KISS, it works!

I don't think that there is anything wrong with right clicking, or another "special" action (Apple key), as long as you KNOW you can make a right click (or that special action) to 'do what you want' with the object you are looking at.

Okay, most users know about it, but an unknown percentage of a >6 billion population may have never used a computer.

If a good solution is found, that on the one hand does not confuse the user nor drives more professional users crazy and on the other hand gives any human in the world who is able to see (and read) an idea what he or she can do, it would be 'one small step' forward, away from a 'silly computer', towards a useful machine for everybody.

Right-clicking of course works. ENIAC did work as well but I though prefer my notebook (at least in every-day life).