|
KHangman becomes the latest application to migrate to SVG-based scalable interface rendering. KOpenBabel is merged and the beginnings of a 3d navigation system in Kalzium. Work expands in the Umbrello/KPlato Student Mentoring program. Support for the ComicBook Archive and other improvements in okular. Work on Picture, Video and Krita "Flake" shapes in KOffice. Improvements in both the KDE 3.5 and 4.0 versions of Konsole. Language detection in Sonnet continues to mature. Import of concept code demos in Decibel. "Simple-search" user interface work, and support for indexing binary data fields in Strigi. "liveui" moves back into kdelibs. dbmodeler, a database schema modelling application (part of the Season of KDE), is renamed "grama".
|
Jacob Rideout discusses Sonnet, the new language checking framework for KDE 4:
|
The Past (KDE 3.X)
In the KDE 3.X series, KSpell2 was used to check for misspellings. Several plugins were provided for to allow various spellchecking engines to be used. Checking was done in one of two ways, either by checking in the background or via an interactive dialog. The background checking was implanted by checking a word each iteration of the event loop. Words were chosen to be checked by using a simple algorithm that worked for common European languages, but was of limited utility to those languages and scripts with more complexity. For the future, something else was needed...
The Future (KDE 4.X)
For KDE 4.X we've created Sonnet. Sonnet will include those functions provided by KSpell2, but will expand its scope. This includes grammar and style checking and providing the linguistic tools that underline them for application developers.
Standards
The algorithm to segment text into suitable chunks for checking is now based on the recommendation from the Unicode Consortium. The class will be extendable enough to provide special rules to conform to specific orthographic conventions. It has yet to be determined to what extent the end user will be allowed to customize their environment and what rules will be hidden in the implementation.
The language checking engines will be accessed from cross-platform libraries. Spelling engines will be provided by Enchant and grammar checking by Elixir. Enchant has been in use for some time by AbiWord. Elixir is currently being developed with the input of the developers of An Gramadóir, LanguageTool, and the maintainers of the AbiWord port of Link Grammar. The standard interfaces of both Enchant and Elixir will become part of a new Freedesktop.org spec that is being developed concurrently with Elixir. Once the spec is available, OpenOffice.org will consider allowing spec-conforming plugins to be used.
Which Language?
Sonnet will provide a new set of heuristics to determine which language a particular segment of text is written in. Global settings will provide a default list of languages most likely to be used in KDE. Application-specific settings will refine that list. Furthermore, applications can opt for language detection which will attempt to guess the languages in use. A language will be selected on a per paragraph basis. The language will be determined based on a statistical model of the language and its proximity to other languages using the same script. The likelihood of each of match will be weighted by both user settings and the language determined by the previous and next paragraph.
User Interface
The GUI is still under discussion. Work to be done includes crafting the Standard Checking Dialogs & Widgets (dialogs that appear when checking text and which allow you to iterate through errors) and Highlightling (the automatic highlighting of misspelled words, etc. within applications). Any suggestions, especially from usability exports is encouraged.
An early screenshot:
This shows a test app for An Gramadóir. The error is shown in bold. The tooltip has an explanation of the error. The small green box below is part of a WeaverThreadGrid, and shows the thread activity for background language checking.
Philosophy
KDE should support all languages for which users exist. This includes supporting diglossic languages in such countries where this is discouraged. Sonnet will provide additional facilties to assist application developers where such support is not provided by Qt.
Read more about the recent technical progress of Sonnet at http://jrideout.blogspot.com/2006/12/how-is-sonnet-stacking-up.html
|
|
Matt Williams, a new KDE developer, recalls his experiences so far and introduces his new game, KSquares:
|
I'm very much a new face in the KDE development crowd and so first, a message to all you out there who are tentative about jumping in with KDE 4 development.
In many people's eyes, the release of KDE 4 seems a long way off. This is especially true for developers outside the "inner circle" of KDE developers and it seems to only put people off. They seem to think it's too early to develop against and (maybe six months ago) I even heard people recommending that if you were thinking of starting a new application, you were better off using KDE 3 and then porting it much later. This couldn't be farther from the truth.
Before I started work on KSquares, I had no KDE development experience whatsoever. I had two choices; I could follow the (then) recommended path of developing under KDE 3 and then later porting to KDE 4 or I could simply jump in at the deep end with KDE 4. I made the latter choice and haven't regretted it. Admittedly, it can seem like a large hurdle to overcome at the beginning since you need to compile the libraries yourself (which six months ago could be quite an adventure but now is much easier) and the lack of beginner-friendly tutorials (now we have some very lovely tutorials on the new developer wiki) made finding your way around initially confusing. But once I got going, the Qt 4-like API along with the ease of use of CMake and the the helpfulness of everyone on IRC have made it such an easy journey (and in fact, looking at KDE 3 code, I'm glad I never had to deal with automake et cetera).
KSquares itself came about from the desire for the sort of game that I want on my desktop. I don't want a game that takes an hour to play, I need a quick, short, entertaining break from work. Many of you will no doubt know of the game of squares as you have probably played it with a friend while in a meeting or a boring lecture. This is the sort of "take your mind off it" experience which I believe is needed on the desktop and it is games like this that were discussed on the mailing list as being the way that the official KDE Games module is likely to go.
Development was started locally, but since being moved to the KDE SVN server (trunk/playground/games/ksquares), KSquares has accumulated the following features:- 2-4 players (AI or human)
- Virtually any sized board
- Two different levels of AI difficulty
- Scoring independent of board-size
- Colourful theme (slightly customisable)
- Auto zoom of board (for accessibility)
It was at this point in development when I came across a problem. Since all this code is only in SVN (and will remain there, unreleased, until KDE 4.0 is released) I found it very hard to get feedback about my application. This is because the only people who compile it are developers who are busy writing KDE 4 for us all - which is perfectly understandable.
Despite not knowing in whch direction KSqaures should take, I think there are some features which still need to be implemented:- Network play (possibly using GGZ)
- Fully customisable theme, possibly with pictorial icons as well as colours
- Centralised highscore tabling (using libkdegames)
- A gametype where different squares are worth different amounts of points
- Any other fun game types people could suggest.
- Usability review (as the interface _was_ designed by a developer :P)
KSquares is far from alone in the KDE games arena. In the official kde-games department the games have been coming on leaps and bounds with SVN porting across the board making them all look sexier than ever. Check them out and remember, feedback is always appreciated by developers!
|
|
Adriaan de Groot distills and comments on the reasons and purpose behind the three branches of KDE-PIM:
|
kdepim-3.5.5+
This is a feature branch. Fun stuff gets developed and tried out here, like new KPilot stuff (ha!) and HTML templates and UI modifications and whatnot. When something is finished and signed off by [person4_short] and the developer and the KDE 3.5 branch maintainer (also [person4_short]) then things can merge back to the stable branch.
3.5/kdepim
This is the stable release branch. It works towards KDE 3.5.X releases as they show up (like KDE 3.5.6 later this month). It takes bugfixes and completed features when they are approved by maintainers and translators.
pimterprise
This is the ultra stable branch. I made the name up, which is why it's so horrible and there will be a better name before the branch is actually created. This has the 5-years or so of support that the name "ultra stable" deserves. Bug fixes, stability and scaling fixes, only features specifically requested by customers. What happens in this branch - in terms of fixes, not necessarily all of the business features - gets merged back to the stable branch.
|
|
KDE 3.5.6 should be released sometime in the coming week, probably on Tuesday 23rd January. Included in this release are some nice bug fixes and functionality improvements, including the "bullet-aliased password input field" modification. The long-awaited KDevelop 3.4 is also due to officially hit the streets next week - the 3.4 code is ready for release, and is now only awaiting syncing to the download servers.
|
|
![[*]](/images/standard/bugfixes)
![[*]](/images/standard/features)
![[*]](/images/standard/optimise)
![[*]](/images/standard/other)