The latest Commit Digest issue comes along with the second Plasma screen cast, this time explaining data engine code. Also, several games moved from review to the main module, and first work at RandR 1.2 support begins for kcontrol.
The Commit Digest issue 61 features also the first screen cast about Plasma together with some additional words by Aaron. While that one focused on the form factor idea in Plasma, the second video focuses on the data engines available:
There are also video downloads available at the Commit Digest. As you might notice Aaron actually does not show any RSS Plasma widget. I wondered why this is and might have found the explanation deep inside the Digest
an applet for the cia engine. would look nicer if the layouting actually worked properly…
I’m curious about the other data engines we might get and how they will find their way into appealing Plasma widgets.
In the meantime three games left the review and joined the main module just in time<: Bovo, KJumpingCube and KSudoku. While I’ve never tried or even heard of the first two ones I’m very pleased to see that KSudoku made it into the final module - I really use it a lot and really like it. It is the best Sudoku game I’ve seen so far anywhere.
The Commit Digest also mentions the Oxygen meeting which took place this weekend - however, I haven’t seen any screen shots of the new Oxygen Theme for KDE 4 yet. But judging from the other work these guys are doing I think I will not be disappointed…
Anyway, as with every Commit Digest there are some hidden eggs I really like - this time it was a comment about RandR 1.2: Kcontrol will get RandR 1.2 support:
Rename RandRScreen to OldRandRScreen. A new RandRScreen class will be created to handle randr1.2 requests, but the old one will still be used when randr1.2 is not available. […] OldRandRScreen was not a good choice for the class: renaming to LegacyRandRScreen Add a basic RandRScreen class which will implement the randr1.2 screen calls
In krandrtray, the functions for the legacy randr interface are properly isolated, now it is time to implement the new interface
I was already wondering when the first RandR 1.2 GUIs would come up, and it is nice to see that they will be well integrated with krandrtray and therefore with KDE. The only thing missing now is a radeon graphics driver supporting RandR 1.2.
Most free X.Org graphic drivers are based on Mesa, which is a free OpenGL specification implementation. However, while OpenGL is already in Version 2.1 the Mesa implementation only supports version 1.5. This is to change soon - but OpenGL will make new releases as well.
Graphics in Linux has several problems and issues: first of all there is only Intel providing real free graphics drivers - but Intel does not build high-end graphics software. Second, Microsoft did its usual monopoly homework, and everyone talks about DirectX 10 - it becomes harder to port graphics apps between Windows and Linux because on Windows you most certainly want to use DirectX. Third there is OpenGL itself: the development stagnated for quite some time and the current OpenGL API does not support all the new cool hardware things out there. Fourth, and that is something I realized just few hours ago, the OpenGL implementation for Linux, Mesa, does only provide an OpenGL implementation for Version 1.5 - although OpenGL 2.0 was introduced almost three years ago.
The first problem might see changes in the future: Nvidia always provided advanced graphics drivers for the Linux community, and AMD at least said it would like to solve issues somehow. The second problem is more difficult: it depends on how well OpenGL evolves in the future. If the API is well implemented with Windows and if there are impressive features and such things available which are appealing to developers on the Windows platform these might prefer OpenGL again instead of DirectX. But to achieve that goal the OpenGL people really have to do their homework.
This is somehow related to the third problem: OpenGL itself. Version 2.0 was released in autumn 2004, version 2.1 was released last year. This year we will see two releases at once: one release in the 2.x branch - and a 3.0 release.
First one that is coming out soon is Longs Peak (OpenGL 2.x), which is a major clean-up of the code after almost a decade and a half of nothing else but stacking numerous extensions together. This API is supposed to arrive in summer timeframe, most probably July. Approximately three months after that, Mount Evans (OpenGL 3.0) will run specifically on hardware born after November 8th, 2006. You’ve guessed it correctly, we are talking about DirectX 10-class hardware, bringing all the features of unified 3D architecture to the world of OpenGL.
This means that OpenGL will get all cool features as well - eventually. I hope that this move is not too late, and I really hope that this will bring more people to use OpenGL again. This is crucial as soon as it comes to porting applications to Linux or any other operating system.
But to use all these cool features there must be drivers available who actually implement these features. Nvidia and ATI/AMD provide Linux drivers (and Windows drivers of course) implementing OpenGL in version 2.1 (Nvidia) or 2.0 (ATI/AMD). However, the free implementation of OpenGL, Mesa 3D is only at version 1.5 - which was released 4 (!) years ago. This is depressing somehow :/ However, the current development version of Mesa, version 6.5.3 is in a good state and a new version, v7.0 featuring OpenGL 2.0/2.1 support is expected soon:
Mesa 7.0 is expected to follow shortly.
Shortly can be anything, but to me it sounds like we see OpenGL support this summer.
The question is afterwards: how fast will the drivers pick up the implemented support for the new API? I can only hope that they are already targeting at the new Mesa release.
And there is another question: how ling will it take to take on with the next OpenGL releases? 4 years are just too much time for the fast developing graphics market.
But having a look at the Mesa news it looks more like that the main development was done in recent months, meaning that the development sped up, compared to the time before. This would mean that there is now an active development community behind Mesa. And if that is true chances are that we will see OpenGL 2.x and 3.x support soon in Mesa.
In any case, the new Mesa will be released soon. And since it will be the first main release after 3 years we can expect a lot of news overage, maybe even an interview or two and quite some information about the road map of Mesa and even OpenGL.
I just hope Mesa will update their homepage till then, it looks horrible at the moment
Phil Rogers was recently interviewed by extremetech.com about the ATI drivers. While the interview focuses mainly on Windows there are some information about Linux as well.
In the 5-page long interview Rogers mentions Linux while he talks about a totally reworked OpenGL driver: the driver was rewritten from the scratch in the last three years and is developed for Windows XP, Vista and Linux. While (of course…) the Vista driver has the main priority the Xp and the Linux driver will be shipped later this year.
Besides the Linux driver itself Rogers mentions also a new Catalyst Control Center:
On the Linux front we will also be releasing a new version of the Catalyst Control Center quite soon.
Sounds great - however, I wonder when we will see the first results of this new drivers. And I wonder what this new driver has to do with the AMD announcement to fix certain issues of the current driver regarding to Open Source. Remember: the fglrx driver does not support AIGLX or has its own implementation (like Nvidia has), not to mention stuff like RandR 1.2.
Last but not least, I wonder which OpenGL version will be supported by this new driver - it is planned to release a new OpenGL API version 3.0 this year (!) and it would be nice to see ATI being fast to adopt it.
The new commit digest is out, and features several important news. Among them are the first real Plasma screenshots, a Kcontrol module for Kwin and Krita and Kalzium improvements.
This weekends Commit Digest, Issue 60, was already mentioned last week to become a big one: the first real Plasma screenshots were announced. But even without the Plasma news there are enough interesting news and changes - and it also feature two videos, something I never saw before in a Commit Digest. Here is an overview about the most important and notable news. Plasma&SuperKaramba
First of all, here is a Video showing Plasma in action (a mpeg version is linked at the Commit Digest):
Pretty neat. Of course similar things have already been possible with SuperKaramba, but Plasma will provide much more functions than SuperKaramba did - this clock is just a first example and proves that the basics are indeed working.
Speaking about SuperKaramba, the Digest also explained the realtion between SuperKaramba and Plasma:
SuperKaramba themes can now live within the Plasma space and will help fill the initial void till real Plasmoids appear.
Sounds to me like the merge will take more time than expected, but that is ok: Plasma is not complete at the moment and we will even see huge improvements in the step from KDE 4.0 to KDE 4.1 In the meantime SuperKaramba might deliver everything which is still missing until both finally merge. Kalzium
One of Kalzium’s main new features will be the molecular viewer:
Kwin
The new composite extension of Kwin develops quite well- but had to be enabled by command line in the past. This changed now: kwin gets a kcontrol modul. Atm it does not really do anything and kwin doesn’t care about the module, but that will change soon. I’m really looking forward to the next KDE Four Live release where I can test this feature and have a look at the new kwin composite features.
Speaking about the composite extension several application developers were faced with the problem that they wanted to support such features in their applications, but needed to know if the composite extension was activated. Therefore the applications developers started to implement their own solutions for each application, which of course is unnecessary duplicated work. Therefore, a common function to check if the composite extension is enabled was introduced: bool KWindowSystem::compositingActive(); Nothing revolutionary, but as said necessary. Now the applications developers need to get aware of that function.
WebKit
Work started to have the option to integrate WebKit as a kpart in the future. This means that users can choose if they want to have KHTML or WebKit displaying their web pages. If this work is finished it might also inspirate other people to start a stand alone browser for KDE based on WebKit. Of course this does not mean that konqueror or even KHTML are replaced or anything like that - it simply adds another possibility.
From my point of view this is great since I have great hopes in WebKit and the fact that several parties are involved with the development: Apple, Nokia, Adobe, many KDE developers, and so on. Still, I would prefer to see that all KDE/KHMTL developers would be fine with WebKit, atm there are still some strong emotions among some developers.
Krita
The Krita development is pretty strong - as usual. And I have to admit that I’m really looking forward to the new Krita 2: I was used to Gimp in the past but started to play around with Krita in the last days and weeks whenever I had to modify images - and I was impressed! It works reliable, fast and just smooth. And this will hopefully be better: with the last week Krita got an OpenGL interface for display of HDR image exposures. The print support was implemented, new layers and transparency features were added, etc.
But the Krita developers are also faced with a current problem: they want to improve the usage of tablets (think of Wacom here), but to achieve this goal they need money to buy them. Therefore they asked the community to donate money. All over all they need several hundred Euros, which is quite a lot, but you know the math: if each user donates 1 Euro…
Stae of KDE 4 in general
There are many more changes and improvements making this Commit Digest worth a read. It also shows pretty well how active and alive the current development and the community around KDE 4 is. Also, with Plasma now getting into shape there are hardly any base technologies left which you have to worry about if they will make it into KDE 4. The only things I’m missing are news about kicker and kmenu replacements.
However, the current state of KDE 4 itself is best described by hints found in to other posts: in recent posts both Annma and Troy mentioned that they currently use KDE 4 to accomplish their daily work! Annma mentioned that she was pretty impressed seeing KDE 4 in such a good state already, while Troy pointed out that the state of KDE 4 is enough to write his famous articles inside of KDE 4.
Or course it does not mean that it is ready for normal users yet - base desktop applications like the menu and the taskbar will be replaced before the final release - but it is on a good track! And there is still a month left till the first Beta release…
