|
Some new wallpapers and an Oxygen mouse cursor theme are imported into KDE SVN for the KDE 4.1 release. The KDM login manager gets an Oxygen facelift. Preliminary version of a basic web browser Plasmoid, and a new "ScriptedImage" Plasma applet. Support for storing Amarok 2.0 statistics in NEPOMUK, more work on the new scripting interface, preliminary support for iPod's, and a partially-working "random mode" restored to Amarok 2.0. The "PopupDropper" interface element of Amarok 2.0 is imported into KDE SVN for future development. Expansion of the D-Bus interface and stats collection functionality of KTorrent. Alignment support in KJots. The irritating bell sound is disabled by default in Konsole. Kexi driver for the xBase family of databases is almost complete. KStars receives a INDI Astrophysics driver, and tweaks to its zooming user interface. Work on the "Leitner box" mode in Parley. The start of a "SnaKe" mode in the newly-revitalised KTron. Work on a KIO-based network implementation in the experimental WebKit integration into KDE. An early implementation of storing Decibel contact data in Akonadi. Many KDE applications will now automatically restart after a crash.
|
Girish Ramakrishnan discusses his work on improving ODF support in the flagship application of KOffice, KWord:
|
I have been working on improving ODF support in KWord for the last 2-3 months. My work is sponsored by NLnet and they have been very liberal with the project goals - all they want is kick-ass ODF support in KWord 2.0 and I need to do whatever it takes to make that happen. I have been working on all parts of KWord ODF - loading, saving, editing documents, the user interface etc.
The first task was to get things to load - for this I have automated the OpenDocument Format Alliance test suite. We have around 62 tests up and running - these involve character, paragraph, lists, headers. Support for tables has been left out for KWord 2.0 since tables are a complex beast. Currently, these tests only check the internal data structure that result in loading and not the visuals of the loaded document. Though, comparing the visuals is in theory very possible, it just requires a stable KWord.
We have now made the 62 loading tests also test the saving process. When I first started, saving of ODF was in a pretty poor state. I am happy to say ODF documents with simple paragraphs and text save flawlessly now!
One of the strategies we followed with writing tests is to test a feature completely (manually) before automating it. If need be, we would add features and fix bugs on the way. Though the task of writing automated tests seems boring, what it actually involves is a thorough understanding of the code and the specification. We also do fixes to the UI as needed.
On a technical note, the design of ODF in KWord is simply super. The big problem is since there were no tests at all, it was impossible to tell what you are breaking. Indeed, when I look into the first few commits I made, it was just total crap :). I believe the tests we have now will go a long way in helping new comers (like me).
What next? In the immediate future, I am now working on lists+headers loading and saving. Lists and headers in ODF are similar but complex beasts. We are hoping to make it before KOffice 2.0 (middle of September).
Problems? Lots. Though ODF support is now in an OK state, we have the bigger task of beefing up KWord itself. Many fundamental features need to be completed. Thomas Zander's style manager is one of the basic missing components that we need immediately. The cursor in KWord doesn't even blink! So, there is *lots* of stuff to work on, but too few hands. KWord itself is worked on only by a couple of major contributors and almost every part of KWord requires some love and attention. So, if you are interested, just drop by irc.freenode.net, #koffice!
|
|
Kelvie Wong introduces Basket, and its current state of development:
|
I'm Kelvie Wong, and I've recently taken up the maintenance and porting of Basket
For those that do not already know, Basket is a rather advanced note taking program. It comes with the slogan "Taking care of your ideas", which says a lot about its philosophy and the intended use for this program. As far as I am concerned, it is the best note taking program I have found on Linux (and in the future, perhaps all platforms? :)). Either way, the author of the program, Sébastien Laoût, had other matters to attend to, and could not find the time to continue this project; it was too sad to see such a project die, so I stepped in, and started porting the thing to KDE 4. Since then, I have taken up porting and maintaining Basket. Sébastien still pops by now and again to share his insights and experiences, though.
Right now, we are at a point where we have finally (after a fair amount of pain, but a fair amount of help :)) gotten a compiled version up and running under KDE 4. I have been informed by Peter Zhou (who is working on Amarok) that it also compiles and runs on OS X straight up. I think Windows will need a bit of tweaking though (I do know a few instances where we still rely on unistd.h...) but here's a few screenshots of the current master branch:
 |  |  | | Note: in the second image above, this is a screenshot of Plasmoids in the Basket window, not native Plasmoids! |
My #1 priority is to have a minimal regression, straight port into KDE 4, with all of the basic functionality. I think Basket is almost at a point where I can finally start to actually use it to start using it to store and edit all of my notes (although I'd advise against any non-developers to do the same; there are still *many* showstopping bugs, but I will squash the main ones as soon as I can; I also do not want to be liable for the loss of your entire album of baby pictures you only keep one copy of in Basket :)).
Reading over our mailing lists archives, wiki, and usability surveys, it seems that there was quite a bit of ideas that were being planned for the future, and there was even a complete rewrite that had been worked on, but that eventually fizzled out, and with the lack of momentum, it had come to a standstill. What I had in mind was to at least get Basket running in Qt/KDE 4 before completely breaking it apart and refactoring it. Some of the code is a mess, but ultimately, I think that we will be taking much less of a risk by porting / refactoring rather than doing a complete rewrite. All the cool ideas that everyone has can be implemented parallel to this (such as QGraphicsView and Akonadi support, as well as Server/Client support). After this port, there is so much we can leverage and do thanks to the new KDE framework. It also makes it a lot easier to maintain as I am far more familiar with KDE/Qt 4 than I am with 3.
One day, I would like BasKet to be integrated with the KDE system; I think it will have to happen after the KDE guys switch to some type of distributed source control management tool, though. Right now, Basket is hosted in Git(Hub), and it is hard to go back to centralised version control the same way after you have been spoiled with the workflows they permit, especially for (but not limited to!) open source work.
Anyways, there is a fair amount more work to do, the potential for this program is endless. If anyone is interested in helping out, drop me a line on the development mailing lists, or just straight up clone the repository and start hacking (includes all branches, including the KDE 3 ones) and sending in the patches:
git clone git://github.com/kelvie/basket.git
|
|
A fellow Dot editor earlier essentially asked me why i'm not busy kicking ass over the comments on the previous Digest - if you are reading this, you know what I was more busy doing.
While I would prefer that the discussion would be related to actual KDE development (and it's certainly disappointing to see most of the comments be about the "lateness" of the recent Digests), seeing the complaining camp battled by the defenders brought a strange smile to my face.
It's a fine line, but at least I know I have passionate readers, and that could never make me unhappy...
p.s. This doesn't excuse the comments, and I don't want this to be a regular outcome: the Digest will catch up in the near future. Seriously.
|
|
![[*]](/images/standard/features.png)
![[*]](/images/standard/optimise.png)
![[*]](/images/standard/other.png)
![[*]](/images/standard/bugfixes.png)