|
Work on porting kdegames applications to SVG and other general improvements continues at a fast pace. Work continues on video support in KPhotoAlbum. Krita gets a new star shape tool. Okular gets support for freehand ink overlays in presentation mode. Kate gets syntax highlighting support for ActionScript and RapidQ code. Mailody continues to mature as an alternative email client. Strigi refactors to allow searching within multiple simultaneous indexes, with preliminary interoperability with Akonadi on the horizon.
|
The games applications within KDE have seen a huge surge in development interest within the last few weeks, in an effort to overturn the years of neglect the module has experienced - though state of the art at their conception, the applications have become progressively more dated as the rest of the KDE desktop has advanced, grown and matured
The momentum now developing behind the module is building to a critical level, with the current progress towards their goals discussed at their recent online meeting:
|
About 25-30 people attended, including the majority of active kdegames maintainers, artists, new developers, translators and other general contributors. We had a brief round of introductions and then began to tackle the agenda.
The first topic discussed was the KDE Games Survey. Survey results can be analysed online, and are available until Dec 15th at http://www.surveymonkey.com/Report.asp?U=274837292751
Most people agreed that the game ratings (see survey) were very useful, especially to identify which currently non-maintained applications we should focus our efforts on for KDE 4. So the question of finding active maintainers for some applications was raised, again. The components who still do not have candidates are libkdegames, KSirtet, Klickety, KFoulEggs, Kolf, Atlantik, KSame, KSokoban and KAtomic.
During the meeting, we already identified people willing to step up and work on some of these applications. Dmitry Suzdalev is already working on KAtomic, and has volunteered to maintain it for KDE 4. Johann Ollivier Lapeyre (from the Oxygen art team) will team up with him and improve the graphics.
Paul Broadbent renewed his former proposal made on the kde-games-devel mailing list, and is already reviewing Kolf. He intends to work on it for KDE 4, and is currently getting familiar with the code. But there are still several unmaintained applications. If you want to consider maintaining one of them, please get in touch with us through the kde-games-devel mailing list. An updated list of maintainers is now available.
The next issue was about removal of unmaintained games from the module. We also considered the removal of games that are starting to show their age and that were rated low in the survey. One proposal was to remove duplicated functionality, and some mentioned KSame/Klickety as an example of this, which was not agreed by others. The discussion proceeded for some time, but it was clear that we would not reach a consensus on this. The survey results regarding this topic are also divided.
As a way to deal with this issue, we discussed what was tentatively called the "kdegames guidelines for KDE4", a loose set of rules specifying what we are looking for in games that will be part of the KDE4 distribution. Following the results of the survey, we agreed on some basic minimum standards:- Scalable windows and graphics (preferrably SVG based)
- Theme support
- Usability improvements
- Some form of network support (where applicable)
We also agreed to form a review team for kdegames with some of the more experienced contributors, formed by Albert, Pino, Coolo and Johann. The plan is not to tackle the issue of removing games right now, but to re-visit this topic in 3 to 4 months. This gives us more time to find maintainers or contributors that can bring current applications to the level of polish required for KDE4. There is plenty of time for this, but if no-one steps up to maintain an applications, and if it is not polished to a level consistent with the rest of the KDE4 artwork (think Oxygen-quality), then the review team may consider removing it from the main kdegames module before KDE4 is released.
For the same reasons, the proposal to move some games from kdeedu to kdegames is on-hold. There is really not much difference to the end user where the applications reside in the KDE SVN repository, the important point is to make sure these are grouped using freedesktop.org standard .desktop categories, which will end up grouping blinKen, KHangMan, KTuberling and Kanagram anyway under the "Games/Kids" category. It was noted that the games in kdeedu all have active maintainers, so they are in better shape than some in the kdegames module. Collaboration is needed, but we already have developers working on both modules actively.
Following the agenda, we then discussed the inclusion of new games in the package. Initial candidates are KSirk, KBoard, KSudoku and KBilliards. KSirk and KBoard are already in KDE SVN (playground) We will invite the developers of ksudoku and kbilliards to join the module. We will follow the KDE procedure for inclusion of new applications, with a move to kdereview before games are accepted into kdegames.
There was discussion on the issue of using custom widgets for games. The general consensus was that we do not want to create a new widget set just for games, and will generally use what KDE offers in terms of dialog boxes, toolbars and other widgets. But the in-game GUI does not have to follow this rule, developers are free to use what is more appropriate for buttons, text areas and other control elements. A good example is blinKen. The in-game elements should preferably be themeable as well.
It was suggested that all games for KDE4 ship with at least one Oxygen theme, for visual consistency with the rest of the desktop. Johann is already working on this and has committed a suggestion for KWin4 as a start. Other games that are already being revamped following the "kdegames guidelines for KDE 4" are KMahjongg, KPat and KReversi.
All in all, a very satisfactory result, considering it was a first meeting, and the chaotic nature of IRC communication. In the end we agreed to repeat the meeting experience next month. The scheduled time will be announced via kde-games-devel mailing list.
Current development screenshots:
|
|
Mauricio Piacentini explains his recent work on new functionality and future optimisation within KMahjongg:
|
These screenshots show the new angle switching functionality. Angle switching is the ability to quickly cycle between 4 points of view of the board (NE,NW,SE,SW), mapped by default to the j and g keys. This is an important feature, sadly omitted on several Mahjongg solitaire implementations, but in my opinion, it is really necessary with some layouts to quickly check if tiles are obscured by other piles. This is especially required on deeper board layouts. And we will have some of them, as KMahjongg now accepts dynamic board sizes, where previously we were limited to 5 levels.
In order to implement angle switching I had to change drawing code yet again, separating the tile backs from the faces, and adding a sprite class that knows how to do the composition and layering quickly. Switching a view is very fast, as it requires no re-rendering of SVG content or pixmaps caches. I recommend that you checkout the code from SVN and give it a try.
The version of KMahjongg currently in SVN is still a bit slow in the initial resizing, but this has to do with the large background being rendered from SVG without any caching or optimization yet. I plan to address this when customizing the background options.
As for next steps, there are still improvements needed to the board editor controls to accomodate the new dynamic board options, and a reorganization of menus and customization settings. Now that tileset format is defined I will also make KShisen use it, and write the guidelines for other tile authors. It currently uses an external XML file for sanity checking and versioning, and the names of the tile elements are specified in the SVG as element ids to optimize rendering (DRAGON_1, FLOWER_1, TILE_1_SEL, for example).
My initial time measurements of rendering speed seems to confirm what Zack told me during Akademy, rendering a face using this approach from parsed SVG content takes more or less the same time as scaling a QPixmap. Final optimization will of course take place after feature freeze, and we hope to have a common approach (kpat, kreversi, kmahjongg, others) for initial rendering and caching of SVG data, something that is already being considered by several developers.
|
|
Two new KDE Games module candidates are Kiriki and Kombination. Albert Astals Cid, lead developer of both applications, briefly introduces the two games:
|
Kiriki is a dice game written for KDE 4. It is a clone of Gnome Tali (gtali), which in turn is a clone of Yahtzee! It is possible to play with multiple human and AI opponents and print out the results of the game (screenshot).
Kombination is a Scrabble-like game, written for KDE 4. It features a client-server architecture and kspell-guided word checking. It also has support for different languages (screenshot).
|
|
Community initiatives have produced increasingly impressive results as of late, with the extremely productive KDE Bug Triage days and the kdegames online meeting producing real results.
A great outreach came in the form of the kdegames survey, of which the comments make interesting reading.
|
Carsten Niehaus introduces a new supplemental periodic table style - Hexagonal View - in Kalzium:
|
|
|
Over the last couple of weeks, you may have noticed the introduction of extended statistics in the KDE Commit-Digest. Within this section, there are (unknown) labels next to some percentages, and these numbers are intolerably high. So, if all KDE contributors with SVN accounts can follow the instructions at http://commit-digest.org/data/, together we can banish this unknown menace to our statistical integrity. Thanks!
|
|
![[*]](/images/standard/optimise)
![[*]](/images/standard/other)
![[*]](/images/standard/features)
![[*]](/images/standard/bugfixes)
