This is another example why Nokia is currently the most OSS friendly company when it comes do Desktop applications.
First they sponsored most of the work on Telepathy which they needed for their Maemo platform and which shall now be used as a desktop-wide presence framework in gnome.
Then they sponsored the development of Tracker, which will be used on Maemo Frementale and probably will be the most advanced desktop-search engine with the coming 0.7 release.
This two projects are already great examples for working with the OSS community; instead of just using the Kernel and building your own closed user-land, they chose to use available Open Source projects and supported them to bring them in shape – therefore the whole Gnome desktop profited.
But now they did probably the most important contribution for the whole OSS desktop; the relicensed Qt under the LGPL. Up to now the linux desktop was split up between Qt applications and GTK applications. This split was really deep; it went from a different API down to the X11 level how the primitives were drawn. This was like that, because the licensing of Qt and GTK was incompatible and absolutely no code could be shared.
Now both Qt and GTK are LGPL, but expecting that either Qt or GTK will be discontinued now is utopic, since many applications would still use the dropped toolkit and developers would not just adapt to a new API if they already one that they like.
But what I think we can expect that Qt and GTK can share a lot of code. Right now GTK uses Cairo for drawing, while Qt has its own implementation which does basically the same. There are also many other such areas where code was unnecessarily duplicated.
So what I hope is that the difference between Qt and GTK will become just the API – with a mostly identical implementation.
I think your post is missing a paragraph. The one where Qt is actually released as LGPL.
Another issue: I have always wondered why there is no such thing like a gtk engine beeing able to run qt code (or vice versa). Now I understand that this is because of the deep deep differences and not beeing able to share code. Do you think that such an engine is now
a) possible and b) probable?
yeah I indeed forgot to mention the topic inside the post 😀
what exactly do you mean by “gtk engine running qt code”? There are already engines which try to map one API to another:
but what I expect is that both codebases will be merged into one over time…
I know the first one and the second one does not seem to have any releases yet, but as far as I understand this is a different approach. They are building a theme that makes qt apps look like gtk. What I mean is an engine (library) that can run both. In other words: If you want to run amarok in gnome, you have to install only amarok, not qtlibs as well (and half of kde, but thats another story)
ah, ok. Such a library will not be much different than where we are today, since it would have to support both the GTK and the Qt functionality and this is basically what qtlibs provide.
But if they share more code “qtlibs” will smaller and it will also make it easier to agree on a common theming specification.
So in the end you should not see any difference as a user…