[scribus-dev] Preparations for GSoC

[a.l.e]

hi elvis,

nice to see you preparing your work!



> 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?

melange says: mrb (craig)

> == 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.

i tend to prefere this approach to the inline items we've heard of...

> 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?

the PP will  lose its tabs and will become content sensitive... but it 
does not change much to the fact that it's probably a good idea to 
implement the table settings as a PP tab.

> tables, rows and columns are resized by click-dragging,
> and I'm guessing this is how we want it to work in Scribus too?

click and dragging + exact measurement in the PP

> 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?
probably, yes, we should keep the modal way of working.

there were some discussion on changing this behavior for text and image 
frames, and the result was that it's not a bad idea to keep the current 
state (it can help prevent accidental change; on the other side 
manipulation can be a bit slower...)
in my eyes, the most important thing is, that the program behaves in a 
consistent way: if we want cells to be "always" resizable, we should 
plan also to change the behavior for text and image frames.


> === 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?
basically, i think that we would like to get styles for as many things 
as possible. frame styles are (somehow) already planned...


> 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?

in scribus you go to the "normal" mode to edit the container... i guess 
we should keep this behavior...
the question is how to best select the elements... i tend to like the 
current alt-click, but we should better document how to get the window 
managers not to capture the alt-clicks.

> === 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()?
do we want the cells to automatically grow?
in scribus, nothing automatically grows...

text overflow can be queried from the scripter, you can go there to find 
out how to do it :-)

> 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?

it's not done and i'm not 100% it's a good idea to implement it...
it will certainly be helpful for newcomers (but what will they think 
when the page is filled and there is no place for growing the frame? 
should we automatically create a new page? ask for it? ... not sure it's 
a good idea...)

> === 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.

double clicking a cell should start the edit mode.

the question is how to find the context in the modal editing... imo we 
could have both in the PP (table / cell)

> 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.

(shift) tab should be captured and used as next cell...
not sure if we want other navigation keys...

> === 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.

i think that it should work in the same way as for text frames...


hope that helps... :-)

keep up the good work!

ciao
a.l.e