Table Container

[kenodegard]

I am aware that this PR is not finished yet. I want to get community feedback to see if there are any preferred ways of implementing this.

The implementation thus far works in generating a table. Still need to figure out the ideal way of controlling column widths.

A demo of the container is available as part of this PR:

from prompt_toolkit.widgets import table

table.demo().run()

I was initially thinking to use the width logic used by prompt_toolkit.shortcuts.progressbar.ProgressBar but I don't think that will work given the desire to support merged cells.

The column widths are controlled by the column_width and column_widths arguments passed to the Table container. column_width is the default Dimension to use for all widths, column_widths is the index specific Dimension. If the column width for a given column is None then we aggregate all of the cells in that column together and get the "maximum" Dimension, otherwise we use the column width defined.

#305

[kenodegard]

Here's an example of what this table container is capable of rendering.

 ╔═══════════════╦═══════════════╦═══════════════╦═══════════════╗
 ║Hello World    ║Praesent eu ult║Lorem ipsum dol║               ║
 ║               ║               ║or sit amet, co║               ║
 ║               ║               ║nsectetur adipi║               ║
 ║               ║               ║scing elit. Ut ║               ║
 ╠═══════════════╩═══════════════╬═══════════════╬═══════════════╣
 ║Buzz                           ║Morbi viverra, ║               ║
 ║                               ║justo eget pret║               ║
 ║                               ║ium sollicitudi║               ║
 ║                               ║n, magna ex sod║               ║
 ╠═══════════════╦═══════════════╩═══════════════╩═══════════════╣
 ║<The quick b   ║Ut egestas vel nisi et sodales. Etiam arcu mass║
 ║               ║a, viverra in pellentesque quis, molestie a lac║
 ║               ║us. Nulla suscipit mi luctus blandit dignissim.║
 ║               ║ Proin ac turpis sit amet enim luctus venenatis║
 ║               ║ quis et orci. Donec sed tortor ex. Class apten║
 ╠═══════════════╬═══════════════╦═══════════════╦═══════════════╣
 ║<Hello World   ║Donec placerat ║               ║               ║
 ║               ║lacus egestas, ║               ║               ║
 ║               ║aliquam enim vi║               ║               ║
 ║               ║tae, congue ips║               ║               ║
 ║               ║um. Praesent vi║               ║               ║
 ╠═══════════════╬═══════════════╬═══════════════╬═══════════════╣
 ║Buzz           ║Aliquam eleifen║               ║               ║
 ║               ║d mi arcu, sit ║               ║               ║
 ║               ║amet convallis ║               ║               ║
 ║               ║tellus condimen║               ║               ║
 ╚═══════════════╩═══════════════╩═══════════════╩═══════════════╝

[jonathanslenders]

Hi @njalerikson,

This looks really nice!

Some people have been asking for this. (I think the pgcli developers would like something like this for rendering the query output. On top of that, one of the developers wanted a way to select a cell, edit the content, and save it again. Further, this would require some kind of scrolling. I guess that can be implemented on top of this.)

I still need to go through all the changes, but I will have some feedback. Before merging it, we have two options. Either we give this pull request some time for it to become stable and mature, or we release it as a separate package until the API is stable, and can be merged. (I don't like to introduce too many backwards-incompatible changes in prompt_toolkit, but at the same time I want code to be really nice before merging it.)

Anyway, thanks a lot for starting this!

Jonathan

[kenodegard]

So I am currently pretty pleased with how the widths are handled. It works wonderfully when using weighted widths and/or fixed widths.

What I currently dislike is that there isn't a way to handle a "fitted" width where a column width is governed exclusively by the preferred width value and not expanded to fill the screen (as currently happens). How do you think that could be best accomplished? I would expect a table where all of the columns are being "fitted" could potentially result in a table that doesn't fill the screen width.

Finally, I think that there should be a different way of solving the need to override the _divide_widths method from _Row/VSplit. I dislike how it's almost a perfect copy of the original.

Maybe it makes more sense to modify VSplit to where we can pass in column_width and column_widths arguments there instead?

[lyz-code]

@jonathanslenders what steps are required for this PR to be merged? Maybe I can help

[jonathanslenders]

@lyz-code:

At least:

• it needs to be rebased on the current code;
• it needs to be fully strict typed;
• all CI checks have to pass;
• all classes should have docstrings;
• the example should go in the examples directory.

I never had the time to review it, but given that it doesn't change any code outside of this file, if all works well and the above is fixed, maybe it can be merged.

[Vosjedev]

are there still people working on this?
Is it possible to use the code in a project? Or would I have to make a table myself?

[lyz-code]

Hi @Vosjedev in the past I started working on a different approach for the same solution. I started creating prompt-toolkit-table but never finished the first version.

If anyone wants to continue where I left it I can transfer the repo or accept PR