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

List:       koffice-devel
Subject:    Re: [kspread] formatting design
From:       Philipp =?iso-8859-1?q?M=FCller?= <philipp.mueller () gmx ! de>
Date:       2002-12-15 8:49:38
[Download RAW message or body]

Am Sonntag, 15. Dezember 2002 03:53 schrieb John Dailey:
> > 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.

Yes, this is true for existing cells. But what with not yet existing ones?
Like you define the border for yet empty cells. You don't like to store the 
border information by creating cells, you need to have it somewhere stored 
(like in a range object) and only in case you later input a value, the then 
created cell gets the layout asigned to from this "range".

I agree with Norbert now, that ranges is the way to go.

> > 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.

Yepp.

>
> > 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 agree with you, that the code can/should be optimized in this area. This is 
still a possibility to reduce the cluttering by the different ranges in the 
list.
But I also see, that there are things the "silly" ;-) user can do, which 
cannot be optimized here. These "silly" things in the end may then make 
KSpread suddenly unusable for the user. E.g. a user can always do a 
ctrl-down, ctrl-right and make a layout change. With "unlimited" rows/columns 
we then get problems. The user can do this ctrl-down/-right with one time 
starting at B2 (border line), the next time at B100(number format) and 
another time with E10 (border color). You code would get cluttered as well 
and you cannot handle all of this in one sheet object.
And what if the user make ctrl-down and one up (silly yes, but users will try 
it, only to see if KSpread can handle it)?

Philipp
_______________________________________________
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]