[Kmymoney-devel] toughts about porting the widgets to the qt model/view framework

Thomas Baumgart thb at net-bembel.de
Thu Dec 3 08:57:03 CET 2009


On Wednesday 02 December 2009 22:20:37 Cristian Oneţ wrote:
> Hi,
>
> Since I'm really bothered by this small annoyance:
> "After the payee completer depletes all possible completions when typing a
> payee's name the typed text is selected so if the user continues to type
> all characters entered so far are lost"
> I began to think about the possible solutions to fix this. I came up with
> the following two possibilities:
> 1. Find the smallest fix
> 2. Look at rewriting the widgets base on what we have now in KDE and Qt
>
> I'm sure that option nr. 1 would be the most straight forward but, to be
> honest, I'm to tired of debugging the KMyMoneyCombo code. So let's assume
> that one would start writing model/view based widgets as replacements to
> the current widgets. The question is how would this work be integrated into
> KMyMoney?

This is the mid/long term plan anyway.

> We have reached a pretty stable state with a release scheduled in a month
> so we would not want to blow that by starting to mess with the widgets :).
> This means that we should be able to work on the new widgets but in the
> same time keep the old ones (and maybe fix them). We could do this in two
> ways: 1. Develop the new widgets in a separate branch of the source code 2.
> #ifdef with a CMake option between the new and the old code
>
> The thing I don't know about option 1 is how can we do it in the KDE
> repository. Other than that it would be the cleanest way. 

You can simply open a branch for KMyMoney and call it 'newwidgets' or 
whatever.

> The second 
> solution is a bit ugly, maybe harder to maintain, but it has the advantage
> that we have the widgets side by side. Developers working on this part
> could compile the project with USE_MV_WIDGETS on. Once the MV
> implementation is completed and tested we can easily remove the old code.
>
> I've attached a patch containing a start using the second approach. What
> are your thoughts? Would it be feasible to work this way?

It might work. As you already mentioned it is a bit ugly. But is has the 
advantage that we all see the changes and can contribute to them.

Another option would be to open a separate subdirectory that contains the new 
widgets. Just an idea I had in the past.

> In the example the KMyMoneyPayeeCombo is written on the MV framework. It
> does not have all the features yet but the completion works like a charm
> and it's a lot less code than the old widget which uses the completer and
> the selector.

Please make sure, that the 'new' widgets do not require any specific KMyMoney 
object(s). I know this might be tricky in some cases (like KMyMoneyEdit which 
currently uses MyMoneyMoney) but we need to get rid of them. This will allow 
us to maintain a single shared lib to be used by the application, plugins and 
the Qt Designer.

-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
If it's there and you can see it, it's real.
If it's there and you can't see it, it's transparent.
If it's not there and you can see it, it's virtual.
If it's not there and you can't see it, it's gone.
-------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kmymoney-devel/attachments/20091203/23a77c2c/attachment.sig 


More information about the KMyMoney-devel mailing list