|
| This Week... |
|
Interface experiments in Amarok 2.0, with the aKode engine shown the door. Initial work on incremental parsing functionality in KDevelop. Further functional development in the Step educational physics simulation package. More refinement of the Oxygen-themed KDE Games artwork, revised sounds in the Oxygen sound theme and more work done on the Oxygen widget style. The Oxygen iconset is dual-licenced as Creative Commons and LGPL. Support for the Plucker document format in okular. Zoom work (ViewBar) and Coverity fixes in KOffice. Basic Phishing protection and the start of user documentation in Mailody. Optimisations in KJS (JavaScript interpreter) and KSysGuard. Import of Athec into playground/games and KBackup to playground/utils in KDE SVN. First NEPOMUK-based GUI elements appear. KSplashX displaces KSplashML as the splash screen engine for KDE 4.
|
John Tapsell talks about recent work in KSysGuard, and its integration in the wider desktop:
|
KSysGuard has been moving towards a more modular approach, so that the Process List, various graphs, etc. are true Qt widgets that can be used in any application.
The migration of the Process List is almost complete now, as you can see from the screenshot.
This will be added to a dialog box in the new Plasma KRunner. KRunner will always be loaded in the background and provides a few lightweight 'programs' that require near-zero start up effort and resources, such as the Run dialog and this new Task List dialog.
The main focus for KSysGuard at the moment has been making it as fast and as lightweight as possible, as well as being easier to use and more user friendly (like the reduction of the number of columns in the default view: no more VmSize (column is hidden by default), VmRSS no longer exists, replaced with much more informative "Memory" and "Shared Memory" display).
|
|
Jos van den Oever provides an overview of the recent move of Strigi into kdelibs and its implications for the wider desktop porting effort:
|
Monday was a red day for the KDE build dashboard. This was the day that KFilePlugin was removed from kdelibs. In fact, dashboard is still mostly red because of this move. The KFilePlugin class has been a great success in KDE3 and there are many implementations of it. So it is no wonder that removing it causes many problems.
KFilePlugin has been removed to be split up into reading and writing plugins. The writing plugins are very similar to what we have now, but the read plugins are radically different and this is where KDE4 will see an enhancement and speed up of the extraction of metadata.
The exposure of the strigi API to the KDE developers this week led to cleaner code, better win32 support and the implementation of many wishes for making it easier to write analyzers.
Since the tutorial on writing analyzers and the list of plugins to be ported were put online, many porting efforts were started. Some plugins will be ported when nice analyzer interfaces are ready. Two of these are planned (in addition to StreamEndAnalyzer and StreamThroughAnalyzer):- StreamSaxAnalyzer will let the analyzer react to SAX events that occur while parsing a file. XML is used for many file formats these days and this will save a lot of duplicated work. The StreamSaxAnalyzers will all be called from a StreamThroughAnalyzer which means that you can run multiple analyses in parallel. This is useful for mixed formats such as RDF embedded in HTML.
- StreamLineAnalyzer will let the analyzer react to each line that is read in a text file. The line will be reported as UTF-8, regardless of the encoding of original stream. This saves the analyzer implementor many headaches.
The StreamSaxAnalyzer is easy to implement and it will be added this week. The StreamLineAnalyzer will come a bit later, because it is a bit trickier to write.
About eight KFilePlugins allow writing of data to a file. This is something Strigi cannot handle and this functionality will go into a new KService, KFileWritePlugin. The first of these can be found in kdegraphics: kfilewrite_jpeg.cpp.
All in all the red color of dashboard should fade in the next week or two. I hope many more will help make this happen and would like to thank all the brave developers that already dove in and committed ported analyzers.
|
|
Casper Boemann discusses the development of Zoom tools in KOffice:
|
We have recently ported the Zoom tool from Krita to KOffice-wide usage. The Zoom tool and the ViewBar are two different ways of controlling the zoom level when viewing documents.
The ViewBar is located to the right of the statusbar and its slider to control the zoom is very nice. As Cyrille Berger said the other day, "I really miss it in KOffice 1.6!". If developers of other document viewing apps read this, please contact me so we can determine how to spread the ViewBar to the rest of KDE.
The Zoom tool (which is an old favorite from Krita and other drawing apps) is now ported to all KOffice applications.
We faced some problems to get the two functions to work together nicely, so we had to refactor that part of Flake (develop some extra classes and modified their responsibilities).
|
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
|
|
|
|
|
|
Development Tools |
|
|
|
|
|
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
|
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
|
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
|
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
|
|
|
|
|
|
Features |
|
Development Tools |
|
Hamish Rodda committed changes in /trunk/KDE/kdevelop/languages/cpp:
|
Start laying foundations for incremental parsing
Tried to re-enable the DUChain viewer, but alas it doesn't show up
Problem at the moment is that the background parser isn't being triggered with changes to text; and I really need the document controller back, too... |
|
|
|
|
|
|
Kris Wong committed changes in /branches/kdevelop/3.4:
|
|
Updated the switch header/implementation functionality to search through the code model hierarchy starting with the global namespace rather than iterating through the project files. |
|
| | | |