[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

Hello Scribus folks,

Summer is getting closer fast, and while I'm exceedingly busy with
preparations for my upcoming exams, I think it's important I get at
least some preparations for GSoC done so that I can get a flying start
and have a clear direction for my project once May 28 comes and exams
are over. I've started to write down some preliminary questions and
thoughts around my project and put them on the wiki [1], but I'll
include that page almost verbatim below, sans some of the wiki markup,
so that we can discuss it on-list. The wiki has a couple of
screenshots from Indesign, so perhaps you'll still want to check that
out. I'll extend/update the page as my project progresses.

I would be very grateful if you could read through these questions
once and give your comments. I'm especially interested in things where
you feel "no no no, not like that", or if there are things where you
know things will get hairy technically. I think it's important we're
on the same page regarding how the tables should work in Scribus from
the get-go, so any and all input is relevant.

Lastly, in the midst of everything I believe I've never asked who will
be my mentor this summer, might be good to know :) Malex? MrB?

Best regards,
Elvis

[1] http://wiki.scribus.net/canvas/GSoC_2011_Tables

= GSoC 2011 Tables =
This page contains technical and functionality related considerations
regarding the implementation of tables in Scribus as part of Google
Summer of Code 2011. Here I'll try to keep an up to date document
describing the design of the implementation, a list of open technical
problems and questions regarding the functionality of the tables,
including a couple of use cases as well as everything else concerning
my work on bringing tables support to Scribus.

== General Design ==
As was outlined briefly in my project proposal, the tables in Scribus
will be implemented as a new page item. Handling of cell content will
be delegated to text frames.

== Interaction Questions ==
In the questions below, I refer quite a lot to Adobe Indesign. This is
not because I see it as a template of good design or anything, it's
just that I happen to have come across a copy of it which I have
running under VirtualBox, and it helps to have something existing to
discuss around.

=== Table Creation/Editing ===
Is there a general consensus on how we want interaction with the
tables to work? Looking at how tables work in Indesign CS5.5, their
design is quite straight forward and works essentially as those found
in word processors: The user is presented with a "Table" menu from
which tables can be inserted and manipulated and formatted through
dialogs that pop up. Something that might be different from how tables
will work in Scribus is that in Indesign, tables can only exist as
inline objects inside a text frame, not as objects on their own.

I'm imagining that in Scribus, the user is able to freely position the
tables on the page, while in the future, we can hopefully let the user
insert the table item I'll be creating inline in running text by
making it an inline object of some kind? Another thing which I think
will naturally be different in Scribus is that in Scribus, editing of
item properties is mostly done through the Properties palette, and not
so much through dialogs that pop up (thankfully! because table editing
in Indesign seems to be very dialog-intense). I guess we will have a
new tab on the PP called "Table" that will be disabled unless a table
is selected, similar to how it works for images?

=== Table/Row/Column Resizing ===
In Indesign, tables, rows and columns are resized by click-dragging,
and I'm guessing this is how we want it to work in Scribus too?
Something that comes to mind is that for most items Scribus uses a
modal way of interacting with the item: In the "normal" mode, the user
is able to select, move and resize an item, while in the "editing"
mode (entered by double-clicking) he/she is able to perform editing
actions on the item, such as inserting text in text frames, or moving
vertices of a polygon. Is this modal way of working something we want
for tables as well, in order for them to fit in with the Scribus way
of working? If so, I'm guessing actions such as column/row resizing
should be available in the "editing" mode, while in the "normal" mode
the user is only able to move/resize the table?

=== Styles ===
A while ago I took an afternoon and investigated what it takes to
create a new kind of style in Scribus, thinking this is something we
might want for tables. It was mostly straight forward and I ended up
with a primitive skeleton of a new style which is now in my Git repo.
Since then however, I've started thinking; Are styles for tables (and
even for rows/columns/cells) something we really want, or are they an
unnecessary complication for small benefits? I don't know about other
programs, but Indesign does not have named styles for tables. Tables
are simply formatted by direct editing of properties for individual
tables. How common are use cases where the user would really be
hampered without support for named table (and possibly
cell/row/column) styles? Would it be sufficient for Scribus if editing
table properties is a per-table operation? I'd really like to get the
opinion of other team members on this.

=== Cell Selection ===
I'm guessing we want cell selection to work similar to word processors
and Indesign, where a user is able to enter a "cell selection" mode by
starting to select some text in a cell with the mouse and then
dragging outside the cell boundaries?

== Technical Questions ==
Below are some of the technical questions I have to find answers to.
Since the content of table cells will be represented using Scribus'
regular text frames, several of the questions below are related to
this.

=== Notification of Text Overflow in Text Frames ===
Using text frames for cell content means the table will have to be
notified when overflow occurs in a text frame, to be able to correctly
re-layout the table starting from the row in which the overflow
occurred. If we eventually want to have width-growing columns, we'll
also need a way to be notified when a line break is about to occur in
a text frame. So the question is; do text frames currently emit any
signals to indicate that content is overflowing? It seems they are
not, but one place where such a signal could possibly be emitted is in
PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might
not be a correct solution though, perhaps the table should instead
listen to insertions being made in the text frame, and query the frame
for its overflow state using PageItem::frameOverflows()?

In addition to being notified of when overflow happens, the table will
also need to be able to query the text frame for the height of its
content, to be able to resize it correctly during table layout. Is
this possible using the current API? If not, what would it take to add
it?

=== Editing of Cell Content ===
As the text frames have their own modal way of being edited, and on
top of that we'll probably have a modal way of editing tables (see
above under Interaction Questions), how will we combine the two when
it comes to editing cell content? I really don't think we want a
multi-layered modal interaction, where the user first has to
double-click the table, and then again double-click a cell in order to
edit its content. Indesign is on the other extreme of this, there a
user can directly edit the content of a table, without any modes of
operation. I think what we want in Scribus is for the user to
immediately be able to interact with the content of cells after the
first double-click on the table. Or what do you think?

On top of this is the question of keyboard navigation between cells,
which I'm sure we want. The table will probably have to somehow filter
the keyboard events before they hit the underlying text frame of the
cell in order to get this to work.

=== Disabling Decorations / Resize Handles of Text Frames ===
I will have to figure out how drawing of decorations, and possibly
also the resize handles of text frames can be disabled. The table will
only be interested in the text displaying / editing capabilities of
the text frames, and will not want them to draw anything else such as
borders, decorations or resize handles. Perhaps this is an easy thing,
but still something I'll have to investigate.