[scribus-dev] state of the art of table, from a tester pov

ale rimoldi ale.comp_06 at xox.ch
Thu Jul 5 22:36:47 UTC 2012


hi

> Following previous year GSOC, tables have been refactored into 1.5svn.
> 
> This mail is a global "how it is now" report from a tester point of
> view.
> 
> Some of it has to be considered as a bug description, some other part
> might be considered as an incent to improve how things work, and some
> other parts might be used so as to start a documentation.
> 
> ===============================================
> 
> Change size of column or arrow :
> - insert carret inside one of the cells in edit mode (double click)
> - bring mouse over one of the lines inside or border outside (except
> left or top borders) of the table: it changes into a double arrow.
> Then : click and drag enables to move that border or line and change
> width or height of that cell / column
> 
> =================================
> 
> Cell selection :
> is uncommon and takes some time to understand.
> - insert carret into one of the cell in edit mode (double click)
> - bring mouse over external LEFT border or TOP border of the table :
> it changes into an single arrow
> - click and gently drag : all cells betwen insert carret and the line
> where you have clicked get selected.
> - go on moving the mouse : the selection changes according to mouse
> position. It is thus possible to select any rectangular group of
> cells, including single cells. However this behaviour is uncommon.
> Expected = usual behaviour would have been to select the whole
> arrow / column when singleclicking.
> 
> Another way to select a set of cells is :
> - go out of edit mode and select the table frame, or place the edit
> carret in one of the cells you dont want to select
> - double-click-and-drag until you select the desired set of cells
> 
> ==============================
> 
> Table & frame adjust
> 
> - adjusting the table is possible without changing the frame. It is
> thus possible to make the table smaller or wider than the frame (if
> wider it is partly hiden). So the User Experience is that both frame
> and table size are independant.
> - BUT changing the frame automatically resizes the table to fit the
> new frame size, even if the table previous size was very different to
> the frame's size. This contradicts the user's previous experience of
> having tables and frames independant sizes.
> 
> I suggest that this 2nd behavious should be changed to either :
> - frame size changes do not change table size
> or :
> - frame size changes do change table size ONLY IF table size is full
> frame size. or :
> - This behavious could maybe be altered using a new option in the
> style of a table (and thus in the edit style window AND in the PP or
> context menu), with a checkbox for : "allways adjust frame to table
> and table to frame"
> 
> 
> ==============================
> 
> Table split :
> 
> i could merge 2 cells but could never have the "split cells" option
> active in the context menu (its allways greyed). (even on a
> previously merged cell).
> 
> ==============================
> 
> Action on a set of selected cells
> 
> Once a set of cells is selected it is possible through the PP to
> change the width and color of the borders of the cell and to change
> the fill color BUT
> - only the first (top left) cell is affected (the other selected
> cells dont change at all)
> - when selecting another cell, it seems the PP doesnt allways update
> its display as for the cell style
> 
> - it seems that : when the shape of the frame has been changed into
> something not rectangle, the lines that are totally outside the shape
> of the frame are displayed when coloured (but not the parts outside
> frame of lines that are only partly inside frame).
> 
> - i understood that each cell can define its borders. since an inside
> line has 2 bording cells, it can be defined in 2 different ways. When
> conflicting, it is the widest border definition that wins and totally
> overwrite the other.
> 
> - the cursor keeps being an insert carret when moved to the PP. that
> is troubling.
> 
> I posted this too in http://bugs.scribus.net/view.php?id=10784


while i was preparing the talk on scribus 1.6 for the rmll
(http://rmll.info),  i've gone through the tables and can confirm most
of the issues jluc encountered...

i've created one ticket for each issue...

ciao
a.l.e



More information about the scribus-dev mailing list