[Kmymoney-devel] Some planning for the next release
fvilas at iname.com
Fri Feb 5 15:17:16 CET 2010
On Friday 05 February 2010 06:41:32 Alvaro Soliverez wrote:
> Hello all,
> while we try to iron out the remaining bugs, I'd like to start talking
> about some of the activities for the next release.
> I think we are in a pretty good shape, though we have room for
> improvement here and there, but I don't think we are doing a bad job
> when it comes to mimic the features present in the KDE3 release.
> That's why I'd like to start preparing the code for KDE4 greatness. A
> full port to MVC widgets is part of that, but that will be done over
> time. Cristian has an idea about how to handle models, which could
> improve performance and improve the tidiness of the code. He can tell
> you more about that, since part of that might be done during the next
> I want to focus my work on making it easier to integrate with other
> apps. As part of that, some code has to be taken out of kmymoney.cpp
> and into some deeper class.
> There are several reasons for this:
> - The logic has to be split from the GUI elements. When trying to
> write an engine for Akonadi, this has proven to be a problem.
> - Kmymoney.cpp is upwards from 6000+ LOC and growing, way beyond what
> is manageable.
> - The code for loading and saving the file is in there. As it is
> attached to GUI code, it can't be unit tested, which has been a major
> pain in the past and will be again in the future, for sure.
> - Other applications can't easily use kmymoney libs unless they
> rewrite the loading/saving code
> If this is done, at least for the major methods, it should be done
> during the next release or wait until after stable release, because it
> has to be well tested.
If this can be done in small increments, I'm fine with having it in the next
release. Otherwise, I vote for waiting until after the stable release.
After stable release, I want to attempt to remove the dependency on CPPUNIT
and use Qt for the unit tests. This provides the advantage of being able to
unit test gui classes by simulating button clicks, etc. so the event handlers
get called in context. It is also something that touches too many files when we
are in beta and trying squash bugs before a stable release.
I'm also still working the db speed issue by consolidating some calls to
reduce round trips. I'm trying to make sure that it is also very stable before
I commit, otherwise that patch will also wait until after stable release. This
is something small enough that it may be able to go in another minor release
> Another one is of motivation. I do not want to spend the next 4 months
> porting Q3TextEdit to KTextEdit widgets. It would feel good to know we
> are preparing KMM to make the best of KDE4, and the other way around
> through integration with dataengines, Akonadi, etc.
> We also have to review the documentation and update at least the
> version numbers for it.
> Are there any other major undertakings you see for the next release?
> It will be a quick cycle, like this one. Start on Feb 15th and end on
> March 31st, with a string-freeze from March 16th onwards.
> If things go ok, the next release will be a Release Candidate. Keep
> your fingers crossed! :)
For the next minor release, I agree. It will be nice to have a KDE4 version
released, with feature parity to the KDE3 version.
fvilas at iname.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20100205/75727aba/attachment.sig
More information about the KMyMoney-devel