[Kmymoney-devel] KMyMoney - Sluggish Response

[Thomas Baumgart]

On Wednesday 12 May 2010 01:30:43 aga wrote:
> On Tuesday 11 May 2010 18:56:22 Alvaro Soliverez wrote:
> > On Tue, May 11, 2010 at 2:08 PM, aga <aganderson at ukonline.co.uk> wrote:
> > > Is there a general sluggishness now?  On v1, saving an edited cleared
> > > status happens 'in the blink of an eye', whereas on svn the window
> > > clears for perhaps 1 1/2-2 seconds while it thinks about things. 
> > > Accepting outstanding schedules is accompanied by much screen updates,
> > > and even when saving a transaction there is a noticeable pause.
> > >
> > > I've only seen a mention relating to keyboard use, not of a more
> > > general issue.  Bugs obviously have top priority, and removing KDE3
> > > too, so responsiveness has to take a back seat, but I just wondered
> > > what the thoughts are on this.
> > >
> > > Don't take this as a complaint!  You guys have accomplished a
> > > tremendous amount on very tight, ambitious  schedules, and I'm
> > > extremely impressed.
> >
> > I haven't noticed it being particularly sluggish, but a) I have a x4
> > CPU. b) I haven't used v1.x for several months.
> >
> > If you filter the transactions to only show the last month or so, does
> > it respond better? That might give us a clue on where the problem is.
>
> If I show an account with just a single entry, the noticeable pause still
> occurs.
>
> David mentioned
> " I've also noticed that when
> switching to the institutions screen it appears to get drawn twice, first
> slightly further down the screen to where it should be and then again in
> the correct position."
> This happens also on the redraw of the Ledger screen.  I don't use the
> transaction form, so when the window drops, the line showing New, Delete,
> Edit, etc., disappears during the redraw, then returns.  If I bring up the
> transaction form, it stays visible, but drops, and the two columns showing
> the editable fields compress and shift to the left.  At the very bottom of
> the screen, the word 'Ready' shifts to the right then back.  Don't know if
> any of that helps.
>
> While looking at the Ledger screen operation, a couple of other points show
> up.  The first, and very minor, is that the column widths look odd.  The
> Date column is twice the width of the date, but the actual data is hard to
> the left and slightly clipped on the left, most noticeable on a date like
> '01.04.2010'.

That is due to the fact, that you have turned off the transaction form. The 
column width is calculated to fit the data entry widget which is slightly 
larger in vertical size than on KDE3. Start editing a transaction and you see 
what I mean.

> Something more disconcerting though is the vertical 
> repositioning of a row. I'm looking at an account that occupies about two
> and a half screens in length.  There is no problem with the first screen,
> but if I click the vert. scroll bar then click the cleared column for the
> top transaction, after the redraw, that row now shifts down to the next to
> bottom position.  If this is done for any row on the second page, that row
> drops down to next to bottom. Oh, that's not quite correct. If you click on
> the bottom row 'cleared', that row moves up one.  It seems illogical
> behaviour, but apart from 'loosing' your transaction, if you're not alert,
> and are intending to change from uncleared to reconciled by clicking twice,
> if you're not careful, your second click is on the wrong transaction.

This is one of the things that sure will be optimized when completely based on 
MVC. Right now, the ledger still uses a lot of the 'old' KDE3 logic.  This 
might interfere with things that have been changed in the underlying KDE4 
technology.

> One final, minor thing I've noticed when looking at this issue.  The above
> behaviour is a little like what happens on v1.x when you change the cleared
> status and the row moves because you have cleared status as a parameter for
> sort order.  So I went to compare with v1.3, which doesn't perform this
> way. But, the thing I did notice is that on v1.3, one can adjust the sort
> order by a right click on the column headers, but this doesn't work on svn.
>
> Sorry folks, but you did ask, sort of.

Please keep going. Your comments are exactly what we need.


-- 

Regards

Thomas Baumgart

GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
-------------------------------------------------------------
Cheaper is more expensive -- thb
-------------------------------------------------------------
-------------- 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/20100512/f165e19b/attachment.sig