[scribus-dev] Preparations for GSoC

[Andreas Vox]

Am 16.05.2011 um 14:08 schrieb Elvis Stansvik:

> Hi a.l.e,
> 
> 2011/5/16 a.l.e <ale.comp_06 at xox.ch>:
> ...

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

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

I'd prefer only two modes of operation: normal/selection + editing text

We can add extra controls to table items which allow row/column resizing and selection. Same with context menus and shortcuts.

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


My opinion: only grow/shrink cell height, but don't do that to cell width. 
That way you can just use a text frame of the given cell width and ask for its needed height. That's much easier than figuring out the needed width (especially with multiline cells).

Shrinking frame height to text height should be added to normal text frames as an option anyway (maybe as a vertical align option?)

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

I wouldn't use the borders of text frames. Cell borders are more complex.

The controls of a text frame are drawn by the current canvas mode. For table frames I would expect different controls to be drawn to allow resizing of rows/columns.

In edit mode I'd expect the margins/tab ruler to be displayed just for the current cell.


/Andreas

>> 
>> 
>> 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
>> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110517/193c7a99/attachment-0001.html>