[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

Hi a.l.e,

2011/5/16 a.l.e <ale.comp_06 at xox.ch>:
> 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)

Ah, thanks. I never seem to be able to work the melange site
correctly. Seems each year it sucks in new ways, though this year it's
not as bad as it was in 2009.

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

Yes, from an implementation point of view I think it will be simpler,
though inline tables is for sure a valid use case. But hopefully we
can work that out later. And as Craig said, there's nothing about the
basic functionality of the tables that should have to change in inline
vs. non-inline mode.

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

Alright, good to know about these plans though.

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

Like I imagined it 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?
>
> 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.

Yes, consistency is worthwhile, and why I brought it up. I also think
tables should have an editing mode in which operations such as
resizing/adding/removing of rows/columns is performed. I don't know if
I explained my concern over multiple layers of modality good enough
though, but more about that further down.

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

Yes, and after my slightly embarrassing ignorance of the fact that
InDesign actually has a quite comprehensive support for table and cell
styles in my initial post (corrected by Leonard above) I must agree,
and will make sure Scribus supports this too.

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

Yes, but this is where my concern over multiple layers of modality
come in. Do I understand you correctly that you actually want one
three modes of operation:

1) Normal Mode: The user is able to select, move and resize the table.
2) Table Editing Mode: The user is able to insert/remove/resize rows
and columns.
3) Cell Editing Mode: The users is able to edit cell content.

And if so, in which mode, 2 or 3, will the user be able to select a
rectangular region of cells by mouse-dragging? As you probably know,
in word processors and in InDesign, doing this is a matter of starting
to select a span of text in a cell and then going outside the cell,
which will enter a cell selection mode where a region of cells is
selected. This would be equivalent to cell selections being done in
mode 3 above (the innermost mode). The alternative is letting the user
do this in mode 2. With that approach, individual cells would then be
directly selectable by just clicking them, and a region of cells by
click-dragging.

In addition to selection of individual cells and rectangular region of
cells, we need selection of rows and columns, and I guess this will
work in mode 2 just like it does in word processors, the mouse cursor
will be changed to an arrow pointing right when hovering the left edge
of a row, and an arrow pointing down when hovering the top edge of a
column. Upon click the entire row or column will be selected,
respectively.

Or maybe you had something else in mind than these three modes of operation?

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

Ah, now I see what you mean. I was honestly not aware of the Alt
modifier to select items inside a group (is it used for something else
as well?), as I'm so used to having Alt for moving windows.

Perhaps in addition to the cell selection behavior I explained above,
we could allow the user to, while in the normal mode (mode 1), select
individual cells by Alt-clicking. But I'm pretty sure that somewhere
we need to give the user the ability to select a rectangular region of
cells.

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

Well I've just assumed that we want this as it's how almost every
other table I've ever seen works, but indeed, nothing automatically
grows in Scribus. Naturally non-growing behavior should be supported
even if auto-growing is implemented. But what do you other guys think?
Grow or not?

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

Good tip. After writing my initial mail and that wiki page, I realized
that some of what I said was non-sensical, as I was suggesting to emit
signals for this inside the decoration drawing method of PageItem,
which doesn't make sense. Listening to text insertions and then
querying the item for overflow is probably the way to go.

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

Hm yes. I guess it would just grow and the user would realize that his
table doesn't fit the page and cope with it. But I see your point.

If you really don't want rows and tables to automatically grow, you've
cut a good chunk out of the table layout logic out of my work :)
Again, what do you other guys think? MrB?

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

Okay, but related to my questions regarding the 3 modes above. Is that
what you want, or should cells be directly editable by double-clicking
in normal mode, cutting the number of modes down to 2? It's very good
that we work this out now before I start!

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

Yes, I think so too. Having both table and cell properties up when
inside a cell makes sense.

This context sensitive PP you talk of, has it been made public yet?
Will it be merged to my GSoC git repo?

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

Alright. Possible other ways of navigation can be figured out later.

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

Hm. You mean the handles of the text frames being used for cell
content should be visible when a cell is selected? I would have
thought that the table wants to draw any cell selection decoration and
handles itself, to have full control over how they look. Do you also
think they should be visible for all the cells in a selected region of
cells. Will that not look cluttered?

And for cell borders, I'm not 100% sure yet if we can re-use the
border support of the text frames, or if the table will have to do the
painting of cell borders itself. I'll look into this. It will depend
on what border model we want to have i think; the CSS collapsing
border model, or something else. I'll also take a look at what border
model InDesign is using.

>
>
> hope that helps... :-)

It most certainly does. Thanks a lot for the input.

Elvis

>
> keep up the good work!
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>