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

[Alvaro Soliverez]

On Thu, Dec 3, 2009 at 4:57 AM, Thomas Baumgart <thb at net-bembel.de> wrote:
> 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.

I agree, this is the plan anyway. It is stable enough, and I think the
only thing holding us is the beta release.
>
>> 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.
>
With SVN you should be able to open a branch, but I don't what are our
effective permissions on this particular SVN.


>> 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.
>

About all this, I'm just wondering whether it can wait a little. You
could have your own branch for these 3 weeks (I'm going to be away for
a while, and so is Thomas) and then merge it inmediately after the
release.
So, perhaps we are overcomplicating for something that's going to be
very short in time.

>> 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.
>
>
We'll have to work around all the validations. That's going to take
some work. :)

Regards,
Alvaro