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

List:       koffice-devel
Subject:    Re: kspread: non-contiguous selection
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-12-16 8:47:13
Message-ID: 492258b10512160047y6ace23f5h54a30ec9f3d19022 () mail ! gmail ! com
[Download RAW message or body]

Hmm I don't read mails for a couple of days and look what I miss :-/

I haven't seen the implementation if this thingie yet, but sounds nice
that someone went to implement it :) It was one of the things on my
TODO list, together with the whole manipulators concept, which would
basically be built on top of this, assuming it's written in the way
that I hoped that it would be.

What all is currently implemented and what is not ? There are many
features that operate over ranges - all the formatting and whatnot - I
hear here that this is not in yet - hence, what is in ? Just the basic
ability to select the cells ? Or also some operations over it ? What
about cut/copy/paste ? Delete ? Zillions of other things that come to
mind ? All of these will have to be manipulators, if I'm not mistaken
- or something very similar.

I will have a look at the code, assuming that I manage to persuade SVN
that I want it - branching in svn still kinda goes a bit beyond me :(

/ Tomas


On 12/14/05, Stefan Nikolaus <stefan.nikolaus@kdemail.net> wrote:
> Hi Robert,
>
> On Wednesday, 14. December 2005 00:14, Robert Knight wrote:
> > Hi Stefan,
> >
> > Is much work required to make formatting work on non-contiguous
> > selections?  (Borders, Fonts, Backgrounds etc.)  That doesn't seem to
> > be there at the moment.
>
> Well, yes, it is some work to do, but nothing spectacular. We have to adjust
> the iteration over the selection. Maybe by implementing the proposed
> Manipulators (DESIGN.html) or extending the already existing CellWorkers.
> Then adjust the UndoActions to work on Regions instead of QRects. And we're
> mostly done, except the always occuring refinements, which are hard to
> forsee.
> What about your HighlightRange efforts? I see some overlapping here. Maybe we
> can bind our forces together.
> In the longer run, I would like to see the Region class used in more cases,
> e.g. the new format storage or a region, that represents the occupied cells
> to achieve the "Select all" functionality. If possible, it should replace all
> the occurences of Point and Range to have one class, that represents a
> "region".
> Wether the Cluster is more efficient than the Region, memory-, runtime- or
> maintenance-wise, I haven't determined yet. I think, the latter point goes to
> Region. ;) Any opinions on that topic are welcome.
>
> Bye,
> Stefan
>
>
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
>
>
>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]