GSoC Calc Table Styles (was: Redirecting conversation regarding GSoC Project to Mailing List)

[Eike Rathke]

Hi Sarrah,

On Friday, 2022-04-08 16:51:34 +0530, Sarrah Bastawala wrote:

> Based on what I have understood so far, here is the functionality we are
> looking to implement in Table Styles
> 
>    We want to visually make it similar to the tables currently present in
>    autoformat, however it should be able to apply the same attribute to
>    multiple cells changing as more data is entered

That's right. It should be one attribute with a table style ID applied
to a cell range, and that table style should handle all the necessary
settings like whether or not header row or total row is present, left
and right column, banded rows, banded columns, and so on, and how a cell
with its offset within such table should effectively be displayed. The
effective display attribute is not tied to a particular cell/row/column,
also for example, banded rows and columns should continue alternating in
the view if rows or columns are hidden. Which is something that
completely does not work with current AutoStyles.


>    The functionality for this could be referred to from the present table
>    styles in Impress and the functionality for sorting, filters, etc from
>    existing code for pivot tables in calc, if I’m not wrong. ( I would
>    appreciate if you could give me the code pointers for these to refer
>    directly)

Sorting and filters or pivot tables are not directly related. A table
style applies to the current view of a table cell range. It should
however be related to defined database ranges (Data -> Define Range), as
those already have properties for column labels (header row) and totals
row and are used with Table References in formulas as well. I'm not sure
if Impress table styles are actually helpful here, though the
functionality in Table Design of sidebar looks very much like what is
needed. I don't know their implementation details yet though.


>    Also, as the bug [#132780](
>    https://bugs.documentfoundation.org/show_bug.cgi?id=132780) talks about
>    in detail, it also includes that the functionality is present identically
>    in openoffice with a GPL3 license,

If you meant
https://bugs.documentfoundation.org/show_bug.cgi?id=132780#c7
that's not OpenOffice but OnlyOffice. And no, we can't use GPL code so
that comment is off.

That bug also is more about the functionality of tables, like behaviour
when new rows are added copying formulas of the row above and such.
Let's focus here on the Table Styles.


>    I’m not extremely well versed in this, but I assume apart from the
>    hindrance to user of formatting added data manually in Autoformat styles,
>    the main difference of table styles to that would be that instead of
>    applying the attributes cell by cell, they would be applied directly to the
>    entire table.

That's correct. (which effectively means that one table style attribute
will be applied to a range of rows per column).

>    I believe this would require some concepts of Object-Oriented
>    programming to increase the efficiency, and I think I could understand
>    better from how it is already implemented in Impress.

Try to work through, maybe it's helpful for ideas. Note though that
Calc's attribution handling works quite different.


>    Lastly, I see that suggestions include asking users to use pivot tables
>    for functionalities such as creating charts from tables etc., so if we do
>    implement table styles, I assume we would merge it with pivot tables.
>    Please feel free to correct me if I’m wrong anywhere and guide me on how to
>    proceed further with this project and what resources would I need to study?

As said, the table style view should be completely independent of any
pivot table functionality.


The current attribution of cells has 3 levels, ordered in precedence
(top items override lower items):

1. conditional format
2. hard attribution
3. cell style

Table styles would go between hard attribution and cell style, yielding
a precedence of

1. conditional format
2. hard attribution
3. table style
4. cell style

So all methods asking for cell atributes that currently evaluate styles,
hard attribution and conditional formatting would have to evaluate table
styles as well to determine the final attributes relevant to display
a cell.

Some code pointers:

sc/source/core/data/attarray.cxx
Does all the applying an attribute to a range of rows within a column
and obtaining attributes. Probably adding/removing table styles could be
similar to ScAttrArray::AddCondFormat() and
ScAttrArray::RemoveCondFormat(), just an idea.

sc/source/core/data/documen4.cxx
* ScDocument::GetEffItem()
  * Obtains the effective item for an attribute (per WhichId), i.e.
    overriding with a conditional format if present. That should handle
    table styles as well in the correct order.
* ScDocument::GetCondFormat()
  * Check places where this is called, they'll likely need handling for
    table styles as well.

sc/source/core/data/fillinfo.cxx
* ScDocument::FillInfo()
  * The hard work of filling a (visible) cell array with all
    attribution, applying conditional formats and so on (to
    a ScTableInfo that is used to draw the grid or print). This will
    have to handle table styles as well.

Those are just some places to give you an idea where to hook in.
Hopefully useful.

  Eike

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20220412/5a653106/attachment.sig>