|
| This Week... |
|
Support for alternate direction layouts (vertical, horizontal) in Kickoff. Improvements in the Device Notifier applet, with support for window icons in the Pager Plasmoid in Plasma, with the "Trash" applet moving into kdebase, the "Luna" applet moving to extragear, and the "Contacts" and "Converter" runners moving into kdereview. Support for online play (using the GGZ network) in the KSquares game. A new default theme for the KSame game. More maintenance work in Kooka. Better interaction between Okular and the KDE text-to-speech system. Full support for colour schemes in the interface of Digikam. Lots of old bugs fixed in the mimetype configuration dialog of Konqueror. Continued work and optimisations in KHTML. The start of the ability to extend GUI's with scripting actions using Kross. KRatingPainter becomes a global way to manipulate ratings throughout KDE. A "Konsole" mode and "Web Interface" are added to KTimeTracker. Long-awaited support for inserting signatures at the top of email replies in KMail. The ability to store all attachments in a specified directory, and a status bar are added to Mailody. KOrganizer gets a new "Month" view. More work on the "online reader" syncronization project in Akregaror. Work on general Zeroconf support in KDE, and particularly in KRDC. Continued porting of Kommander to KDE 4. The start of moves to make Phonon the only output engine in Amarok 2.
|
Rivo Laks introduces KGLLib:
|
KGLLib is an object-oriented OpenGL library built on top of Qt. The main features of KGLLib include ease-of-use, extensibility, and a clean API. The main purpose of KGLLib is to make it easier to develop OpenGL applications for Qt and KDE, and to add OpenGL support to existing applications.
Qt includes its own OpenGL module, so why is KGLLib better? Qt's module is quite limited, as it only provides very basic things. It also doesn't have an object-oriented design, for example there is no "Texture" class which would make some operations easier. Instead, you will need to use OpenGL texture ID's.
KGLLib is divided into two big parts: "core" and "extras". Core includes classes which are useful to a wide range of applications. Examples of this include Texture and Program classes. Core classes are also more stable and complete, having already reached some level of maturity. Extras, on the other hand, also includes parts which are interesting only to a few applications or which are still under heavy development, and therefore we cannot guarantee future binary or source compatibility.
KGLLib is built with extensibility in mind. The existing classes should provide building blocks on top of which additional (sometimes application-dependent) functionality can be developed. Those extended parts could then be contributed back into the KGLLib extras library, so that it could be used by other interested parties. KGLLib depends on Qt, Eigen and GLEW. Probably all the readers already know what Qt is! Eigen is an excellent lightweight library for vector and matrix math, already used in quite a few KDE projects. GLEW is an OpenGL extension library, taking care of initializing OpenGL extensions and function pointers. Together they form a good basis for any OpenGL application.
KGLLib lives in KDE SVN at /trunk/playground/libs/kgllib/. It also has some examples to demonstrate how to use the API to build smaller OpenGL applications. For now, the API documentation for KGLLib can be found at http://freehackers.org/~rivo/kgllib/html/. I'm hoping that KGLLib will become a standard for KDE OpenGL applications. KWin will probably start using it instead of its own little internal OpenGL library. KGLLib is also using some code from the Avogadro project, and it is possible that they'll start using KGLLib after it matures some more.
As a sidenote, I'm looking for a *Cool* name for KGLLib, so if you've got a candidate, let me know!
|
|
Didier Hoarau and Frank Osterfeld talk about a project to add online reader syncronization support to Akregator:
|
With the help of Frank Osterfeld, I'm working on a online reader synchronization module for Akregator. The goal is to synchronize Akregator with online readers such as Google Reader. RSS aggregators are great, but if someone uses different aggregators at home and at the office for example, he might have a hard time to synchronize them manually. As a consequence some people might prefer to use only one (probably "online") reader. That's why (in my opinion) a nice feature for a desktop reader is to make the synchronization easy (between both types of clients).
At first, we would only deal with the list of subscriptions: adding the new feeds, updating the existing feeds (the name and the category for example) and removing (optionally) the feeds that are not in the source. But in the future, it would be interesting to mark the articles as read or at least to mark an article as important if it is present in the other reader. We began the work with Google Reader because the Google API is really simple, but it would be obviously be nice to deal with other readers.
At mid-term, something like this should be based on Akonadi, but as a version of Akregator based on Akonadi won't be released before KDE-PIM 4.2, a simple synchronization of the feed list (as opposed to a full sync, including items/item states) could be implemented on the current codebase and would already be available for KDE 4.1.
From a technical perspective, there is not a lot to deal with. All aggregators include more or less the same set of features. There can be some differences in the vocabulary (for example Google calls "starred" something others would call "important") but that's not a problem. The main difference we have seen so far is the feed hierachy: for example Google uses labels and Akregator uses folders. That's a difference but in such cases the only thing that we need is to agree on a simple mapping rule between both systems.
|
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
|
|
|
|
|
Development Tools |
|
![[*]](/images/standard/features) |
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
![[*]](/images/standard/bugfixes) |
|
![[*]](/images/standard/optimise) |
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
|
|
KDE-Base |
|
David Faure committed changes in /trunk/KDE/kdelibs/kdecore:
|
I keep hitting KConfig bugs while trying to implement filetypes stuff...
This time: do create the parent directory if necessary. Seems canonicalPath returns empty for a non-existing dir. |
|
|
|
|
|
|
Kévin Ottens committed changes in /trunk/KDE/kdelibs/kfile:
|
React to folder being empty or not when the bookmark icon has a "-full" version.
This allows to react to the trash state for instance. |
|
|
|
|
|
|
KDE-PIM |
|
Thomas McGuire committed changes in /trunk/KDE/kdepim:
|
Fix the "clean spaces" function in KMail and also fix changing identities - now the signature is properly changed, even if it is a HTML signature.
Changes to KMeditor:
- Add new functions: cleanWhitespace() and replaceSignature(...) + helper functions for those
- Remove some unused virtual functions
- Remove a unused variable
- Small style fixes
- Rename parent to q, as this is the standard
- Small fixes for insertSignature
Changes to KMail:
- Use the new functions of KMeditor and remove own implementations
Changes to KNode
- Follow KMeditor change
Still TODO:
- Move the HTML mode mess completely into KMeditor instead of having 3 different implementations in KMeditor, KMComposeWin and KMCompoerEditor
- Fix the highlighter |
|
|
|
|
|
|
Volker Krause committed a change to /trunk/KDE/kdepimlibs/kioslave/sieve/sieve.cpp:
|
Waiting for the server response might be a good idea instead of just assuming the operation faild if the server is too slow.
Now sieve actually works (and thus also the out-of-office reply stuff).
I'm wondering though why this isn't a problem in 3.5, the code is exactly the same there... |
|
|
|
|
|
|
|
