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

List:       koffice-devel
Subject:    Re: [kspread] formatting design
From:       Norbert Andres <nandres () web ! de>
Date:       2002-12-15 9:10:57
[Download RAW message or body]

On Sunday 15 December 2002 03:53, John Dailey wrote:
> > Ok, if you selected all possible cell and change their borders, thousands
> > of cell objects would be created. That's the reason, why we don't have
> > something like a "Select All" menu entry.
>
> In this case, no, there would be a BorderLayout object for the sheet set
> with the new border, and you simply have to remove any existing
> BorderLayout references in existing cells.  No new cells are created.
Sure, they are! Because in the beginning every cell references the default 
cell. If you select something and change an attribute, we create new cells 
and assign the attributes to it. This has nothing to do with the BorderLayout 
object.


>
> > You can even use a sheet layout for it, because all the individual
> > attributes should stay, just the border attribute changes.
>
> Which is why we break apart into different types of Format objects -- like
> a BorderFormat, FontFormat, BackgroundFormat, etc.  What I named a 'style'
> is a complete set of format objects that encompass all configurable
> layout/format options.  If a cell's style is missing certain format
> objects, then it uses the default from the column or row's style, and if
> missing there, uses the sheet style, and if missing there, uses the
> document style which has all the 'default' settings.  This would be how
> 'fallbacks' work.
>
> > Or what if a user uses "Select All" to select really every cell and
> > deselects the first column? This wouldn't be possible with a sheet layout
> > either.
>
> This is the tricky case.  I am hesitant to agree that we should set up
> these lists of regions with certain styles.  I think if we start setting up
> regions these lists can grow and grow and become very inefficient.  I
> suggest we keep track of the selection so that if all cells are selected
> then changing the format changes the sheet's format and any columns or rows
> that were deselected before changing the format are then set manually to
> what they had before.
> An example would probably clarify this:
>
> To begin with, the document has default formats, each sheet, column, row,
> and cell has the empty style which means inherit the default.
> Select all cells in the sheet and set background color blue.
>    ---- Now the sheet style has the BackgroundFormat object that is blue.
> Select all cells and then deselect column A, and then set background color
> green.
>   ---- The code 'realizes' that the selection is all cells minus column A
> so column A is manually set to it's current background value.  This means
> we retrieve column A's background layout (doesn't have one so it retrieves
> the default from the sheet which is blue), and then set's column A's style
> to contain that blue BackgroundFormat.  Finally, the sheet's
> backgroundformat is set to green.
>
>
> Does that make sense?  Difficult to explain but I think it is more
> efficient than managing ever-growing lists of regions with associated
> styles.

I see what you are saying. But the region lists won't just grow. As soon as a 
region is not referenced anymore, the entry gets deleted. So the region must 
have a counter. If a cell doesn't use the fallback layout anymore, the region 
counter gets decreased, if it's zero we'll remove the region entry.

We don't need to use this way of organizing for every region. Only if the 
selections is "big" and use mostly uninitialized cells - if not we could 
still change cell by cell within the selection and use the way you and 
Philipp proposed.

In the end this region design works fine (and fast) for Gnumeric (which does 
not mean that we have to copy their code).

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]