GSoC 2011 Tables Design: Difference between revisions

From Scribus Wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by the same user not shown)
Line 1: Line 1:
= GSoC 2011 Tables Design =
= GSoC 2011 Tables Design =
This page outlines the design and implementation details of tables in Scribus as part of Google Summer of Code 2011.
This page outlines the design and implementation details of tables in Scribus as part of Google Summer of Code 2011.
Page TODO:
* Summarize what was concluded in [http://lists.scribus.net/pipermail/scribus-dev/2011-May/000917.html this] thread on the mailing list.
* Make simple mockups for the most common UI operations on tables.
* Go through the [[#Old Material|old material]] below and make sure all questions there are incorporated into the new material. For those that are not, bring them into a new section "Unanswered Questions".


== General Design ==
== General Design ==
Line 57: Line 51:
[[File:Resizing_table_proportionally.png|center|frame|Mockup of resizing a table where all column widths follow proportionally.]]
[[File:Resizing_table_proportionally.png|center|frame|Mockup of resizing a table where all column widths follow proportionally.]]


{{warning|What do we do with table height during resizing of tables? Is not scaling the entire table proportionally, both width and height, a valid use case? And how do we cover this? And should table width follow the width of the table frames like in these mockups, or should table width be independent of the width of the frame just like height?}}
For an alternative workflow when resizing tables, inspired by some ideas by a.l.e. on the mailing list, take a look at this more detailed workflow mockup:
 
[[File:Resizing_table_workflow_mockup.png|thumb|center|Detailed Table Resizing Workflow Mockup.]]
 
=== Selecting Cells ===
Selecting cells can be done directly from ''normal'' mode. Using the '''Alt''' modifier, the user can select individual cells by clicking on them, and by using the '''Alt+Shift''' modifier a rectangular region of cells can be selected by dragging across them.
 
[[File:Selecting_cells.png|center|frame|Mockup of selecting table cells.]]
 
=== Selecting Rows and Columns ===
Selecting rows and columns will work like in common word processors. When hovering the left edge of the first cell in row the cursor will be turned into a right-pointing arrow and by clicking the entire row is selected. Likewise for columns but when hovering to top edge of the first cell and with a down-pointing arrow.
 
[[File:Selecting_row.png|center|frame|Mockup of selecting a table row.]]
[[File:Selecting_column.png|center|frame|Mockup of selecting a table column.]]


=== Resizing Rows and Columns ===
=== Resizing Rows and Columns ===
Resizing rows and columns will also work like in common word processors. While in ''normal'' mode the user will be able to drag with the mouse on row/column boundaries to resize the rows and columns, respectively.
[[File:Resizing_row.png|center|frame|Mockup of resizing a table row.]]
[[File:Resizing_column.png|center|frame|Mockup of resizing a table column.]]
=== Inserting and Deleting Rows and Columns ===
=== Inserting and Deleting Rows and Columns ===
TODO.
=== Editing Table Content ===
By double-clicking a cell the user is put in table ''editing'' mode. As text is typed, it will be constrained to the cell width, but the height of the row will grow automatically. If the rows of the table will not fit the frame, the overflow marker will be displayed.
[[File:Table_editing.png|center|frame|Mockup of editing the contents of a table cell.]]
=== Formatting Tables and Cells ===
=== Formatting Tables and Cells ===
=== Editing Table Content ===
Formatting of tables and cells, such as background color, border color, border style, default paragraph style et.c. can be done either directly by using the Property Palette, or by using table styles or cell styles. These will be available in the Styles Manager just like normal paragraph or character styles, but will contain properties specific to tables and cells.
==== Direct Formatting ====
 
==== Table Styles ====
There is currently some work planned to rework the Properties Palette to be less cluttered and more context sensitive, and if this work will take place during the course of my GSoC project, this is something that might need to be taken into account. But no matter which version of the Properties Palette will be in use, I imagine that the user should be able to
==== Cell Styles ====
 
# '''(in normal mode with a table selected)'''
#* change formatting properties of the table.
# '''(in normal mode with a row selected)'''
#* change formatting properties of the row '''and'''
#* change formatting properties of the table
# '''(in normal mode with a column selected)'''
#* change formatting properties of the column '''and'''
#* change formatting properties of the table
# '''(in normal mode with a cell or rectangular region of cells selected)'''
#* change formatting properties of the cell(s) '''and'''
#* change formatting properties of the row(s) the cell(s) is/are in '''and'''
#* change formatting properties of the column(s) the cell(s) is/are in '''and'''
#* change formatting properties of the table the cell(s) is/are in
# '''(in editing mode with the cursor positioned in a cell)'''
#* change formatting properties of the cell the cursor is in '''and'''
#* change formatting properties of the row the cursor is in '''and'''
#* change formatting properties of the column the cursor is in '''and'''
#* change formatting properties of the table the cursor is in.
 
as well as apply a style for any of the above.
 
The theme here is that with more specific parts of the table selected, such as a cell, the user should still be able to format higher level parts of the table which the cell is in, such as the row or the entire table.


== Technical Implementation ==
== Technical Implementation ==
This will all come as the project progresses.
=== Basic Data Structures ===
=== Basic Data Structures ===
This will all come as the project progresses.
=== Table Layout Process ===
=== Table Layout Process ===
This will all come as the project progresses.
=== Border Model ===
=== Border Model ===
=== CSV Import Script ===
The border model initially used for the borders of the table cells will be a collapsing border model similar to the [http://www.w3.org/TR/CSS2/tables.html#collapsing-borders CSS2 collapsing border model]. Border conflicts will also be handled in a similar way, described below.
 
==== Border Conflict Resolution Method ====
TODO.
 
=== Border Painting ===
With borders joined, the following cases are possible:


== Future Considerations ==
[[File:Table_border_join_cases.png|400px|thumb|center|Possible cases when painting joined table borders]]
=== Linked Table Frames ===
=== ODF Import ===


= Old Material =
=== Saving / Loading ===
== General Design ==
This will all come as the project progresses.
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.
=== CSV Import Script ===
This will all come as the project progresses.
=== Outstanding Questions ===
Here I'll gather some technical questions I need to find answers to.


== Interaction Questions ==
==== Disabling Decorations / Resize Handles of Text Frames ====
In the questions below, I refer quite a lot to Adobe Indesign CS5.5. 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.
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.


=== Table Creation/Editing ===
==== Saving to .sla ====
[[File:Indesign_table_menu.png|thumb|right|The "Table" menu of Adobe Indesign CS5.5]]
How will we represent the tables in Scribus' .sla format?
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?
== Future Considerations ==
=== Linked Table Frames ===
In the future, we'll probably want to be able to link table frames, e.g. to be able to let one table flow from a page to the next, or from one column to the next. It might be a good idea to keep this in mind when writing the table layout process.


=== Table/Row/Column Resizing ===
=== ODF Import ===
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?
This is for the future.


== Some InDesign CS5.5 Screenshots ==
{|
{|
| style="vertical-align: bottom;" | [[File:Indesign_table_menu.png|thumb|right|The "Table" menu of Adobe Indesign CS5.5]]
  | style="vertical-align: bottom;" | [[File:Indesign_table_resizing.png|thumb|center|Resizing a table in Adobe Indesign CS5.5]]
  | style="vertical-align: bottom;" | [[File:Indesign_table_resizing.png|thumb|center|Resizing a table in Adobe Indesign CS5.5]]
  | style="vertical-align: bottom;" | [[File:Indesign_row_resizing.png|thumb|center|Resizing a table row in Adobe Indesign CS5.5]]
  | style="vertical-align: bottom;" | [[File:Indesign_row_resizing.png|thumb|center|Resizing a table row in Adobe Indesign CS5.5]]
Line 99: Line 153:
  |}
  |}


=== Styles ===
[[Category:GSOC]][[Category:GSOC 2011]][[Category:EN]][[Category:Development]][[Category:Tables]]
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 simple 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 it's 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.
 
== Use Cases ==
TODO.
 
[[Category:Development]]
[[Category:Tables]]

Latest revision as of 16:47, 3 July 2011

GSoC 2011 Tables Design

This page outlines the design and implementation details of tables in Scribus as part of Google Summer of Code 2011.

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. More radical approaches to tables in Scribus have been suggested before, but the tables I'll be implementing as part of Summer of Code will be more traditional in the sense that tables will consist of a rectangular array of cells.

Use Cases

TODO.

User Interface Design / Interaction

These are some notes about the interaction design of the tables UI. A lot of the ideas come from this thread on the mailing list.

Modes of Operation

Mockup of the normal and editing modes.

Following the tradition of the modal way of working with items in Scribus, there will be two operational modes when working with tables; normal mode and editing mode. The possible operations for each mode are listed below. The operations are explained in more detail further down.

Normal Mode

This is the normal mode of operation when working with items in Scribus, and the one the user will be in directly after creating a table. In this mode, the user is able to

  • Select tables.
  • Resize tables.
  • Move tables.
  • Select rows and columns.
  • Resize rows and columns.
  • Select cells and regions of cells.
  • Add and remove rows and columns.
  • Format tables, rows, columns and cells.

Editing Mode

By double-clicking in a table cell with the mouse, the user is able to enter editing mode. In this mode, the user is able to

  • Edit cell content.
  • Navigate between cells using the keyboard.
The "quick" table creation widget in Calligra Words

Creating Tables

The current way of creating tables is quite sufficient; the user is able to create tables by pressing a button in the toolbar or by picking a menu item, entering the desired number of rows and columns and then mouse dragging the desired dimensions of the table on the page. Possibly, I could steal a widget that Casper Boemann of Calligra Words wrote which looks like the automatically expanding grid for selecting number of rows and columns in e.g. LibreOffice. He said it was OK, as long as I fix a couple of bugs he had found in it :) But in general, the current way of inserting tables works fine.

It should also be possible to create tables by importing them from a file, and the general consensus seems to be that CSV has higher priority than ODF, at least for the GSoC project. Hopefully the table implementation will be scriptable enough that this import could be done as a script.

Moving and Resizing Tables

Moving a table is a simple matter of dragging it around with the mouse, just like with other items in Scribus.

Mockup of moving a table.

Resizing a table is also done just like with regular Scribus items. We will probably want two ways of resizing the table, one where only the width of the last column is affected, and one where all column widths follow proportionally.

Mockup of resizing a table where only the last columns is affected.
Mockup of resizing a table where all column widths follow proportionally.

For an alternative workflow when resizing tables, inspired by some ideas by a.l.e. on the mailing list, take a look at this more detailed workflow mockup:

Detailed Table Resizing Workflow Mockup.

Selecting Cells

Selecting cells can be done directly from normal mode. Using the Alt modifier, the user can select individual cells by clicking on them, and by using the Alt+Shift modifier a rectangular region of cells can be selected by dragging across them.

Mockup of selecting table cells.

Selecting Rows and Columns

Selecting rows and columns will work like in common word processors. When hovering the left edge of the first cell in row the cursor will be turned into a right-pointing arrow and by clicking the entire row is selected. Likewise for columns but when hovering to top edge of the first cell and with a down-pointing arrow.

Mockup of selecting a table row.
Mockup of selecting a table column.

Resizing Rows and Columns

Resizing rows and columns will also work like in common word processors. While in normal mode the user will be able to drag with the mouse on row/column boundaries to resize the rows and columns, respectively.

Mockup of resizing a table row.
Mockup of resizing a table column.

Inserting and Deleting Rows and Columns

TODO.

Editing Table Content

By double-clicking a cell the user is put in table editing mode. As text is typed, it will be constrained to the cell width, but the height of the row will grow automatically. If the rows of the table will not fit the frame, the overflow marker will be displayed.

Mockup of editing the contents of a table cell.

Formatting Tables and Cells

Formatting of tables and cells, such as background color, border color, border style, default paragraph style et.c. can be done either directly by using the Property Palette, or by using table styles or cell styles. These will be available in the Styles Manager just like normal paragraph or character styles, but will contain properties specific to tables and cells.

There is currently some work planned to rework the Properties Palette to be less cluttered and more context sensitive, and if this work will take place during the course of my GSoC project, this is something that might need to be taken into account. But no matter which version of the Properties Palette will be in use, I imagine that the user should be able to

  1. (in normal mode with a table selected)
    • change formatting properties of the table.
  2. (in normal mode with a row selected)
    • change formatting properties of the row and
    • change formatting properties of the table
  3. (in normal mode with a column selected)
    • change formatting properties of the column and
    • change formatting properties of the table
  4. (in normal mode with a cell or rectangular region of cells selected)
    • change formatting properties of the cell(s) and
    • change formatting properties of the row(s) the cell(s) is/are in and
    • change formatting properties of the column(s) the cell(s) is/are in and
    • change formatting properties of the table the cell(s) is/are in
  5. (in editing mode with the cursor positioned in a cell)
    • change formatting properties of the cell the cursor is in and
    • change formatting properties of the row the cursor is in and
    • change formatting properties of the column the cursor is in and
    • change formatting properties of the table the cursor is in.

as well as apply a style for any of the above.

The theme here is that with more specific parts of the table selected, such as a cell, the user should still be able to format higher level parts of the table which the cell is in, such as the row or the entire table.

Technical Implementation

This will all come as the project progresses.

Basic Data Structures

This will all come as the project progresses.

Table Layout Process

This will all come as the project progresses.

Border Model

The border model initially used for the borders of the table cells will be a collapsing border model similar to the CSS2 collapsing border model. Border conflicts will also be handled in a similar way, described below.

Border Conflict Resolution Method

TODO.

Border Painting

With borders joined, the following cases are possible:

Possible cases when painting joined table borders

Saving / Loading

This will all come as the project progresses.

CSV Import Script

This will all come as the project progresses.

Outstanding Questions

Here I'll gather some technical questions I need to find answers to.

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.

Saving to .sla

How will we represent the tables in Scribus' .sla format?

Future Considerations

Linked Table Frames

In the future, we'll probably want to be able to link table frames, e.g. to be able to let one table flow from a page to the next, or from one column to the next. It might be a good idea to keep this in mind when writing the table layout process.

ODF Import

This is for the future.

Some InDesign CS5.5 Screenshots

The "Table" menu of Adobe Indesign CS5.5
Resizing a table in Adobe Indesign CS5.5
Resizing a table row in Adobe Indesign CS5.5
Resizing a table column in Adobe Indesign CS5.5