← Back to team overview

zim-wiki team mailing list archive

Re: Bounty for Tables Implementation

 

On Sat, Nov 27, 2010 at 11:40 PM, Michael Mulqueen
<michael@xxxxxxxxxxxxxx> wrote:
> Short specification:
> * some kind of table widget needs to be embedded into a standard Gtk+
> text editor (or we need a substantial rewrite of that part of Zim, but
> that would be far from ideal)
> * it should be native if at all possible (rather than requiring LaTeX,
> although that's a useful work around)
> * must be easy to use
> * must follow existing coding conventions in Zim
> * must be released under the all of the same licenses as Zim
>
> See also: https://bugs.launchpad.net/zim/+bug/208589

Just brainstorming a bit how this would work. I think it is clear that
we need to embed a widget in the textview, which requires a bit of
work.

However there is a choice on what kind of widget to use. We can make a
custom widget that builds a table from embedded textviews, or we can
embed a treeview widget.

Custom widget of textviews:
* Pro: can contain any formatting
* Pro: could support merging cells (so more flexible layout)
* Con: need to test performance for large tables
* Con: lot of implementation work to work out all the details

Treeview widget:
* Pro: get all advanced features for free: sorting, hierarchical items, etc
* Pro: known to have good performance even for large data sets
* Pro: existing widget, only need work to integrate and add controls
to add/remove cols etc.
* Con: no formatting (or at least one formatting per column)

What it comes down to is that if tables will be mainly used to chart
data the treeview looks like a very nice option and it can do advanced
stuff out of the box. Big disadvantage is that it can not support text
formatting or flexible layout like merging cells. We could set format
per column though (including making a column link).

On the other hand if the intention is to create tables as a way to
layout the text and make a page pretty (a typical usage in HTML web
design) the treeview is useless and we really need a set of textviews
layed out in a semi-regular grid.

Third option is of course to support both, but would like to get some
feedback which use case would have the most users and focus on design
for that use case first.

(Just to be clear, I'm only thinking about the design, not on
implementation, so still open bounty for whoever wants to work on it.)

Regards,

Jaap



Follow ups

References