On Wed Nov 06 10:36:25 2013, SHARYANTO wrote:
Show quoted text> On Wed Nov 06 05:25:31 2013, TEAM wrote:
> > Thanks for the report - this module needs an overhaul really, it's
> > mostly been replaced by Tickit::Widget::Table::Paged (which provide
> > more efficient rendering and the ability to scroll through the list)
> > but it's about time I fixed Tickit::Widget::Table so that it's at
> > least usable.
>
> Yeah, I kind of figured that out when I see
> Tickit::Widget::Table::Paged on MetaCPAN. Is there a feature of
> ::Table not in ::Table::Paged? Because if there is none, I would
> suggest that ::Table be retired.
The main difference is that the ::Table module provides cell, column and row abstractions, allowing more control and variety for populating cell values (such as arbitrary widgets rather than just text).
::Paged is more intended for a table where each row contains the same structure and we expect more rows than would fit on the terminal - database query results, for example. The major difference here is that ::Table is intended for direct control - you specify the cell content ("push" model) - whereas ::Paged is (eventually) supposed to pull data from an abstract data source.
Show quoted text> > I was highly impressed by your Text::ANSITable implementation - it's
> > the best-looking table on CPAN - so I was wondering whether it would
> > make sense to reimplement this using your code instead. What do you
> > think? Seems that most of the Text::ANSITable API would also be
> > appropriate here, just needs support for the interactive aspects
> > (actions on highlight/selection) and rendering specifics.
>
> Actually TBH I'm not terribly satisfied with the performance of
> Text::ANSITable either (haven't done any real optimization on it).
> Creating a table with hundreds or a thousand+ rows will require a
> noticable (1+ s) delay. So I'm not sure how well that would work.
Since Tickit has the luxury of knowing how many rows it'll be required to render to fit on the terminal, it might be possible to take some shortcuts there - seems that the API is more complete than the current ::Table implementation and there'd be some advantage in being able to switch between STDOUT and interactive Tickit versions without having to rewrite the table-handling code.
Hoping to have some time to spend on these during this week so I'll let you know when there's any progress.
In the meantime, there's some more Tickit info in
https://github.com/ingydotnet/tickit-info if you haven't seen it already?
cheers,
Tom