Bug 512744

Hello,
I have just commented in the other bug you created https://bugs.kde.org/show_bug.cgi?id=512750#c1 that the user interface changes between version 5.13. and 5.2.0 brought the things you mention in the bug.
However, this are no bugs, but software improvement decided by development team.

You say
> The operation input section is not always at the same place, leading to unnecessary mouse movements.

Actually, the transaction input section is always 
a) at the place where my mouse is currently in the ledger (for existing transactions i want to edit).
b) at the bottom of the ledger if i want to enter a new transaction manually.

Are you making a lot of transaction edition and transaction creation at the same time? If yes i can understand you have to scroll up and down a lot. However, it is also necessary when searching for old transaction one wants to edit, regardless of the place where the transaction editor opens, isn't it?

(In reply to surcouf from comment #1)
> Hello,
> I have just commented in the other bug you created
> https://bugs.kde.org/show_bug.cgi?id=512750#c1 that the user interface
> changes between version 5.13. and 5.2.0 brought the things you mention in
> the bug.
> However, this are no bugs, but software improvement decided by development
> team.

     « it's not a bug, it's a feature » ;)

     I understand that it was an intentional and wanted/debated modification.


> You say
> > The operation input section is not always at the same place, leading to unnecessary mouse movements.
> 
> Actually, the transaction input section is always 
> a) at the place where my mouse is currently in the ledger (for existing
> transactions i want to edit).

    Indeed.


> b) at the bottom of the ledger if i want to enter a new transaction manually.

    Well... Not always. As an example, when almost all of the previous Reconcilliation transactions are
    masked, there is no transaction displayed. In this case adding a new transaction is at the top of the
    window. If you have a few non-reconcilled transations, the new transation is displayed around the
    middle of the window.


> Are you making a lot of transaction edition and transaction creation at the
> same time? If yes i can understand you have to scroll up and down a lot.

    Yes. Unfortunately, my wife tend to accumulate bills and give them to me all at once. And some
    time I'm just too lazy to enter them fast enough ;)


> However, it is also necessary when searching for old transaction one wants
> to edit, regardless of the place where the transaction editor opens, isn't
> it?

     Indeed, when editing an old transation, it's a bit easier than before.

     Anyway, overall, I found that, in general, the UX/UI changes in the 5.2 version not as polished as in
     the previous version :
     - colors in dark theme
     - mouse mouvements (hopefully there are keyboard shortcuts ;) )
     - tabbed accounts :(

     Those are all my personal opinions of course. What I would love to is to have a TUI version of KMM ;)

Thomas.

Created attachment 187291 [details]
New transation after all reconcilliations

Created attachment 187292 [details]
New transation after all reconcilliations (adding it)

>     Yes. Unfortunately, my wife tend to accumulate bills and give them to me all at once. And some
>    time I'm just too lazy to enter them fast enough ;)

I solved this by reducing the data sources as much as possible, i.e. :
a) having one current account for the household. The other accounts - if they exist - are savings accounts. (if you have more than one currency, this model must be replicated though...). Advantage: I need to update only one account in KMyMoney, so less work with different banks having different systems and formats.
b) pay as much as possible everything using debit cards associated to the unique current account -> nothing gets forgotten, even the things paid in cash are tracked as withdrawals (which i may split afterwards in KMyMoney if i know what is behind them) from this current account -> no time shift issue (like credit card payment booking at the end of month and needing an extra account to get the proper dates, category, payee).

What about the status of this bug?
Do you want to keep it open? or do you want to set it to "resolved"?

(In reply to surcouf from comment #5)
> >     Yes. Unfortunately, my wife tend to accumulate bills and give them to me all at once. And some
> >    time I'm just too lazy to enter them fast enough ;)
> 
> I solved this by reducing the data sources as much as possible, i.e. :
> a) having one current account for the household. The other accounts - if
> they exist - are savings accounts. (if you have more than one currency, this
> model must be replicated though...). Advantage: I need to update only one
> account in KMyMoney, so less work with different banks having different
> systems and formats.

    Not possible in our case due to several circumstances -_-;

> b) pay as much as possible everything using debit cards associated to the
> unique current account -> nothing gets forgotten,

    Not so sure ;) Card payment bills can be lost (and that happened several
    times). I don't rely on banks account statements because they are way too
    inaccurate (in time) and I want to double-check if withdrawals are "normal"
    or due to malicious intent.

    The only account I do not need paper bills is for an online bank where
    everything goes into the app to keep it up to date... So for this account
    I do not even need KMM.


> What about the status of this bug?
> Do you want to keep it open? or do you want to set it to "resolved"?

    I did report it because I do not like how it has become. However if it's a wanted
    and supported by the development team, you can close it.


Thomas.