|
The Summer of Code for 2007 nears its end. Implementation of more features in the Step physics simulation package. More graphical game themes in KMahjongg, KWin4 KShisen, KGoldRunner and KJumpingCube. The start of a new game, KDiplomacy. More development in the Blitz graphics library. Lyrics Plasma applet and other interface work for Amarok 2. The start of the implementation of panels, and a clipboard engine in Plasma. More features in the ODBC Data Sources KControl module. Animation support in the Raptor menu. KCacheGrind is ported to QGraphicsView. MusicXML import function in KOffice. Ability and an application for viewing statistics in KPixmapCaches. KGraphEditor imported, an application to edit "dot" graphs. A new architecture for KMobileTools. KTrace renamed to Inspektor.
|
Last week, Daniel M. Duley (aka. Mosfet) returned to KDE SVN development. I asked Daniel for a reintroduction and an overview of his work on the Blitz graphics library:
|
How I came back to developing for KDE?
I've actually been back for a while, I just haven't been making much noise because I haven't had anything to release yet. Nonetheless I've been chatting with various developers and coding my own stuff mostly with Qt 4 for quite some time.
How Blitz came about and what does it do?
Since I've been coding on my own for some time one of the things I've been doing is improving the old effects from KDE3.x. These were originally pretty buggy and sloppily coded, (at least the stuff I wrote ;-). So I dumped the old code and reimplemented most things from scratch using Qt 4. Sometimes I kept the same algorithm, often I used new ones, added a sprinkling of MMX here and there. That type of thing.
My original intention was just to use this myself until the new KDE imaging library, Quasar, became available. Then I'd port the good stuff to that. But when it became apparent that Quasar wouldn't be ready until KDE4.1 and the old KDE effects were hopelessly broken I suggested that they use the filters I have been working on in the meantime. That's how Blitz came to be. Once Quasar is available I'll try to make sure it supports all the stuff Blitz does in order to make the transition for KDE4.1 as easy as possible.
Besides being much better coded the improvements in Blitz are numerous and include:
- MMX Smoothscaling and a high quality, filtered smoothscale
- MMX-SSE Grayscale and invert
- MMX-SSE Sobel edge
- MMX-SSE Integer convolve
- MMX-3DNow! Floating point convolve
- MMX-3dNow! Gaussian blur
- Inline HSV and interpolation
- New blurs and sharpens
- Far more efficient methods for things like despeckle, equalize, normalize, etc...
For the methods that existed before in KDE virtually every one has had multiple improvements and should perform visibly better using either the MMX or plain C++ versions. Each has also been thoroughly tested on 8bit, 32bit RGB, 32bit RGBA, and premultiplied images, (I took a vacation day just to do this >:).
Another thing people may not be aware of is just how much Qt has improved in it's graphics handling, especially using a QPainter on a QImage. If you go looking around Qt's source, (src/gui/painting/), you'll find all sorts of very clever MMX/SSE accelerated goodness. For some of the things we used to do manually using scanlines such as blending images, it now makes more sense just to use Qt. They deserve a lot of credit on this.
Anyways, currently I've been back hacking in KDE's SVN, just going through things and fixing some of the old graphics code. For example I just finished a large KIconEffect rewrite that should both perform much better and fix some bugs with the new Qt4. Small stuff, but someone needs to do it before KDE 4 gets released.
Other things I've been working on...
Some of you may remember an application from the old days of KDE called "Pixie". It was meant to be a high performance image manager for people with a ton of images, (several thousand), per folder. Well, I've been working on that and hope to get an initial version out soon.
With excellent image related applications like Digikam, Krita, KolourPaint and Gwenview around some people may wonder why I'm bringing back Pixie, but for me it's mostly a testbed for trying out new technology, user interfaces, and ideas. I occasionally chat with Aurelien Gateau of Gwenview and Boudewijn Rempt of Krita, share ideas about code, etc... so Pixie has been just a way for me to re-familiarize myself with KDE/Qt and experiment with stuff.
On the technology side the most obvious benefit to be gained so far from this is Blitz, (much of which I plan to add to Zack Rusin's Quasar). But I'm also working on different things like a high performance iconview that follows Qt's model/view architecture and other people can use:
Note these are all just early development screenshots of me experimenting with stuff :P
 | | Pixie's high performance icon view. |
I also have been playing with KParts and Pixie is now a KParts host that can load any KDE component into a tab and properly merge it's interface. Konqueror it ain't but this is good practice for me and a way to re-familiarize myself with KDE's internals after being gone for so long.
 | | Pixie using a KParts component. |
On the user interface side I'm taking a cue from the interfaces you see on newer digital satellite and cable television receivers. I've gotten rid of the statusbar and "spinning gear" progress indicator and replaced them with translucent overlays. This is just me experimenting with user interface ideas.
 | | Using overlays to present information. |  | | Even other KDE components use them. |
On a more random note, if you don't make tooltips toplevel windows you can make them translucent without requiring composite and it will work on everyone's machine. The downside: it has to fit into the main window :(
 | | A somewhat ugly tooltip using the mainwindow. |
On an even more random note, with improvements in Qt you can now easily do crazy stuff like have a scaled wallpaper that properly shows through all the widgets on top of it. No this is not going to be how the application actually looks, but it's fun to play with!
 | | Crazy scaled wallpaper stuff :) |  | | I've been using this wallpaper from kde-look.org for testing because the spider is right where the widgets meet :) |
|
|
Jason vanRijn Kasper provides a round up of the progress in the KPilot Summer of Code project, "Enhance KPilot Record-based Syncing":
|
The KPilot Summer of Code project is winding down to a close, with this Monday being the “pencil's down” date. Bertjan Broeksema has done an outstanding job and has accomplished all that we said we wanted to on our Summer of Code proposal. The problem that we faced in KPilot was that each of our conduits did a lot of things in common, but all of them had their own code for doing these things. This has made maintenance a much harder job than it should be, and has led to some conduits being less feature-complete than they should be - not to mention having too many bugs from the duplicate code.
So the idea was that each of our record-based conduits should be doing the same sorts of things as far as algorithm, process, and flow, and that we should pull as much of this common code out of the conduits (and into some base classes) as possible. This leaves our conduits to be responsible mainly for data transformation (turning a PC calendar VCal record into something that can be synchronized with a Palm database record), and should address the problems listed above.
But while we were at it (and while we were taking the time to think through and design how KPilot should work), we also put as much effort into making it as hard as possible for our conduits to destroy our user's data. It's something that needs to be carefully included in the design process, since it simply doesn't happen by accident (not destroying data during edge cases, etc.). So we made some intentional design decisions that should hopefully result in fewer "KPilot ate my future" e-mails.
We officially had 3 main goals for our Summer of Code project:
 1. Sequence Diagrams and Class Diagrams
We used a loose interpretation of the Rational Unified Process for our project this year. We spent 5 weeks at the beginning of the project, creating the Use Case for our upcoming work, and then laying down some Class and Sequence diagrams which showed how all of the requirements and flows from our Use Case would be realized. We used BOUML for our UML diagrams (I'd have rather used Umbrello, but Bertjan had some difficulties in getting it working on his Gentoo box). All in all, though, I believe we found a good balance between spending enough time to make sure we had a well-thought-out design and having enough time to implement it all.
2. Implementation of the abstract record framework
Since our Use Case focused almost entirely on the functionality required for all of our conduits, Bertjan was able to fairly quickly write the code for the base conduit classes. We found very few design challenges and misses during the code-writing phase, which I credit largely to the thorough work we did on our Use Case and UML models. It goes against the typical Open Source Hacker mindset to spend so much time preparing to code and not actually coding (I mean, coding is the fun part, right?). But Bertjan patiently worked with me through this phase and I think we have some really good quality code as a result. Bertjan also wrote a series of unit tests to help verify his code in the base classes.
 3. Implementation of a new conduit as proof of concept.
Early on, we weren't sure which route to go - whether we should try to port one of our existing conduits to the new base classes or whether we should just create a new conduit. As it turns out, we did our SoC work in trunk/, which means we didn't have a very stable code base (we're still working on getting KPilot stable in trunk/) to start from. So we decided to create a new conduit to use as an implementation for our new base classes rather than struggle with porting code and also trying to fit it into the new base system. I've been wanting to have a way to sync with the Keyring Palm application (encrypted, multi-purpose Palm database for storing passwords, account numbers, etc.) for a long time now, so we decided to create a new conduit in trunk to test and verify the new base classes. We're just finishing up a few minor nits with it and hope to have it fully functional by EOD, Monday.
So, to summarize, thanks to this year's Google Summer of Code KPilot project, we now have a solid base conduit framework that is implemented in a new Keyring conduit. Our next steps in the KPilot team are:
- stabilize the daemon and user-visible portions of KPilot
- finish porting the old conduits over to the new KDE4 APIs
- port the old/existing conduits over to our new base record framework
- stabilize, test, wash, rinse, repeat
- look at OpenSync framework again and (now that we have a common conduit framework in KPilot) see if we can leverage OpenSync's libraries for the underlying syncing algorithms.
|
|
Inge Wallin writes an update on the new features (including Summer of Code projects) in Marble (illustrated by screencasts by Andrew Manson):
|
For some reason, Marble has become a poster boy for the new generation of KDE applications. It's graphic, it's beautiful, fast, and uses Qt4 to it's full potential. It has also managed to gather a sizable development team in almost no time. An interesting thing with Marble is that it exists in two incarnations: one as a KDE application in the KDE-Edu module, and one as a Qt-only version. So to keep up with a good tradition, here are the latest developments.
Two days ago, this Friday, we released version 0.4. Among the new features from last version is a KDE version, configurable legend, improved performance, new map types, better data sets, support for downloading tiles on the fly, and more. See the release announcement above for the full details.
Personally I think that the most interesting "feature" is the improved datasets. For instance we got a new set of satelite images with a resolution of 500m/pixel. Obviously, this is not as good as Google Earth, but it's good enough to make a very impressive map. Since Marble is tile based, and all of this data would make the KDE-Edu module far too large, the tiles with the highest resolutions are stored on a server and downloaded when needed. This will make much demand on the servers when KDE 4 is finally released and millions of users start using this feature. There is an active discussion within KDE on how to solve it.
During the development of 0.4, we managed to attract help from outside KDE. This has lead to support for both MacOS X and Windows.
Even with this impressive list of new features, most of the latest developments within Marble are missing in this release. I am talking about the projects of the Summer of Code students. They are basically ready, but disabled in 0.4. Marble had 3 students, and the next week will mean integration and enabling of all the projects: Flat projection, GPS support and support for Google Earth KML files.
Andrew Manson, GPS programmer writes:
"The GPS GSoC project was to implement GPS device support and GPX file reading and writing. GPX files contain important GPS data such as:
- Trackpoints, which are generally generated by the GPS device as a form of tracing where you have been;
- Waypoints, which are user-defined points of interest, and
- Routes, which contain a series of waypoints that represent a directional path.
The GPX file view is a very simple interface to deal with open GPX files and can be enabled by running marble with the --enableFileView command line argument. GPS tracking is provided by the gpsd project and can be enabled by compiling Marble on a Linux system that has libgps (provided by installing gpsd) installed and running marble with the --enableCurrentLocation command-line argument."
Most of these features will of course be enabled by default after the project is fully integrated.
The second project, support for Flat Projection, was done by Carlos Licea.
Carlos writes:
"The flat projection project has evolved very well, although not as fast, to a point in which it's almost usable now. We have finished almost everything the spherical projection has: texture, place-marks, vectors, distance measures, you name it :).
As usual some task were relatively easy while others were hard, and yet others that 90% of the task was just wrote in one go while the remaining 10% was harder or in some way complex, so that I actually had to think throughly about it.
Just to give a small example: have you ever stopped to think about how Asia crosses the dateline so that mostly of the continent is on one side of the Earth and the rest in the other? Well, I had never before, but now I had to do some voodoo magic and tricks so that the small bit of land that is on the other side of the map gets displayed correctly (for those curious I had to separate the polygon).
So in conclusion, there are a few glitches that need to be solved before this projection it's actually usable but, hey, Marble team is really fast, so it will not take too much time before you can pick "Flat projection" instead of a Spherical Projection".
Finally, support for the standard KML (Keyhole Markup Language) format used by many applications such as Google Maps was done by Murad Tagirov of Belarus.
We were not able to reach him for a comment, but his project is also being integrated right now without too much trouble.
|
|
An interview with Carlos Licea, the student working on the "Flat (2d) Projection in Marble" Summer of Code project, can be read here.
|
As you might have read last week, the author of Kalzium, Carsten Niehaus, removed a couple of features which have been in KDE 3 version of Kalzium but didn't make it into KDE 4.0. The reason is that Carsten doesn't have enough time right now for Kalzium to fix all remaining issues.
This is a call for interested coders to help Carsten maintain Kalzium. If you are interested in improving Kalzium by porting remaining features or adding new one contact the Kalzium mailing list. Thanks.
|
|
![[*]](/images/standard/features)
![[*]](/images/standard/other)
![[*]](/images/standard/optimise)
![[*]](/images/standard/bugfixes)