Addon flat-tables - for spanning rows and columns

[phidrho]

Goal:
For some examples in documentation I need possibility to span columns and rows.
Line-Tables don't support this so I found and additional extension Flat-Tables that extends Line-Tables and adds this functionality. I hope that you are OK with this proposal, I really didn't want to draw big tables just to get spanning of columns and grids.

I'm open to all comments and different suggestions to approach this problem if implementing additional extensions is not acceptable.

Feel free to change anything, or propose a change, I'll implement it.

Ticket(s): #

• Backport to LTR documentation is requested

[phidrho]

current:

new documentation:

[DelazJ]

For some examples in documentation I need possibility to span columns and rows.

@phidrho Is this not already possible with grid tables (see https://docs.qgis.org/3.40/en/docs/user_manual/introduction/browser.html#database-entries)?

[DelazJ]

And for faster structure edit, you can use tools like https://www.tablesgenerator.com/text_tables

[DelazJ]

That said, one advantage I can see with this extension is that you probably won't have to handle a wide table with long text

[phidrho]

Hi @DelazJ,

yes, I know it is possible with grid table, as I commented, but I'm trying to avoid it, because it's unpractical for bigger tables, small ones are ok.

Other, more important reason is that grid table is not DIFF friendly.

I will adopt, whatever choice you make.

[phidrho]

@DelazJ

To put myself in context...

I have prepared this 4 tables with detail description of LinesToPolygons and Polygonize Processing Algorithms with hi-res images and project samples in December, but never got time to deal with converting them to RST:

These images/tables are working material, I will try to simplify them and remove unneeded content while creating RST files.

So I started this conversion to RST this weekend and didn't like option to draw all this into Grid Tables, and I found an practical solution with flat-table extension, but if it breaks anything, or breaks any rule that's set by QGIS Documentation team - I fully understand and don't have anything against that we continue the "old" way.

It's related to my bug/feature request report, where I've promised to create a documentation for "weird" behavior in certain circumstances - qgis/QGIS#59785

[DelazJ]

yes, I know it is possible with grid table, as I commented, but I'm trying to avoid it, because it's unpractical for bigger tables, small ones are ok.

I can agree. and the diff point is valid one.
But I also notice OTOH there is no preview of the generated table in GitHub
Afaik, there is no rules about adding extensions so I think if we need it, we can install it.

To put myself in context...
I have prepared this 4 tables with detail description of LinesToPolygons and Polygonize Processing Algorithms with hi-res images and project samples in December, but never got time to deal with converting them to RST:

What do you think about simplifying the table as follows:

• the first row is the table title
• we remove the title row for description and visualization
• we merge description and visualization columns contents, the former being the caption of the latter
• input and output would then be single columns

.. list-table:: Lines to polygons ...
:header-rows: 1
:widths: 40 40 20

input	output	note
an image + description (or the other way)	an image + description (or the other way)	the note

Would that correspond to what you wanted to show?

[phidrho]

Would that correspond to what you wanted to show?

I will surely simplify it, something similar I've had in mind, I also need to remove unessesary repeated information.
These tables are actually my notes where I wanted to test all scenarios to fully understand how these tools work and I saved everything and wrote notes because I didn't know what data will in the end be in docs.

I often need these tools in my daily work, and I could never understand why sometimes one is working and another doesn't.
I regulary have data that's coming from CAD - usually lines (literally lines, not linestrings), and I needed to generate polygons but algorithm linestopolygons almost never worked on my data, so it was very confusing.
My opinion is that renaming this processing tool to linestringstopolygons is a must ASAP, with keeping old version hidden and still working for backwards compatibility, but that's another topic... firstly we need docs that describe behavior properly, then next thing will be slightly updating docstring for GUI.

I believe that this weekend I'll be able to create docs and make pull request.

[DelazJ]

These tables are actually my notes where I wanted to test all scenarios to fully understand how these tools work and I saved everything and wrote notes because I didn't know what data will in the end be in docs.

OK. If it finally happens that you still need flat-table for a proper formatting, go ahead; we will then include it.