|
The Oxygen iconset is moved from playground to kdelibs, changes made throughout KDE to support the new icon names specification. The Crystal iconset is moved from kdelibs to its kdeartwork retirement home. More work on the Oxygen widget style. Security fixes in KTorrent. Initial work on "uninstall" functionality for the KDE Windows installation utility. New "Snowish" theme for the Kamion user information migration utility. Continued graphics improvements across kdegames. Improved wireless network encryption support in Solid. Further work on the Amarok 2.0 porting, with particular attention to the Music Store integration elements. KPilot is to make a surprise return for the KDE 4.0 release.
|
Branan Riley talks about the game KSpaceDuel and his plans for its KDE 4 port:
|
I decided to do the port because I like the game, and didn't want to see it go away. I was looking for something to really sink my teeth into with KDE 4, something that would be fun to work on, but was also small enough that I could fit around my school schedule. I've always enjoyed the game (even though I always lose), and when I noticed that it needed to be ported to SVG and didn't have a maintainer, I decided to try my hand at doing the port.
I actually haven't made any big feature commits since the original port - a few fixes for bugs in my code, and a few small changes, but that's it. I have, however, filled up about half a notebook with scribles on different ways to add different things. I've finally settled on how I want to implement everything, and the first commit might come through within a couple of weeks (please don't hold me to that - schoolwork might get in the way).
When I started, KSpaceDuel was already ported to KDE 4, it just didn't use SVG graphics yet. I wrote the SVG patch over a couple of afternoons (the first day was actually spent doing API documentation, so it was a one-afternoon patch). The engine already used QGraphicsView and QGraphicsPixmapItem, so all I had to do was switch it to QGraphicsSvgItem (but don't tell anyone that - they all still think it must have been hard to port to SVG :-P). I'm pretty sure that Dirk Rathlev did the original KDE 4 port of the game. You should really talk to him, too, since he was sort of the unofficial maintainer for a while.
My list is mostly short-term stuff. Sound, multiplayer, and savable configurations are all things I want to get in before KDE 4.0. Creating new areas of space will probably require a lot of work on the physics and AI - the two most important parts of the game, actually. I don't want to mess with them until I really know what I'm doing. So that will be more long-term, possibly KDE 4.0 though, depending on how long the rest of KDE 4 takes to get ready.
KSpaceDuel is actually really fun to work with. The code is very clean and organized, and most of it is well-commented. My issues now are mostly about learning APIs, not fighting with the way KSpaceDuel is designed. I need to learn Phonon, GGZ, and some of the more advanced KConfig features before I can get back to coding. I think I've just about figured out all the multi-configuration stuff, but it's still going to be a pain to code. Until I have a chance to do a couple of test apps, I'm putting that on the back burner. Sound first, then GGZ, then back to the configuration stuff.
KSpaceDuel is actually my first real KDE development experience. I've done some small code tweaks on my own system, but I've never actually submitted any patches to KDE before taking over KSpaceDuel. It's a pretty awesome feeling being involved in the coolest GUI project on the planet.
|
|
Aron Boström introduces his recent import into the KDE Games playground, Bovo:
|
Firstly, it's not really "chess" at all! That's just what it's called in my local language. I dropped the "chess" part of the name to avoid confusion. Though, I'm thinking of renaming it again, as I did some research and found that it already has an English name.
In Japan, it is referred to as Gomoku (or freestyle Gomoku), where for centuries it has been played on a Go board. This name seems to be the dominating English name as well, but other names I have seen are Connect Five, X and O's and Five in a Row. In German it is called "Fünf-in-eine-Reihe" and in Swedish it is either "Luffarschack", "Fem-i-rad" or "X&O". In Europe, it is mainly played with pen and paper.
The game rules are rather simple. X starts (in Japan, "black" starts) to place his mark. A placed mark cannot be moved and nobody can place a mark on top of an already-placed mark. The two players take turns to place their marks and eventually one of them will have connected five marks in a line and thus wins.
I developed the AI code in Java some years ago as my examination task from the Swedish "gymansium" school (Upper Secondary School). Since I haven't had anyone to play with since then, I decided to port it to KDE 4, partly so I could play it against the computer, and partly to refresh my Qt 4 skills.
Before a release, I would like to introduce theme support in the already-present SVG rendering, thus allowing both European and Japanese variants. Also, I would like to clean up the rendering code, making it faster and less memory demanding. As the game is unbalanced (i.e. whoever starts is guaranteed to win rather quickly with "perfect play") I would also like it to alternate whether the AI or the human starts, to make it "equal". Furthermore, I would like to kidnap an artist and blackmail him for some decent artwork. However, the game is already fully complete, so I could at any time check out the Subversion repository and release that as version 1.0.
In the long term, I have planned to add an adaptive AI mode to the game. This means that the game adapts itself to the skill of the human player, so it is always challenging but never "impossible". Also, I'd like it to be included in KDE 4.0 :)
Personally, I started monitoring KDE mailing lists five years ago, hoping to start contributing. But I always hid beneath the protective laziness of Java, which I perceived as a more convenient language. A year ago, I decided to learn C++, so I enrolled in a university course and worked a lot with Qt 4 during my Google Summer of Code project. The past winter I worked part-time as a C++ laboratory supervisor at my university and a few weeks ago I got re-involved in KDE. Mainly with this project, but I have something a lot more complex hiding on my hard drive ;). Though I doubt I will ever finish that (unless I am somehow paid to work full-time on it for a month or two). Still, I consider myself a KDE junior developer.
If anyone has any more questions, come and talk to me! I'm lurking in #kdegames and #kde4-devel on irc.freenode.net most of the time (alias 'hrafnahnef').
|
|
Torsten Rahn discusses the Marble geographic tool, the next development stages, and its impending move into the kde-edu module:
|
Many people may already be aware of it, but I would like to formally express my intention to move Marble into KDE-Edu.
Marble is a generic geographical widget providing a globe that people can browse the world with. I recently added support for co-ordinate grids and initial Wikipedia integration. I also started ways to measure distances between placemarks. Some recent screenshots:
I'm currently aiming for a move to the kdereview module within the next 10 days and a move into kde-edu (right in time for KDE 4.0) once the review weeks have passed.
By that time, Marble should have also basic KDE-ification which would include the following extra functionality:- saving maps (in PNG)
- printing maps
- copying maps to the clipboard
- proper documentation
- proper CMake inclusion
So, if everything goes well, the first inclusion of Marble (already very stable) into KDE-Edu should happen around April 2nd 2007.
This would still be right in time for a possible feature freeze on May 2nd and offer enough time to solve remaining issues and take delays into account.
I already talked with Albert Astals Cid of KGeography in the past about possible sharing of funcionality between the two applications in the future to varying extents. Whatever the solution will look like, I personally think that this can only be fully addressed after KDE 4.0 has been released. Currently, KGeography uses bitmaps imagery to store and display data, which is pretty inefficient in terms of flexibility as well as filesize. Marble uses a smart combination of vectors and bitmaps, which basically offers improved quality for the maps, better accuracy, more flexibility and all this at much less file space utilisation than KGeography needs to cover the world fully. I consider the availability of a 2 Dimensional view for Marble an additional requirement to merge functionality. And this feature won't be implemented earlier than the Google Summer of Code 2007, for which I offer my mentorship.
So that's one of the reasons why merging functionality between KGeography and Marble in some way will likely have to wait until KDE 4.1.
|
|
So far, the most visible element of the Oxygen user interface initiative has been the new iconset for KDE 4.0. An important milestone has thus been reached with the move of the Oxygen icons into kdelibs this week. Aaron Seigo summarises the occasion:
|
hi everyone...
if you svn up the playground/artwork/Oxygen dir, don't have a heart attack. the icons are now in kdelibs. please commit final work there from now on.
we still need to work out a few issues including:- generating new png's from the svg's
- porting of the code base
- i have patches for libs and base already together and apparently a few others are also done?
in any case, congratulations. the oxygen project is moving on to its next step of maturity, importance and success. =)
*pops the champagne*
|
|
One of the special moments in KDE is when a contributor closes more than 100 bug reports in a week. Going above and beyond this week, Bram Schoenmakers has somehow crushed 140 bugs this week, or in terms easier to understand for mere humans, similar to a dedicated crack team of bug killing assasins working without sleep for days on end. Congratulations Bram!
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
![[*]](/images/standard/security)