Apple’s Leopard with DirectX-like OpenGL? More hints.

There are additional hints that Apple plans to implement the new generation OpenGL into their products.

I already expressed that there are hints and reasons that Apple’s Leopard might ship with a new OpenGL version – either “Longs Peak” (which could be seen as a new 2.x version) or “Mount Evans” (which could be seen as a totally new branch like 3.0).

In short the reasons are that Apple uses OpenGL – and OpenGL is currently lacking a lot of features and does not support all the new goodies of today’s graphic hardware (think of DirectX-10-hardware here). But there are two new OpenGL versions expected this year: one cleaning up the current API, and another one with revolutionary new code with support for the newest hardware/features. Both are expected somewhere around the release date of Apple’s Leopard in a distance of 2-3 months.

Now ghost-sypher pointed me (thanks for that!) to a paper describing the working groups of the new OpenGL releases. And there it turns out that the chair man who is responsible of coordinating and planning the next revolutionary release “Mount Evans” is Jeremy Sandmel – from Apple.

This means that the main person behind the newest OpenGL – which will support all the new graphics technology available today – is employed by Apple.

So Apple is deep involved with the newest OpenGL work. And being able to use the newest graphics hardware would definitely benefit the marketing. Therefore I think it is safe to estimate that Apple will indeed try to release OpenGL “Mount Evans” support as fast as possible. And I would not be surprised if that would be included with Leopard if the OpenGL team releases fast enough.

Amarok and Digikam ports for KDE 4

KDE 4 is coming closer, and the 3rd party programs are busy porting. Amarok now unveiled that they will reuse some Plasma techniques to create appealing effects while Digikam reported a first version running on KDE 4.

Amarok and Plasma

The Amarok team decided to implement the context view for the upcoming Amarok-KDE 4 version in Plasma:

we have been considering moving to Plasma for the context view (the big display in the middle) in Amarok.
[...] there are the great possibilities that Plasma offers us: Ability to include scriptable Plasmoids, fancy SVG rendering, and theming.

While this includes trashing almost the entire existing code the developers are looking forward to this solution and estimate that the advantages outweigh the disadvantages.
Aaron Seigo mentioned in this regard that Amarok will use static linkage: Amarok will come with Plasma included in their own code and therefore not sharing the Plasma engine of the desktops. However, this is necessary since Amarok decided to have no dependencies on kdebase. Also, Aaron refuses to give binary compatibility in the Plasma API before the KDE 4.1 release – wasn’t aware of that, btw.

Digikam

One of the other big, 3rd party applications for KDE besides Amarok is Digikam. And the porting of the applications has started as well some time back. Today it was reported that it works on KDE 4 indeed:

Today, after 5 weeks of intensive work to port source code (and one million of commits on svn), digiKam compile fine now under QT4/KDE4.

Porting in general

Porting these applications is an important step for KDE 4 because it is the Litmus Test of the APIs and the general concept of KDE 4. Porting such big applications will unveil if there are APIs which still need a change or design concepts which simply don’t work in the real work.
Besides Digikam and Amarok there are other port efforts going on at the moment: ktorrent is working actively on a port. Kile will start porting directly after the release of Kile 2.0 (I’m not sure when that will be, but hope it will come soon). Another “big” 3rd party program is K3B, but I’m not sure about current porting efforts.
Speaking about 3rd party: as it currently looks like Kopete might not be part of the official KDE-Network module at release time because the port might not be ready. This would make kopete a 3rd party app, and I think that could be a chance for Kopete: I always had the feeling that the fixed release schedules were too tight for an app like Kopete (which has to react to protocol changes sometimes quite fast and out of any release cycle). But that’s not sure yet.

In any way its pretty clear that some big programs will already be ported at KDE 4 release date, and that some will come later. But if the current Gamma plans are accepted by the broader KDE community some of the yet-not-ported apps have some extra time for porting.

OpenSuse Build Service: Problems building Debian packages

After successfully building packages for OpenSuse and Fedora I thought about building Debian/xbuntu packages. But it turned out this task is more difficult than I expected. However, in the future the OBS might help with this task.

For me the main advantage of the OBS is that it helps building packages for more than one distribution. And it works quite well for me for OpenSuse and Fedodra packages.
However, the real interesting part begins when you leave rpm based distributions behind and start building packages for a totally different package system. Therefore I looked into building packages for Debian and xbuntu.

But the OBS is currently not much more than a build platform – you have to provide configuration files and everything else by yourself. Nothing is prepared for you, so you are on your own. That also means you need experience in building the package type you want.
And now comes one of the main problems of dpkg packages: the creation of them require certain tools you only have on a dpkg based system. While the entire configuration needed to build a rpm is handled by a single text file (the spec file) the Debian package tutorial uses helper scripts and a variety of different configuration files and directories. So to package dpkgs with OBS you still need to know everything about packaging dpkgs – and a running dpkg based distribution. And that’s exactly what I’m missing here and also what I wanted to avoid. And it means that the OBS does not help as much as I hoped.

Anyway, I think I will start playing around with building some simple packages in a VM to get the idea. Can’t hurt to know more about both worlds.

And the future of the OBS might still hold some very helpful features in this regard: it is still in development, and there are projects under way to evaluate if it might be possible to generate package build configurations out of some kind of meta data. Imagine an interface where you just have to enter the needed data for example into a xml file. The OBS would afterwards create all needed spec files and dpkg configuration files for you out of the XML file data.
While nothing is written in stone yet such a feature would make very much sense – and would again help spreading software on Linux.