[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: KSpread bug (was Re: KOffice-1.2 release schedule)
From:       Norbert Andres <nandres () web ! de>
Date:       2002-03-24 13:20:59
[Download RAW message or body]

On Sunday 24 March 2002 14:03, Philipp Müller wrote:
> Am Sonntag, 24. März 2002 13:30 schrieb Norbert Andres:
> > > I was thinking about enhancing cell by pointers "left cell - right cell
> > > - upper cell - lower cell" (additional to the previos cell/next cell).
> > > Don't know if it is feasable, but may do the trick.
> > > Any other ideas for cycling through all _filled_ cells in one
> > > direction?
> >
> > This sounds good to me.
>
> Do you have time for implementing this? I'm still lost within other topics.
I can do it in my vacations, so it will be in the CVS about the 10th of april.
But my problem right now is: how to do it without making the performance when 
loading a document even worse.
I think improving the performance here is much more important.
If I can get KOffice to compile on HP-Ux I could use Rational Quantify to 
check where we lose time. I'll try this after beta.

>
> > > > Another problem is that jumping to KS_rowMAx or KS_colMax increases
> > > > the values you get for activeTable()->rowMax() or
> > > > activeTable()->colMax(), which gets used in other places, too.
> > >
> > > Then we need to fix this anyway. There should be a value to reflect the
> > > last most filled row/column. Currently it only reflects the last "seen"
> > >
> > > || used row.
> >
> > What about adding a last[Used | Filled]Column() and last[Used |
> > Filled]Row() for methods that use colMax() or rowMax() now?
>
> Yes, like I was thinking about it, "fixing" the double interpretation of
> rowMax and columnMax. Maybe there is even a more finegrained usage (think
> of the scrollbars or current visible area).
> This is a hard job, going through the code and checking what the current
> usage of col/rowMax intends to do.
>
> But from a priority, having a possibilty to cycle through the cells by
> direction is much more important (maybe a lot of the current row/colMax can
> be replaced by much more efficient code).
>
> Remark:
> I wouldn't call it last, keep the max in these cases or use bottom/right.
I will implement this during my vacation.

Norbert
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
http://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]