<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>Am 16.05.2011 um 14:08 schrieb Elvis Stansvik:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hi a.l.e,<br><br>2011/5/16 a.l.e <<a href="mailto:ale.comp_06@xox.ch">ale.comp_06@xox.ch</a>>:<br><font class="Apple-style-span" color="#006312">...<br></font></div></blockquote><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Something that comes to mind is that for most items Scribus uses a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">modal way of interacting with the item: In the "normal" mode, the user<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">is able to select, move and resize an item, while in the "editing"<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">mode (entered by double-clicking) he/she is able to perform editing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">actions on the item, such as inserting text in text frames, or moving<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">vertices of a polygon. Is this modal way of working something we want<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for tables as well, in order for them to fit in with the Scribus way<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">of working? If so, I'm guessing actions such as column/row resizing<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">should be available in the "editing" mode, while in the "normal" mode<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the user is only able to move/resize the table?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">probably, yes, we should keep the modal way of working.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">there were some discussion on changing this behavior for text and image<br></blockquote><blockquote type="cite">frames, and the result was that it's not a bad idea to keep the current<br></blockquote><blockquote type="cite">state (it can help prevent accidental change; on the other side manipulation<br></blockquote><blockquote type="cite">can be a bit slower...)<br></blockquote><blockquote type="cite">in my eyes, the most important thing is, that the program behaves in a<br></blockquote><blockquote type="cite">consistent way: if we want cells to be "always" resizable, we should plan<br></blockquote><blockquote type="cite">also to change the behavior for text and image frames.<br></blockquote><br>Yes, consistency is worthwhile, and why I brought it up. I also think<br>tables should have an editing mode in which operations such as<br>resizing/adding/removing of rows/columns is performed. I don't know if<br>I explained my concern over multiple layers of modality good enough<br>though, but more about that further down.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">=== Styles ===<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">A while ago I took an afternoon and investigated what it takes to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">create a new kind of style in Scribus, thinking this is something we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">might want for tables. It was mostly straight forward and I ended up<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">with a primitive skeleton of a new style which is now in my Git repo.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Since then however, I've started thinking; Are styles for tables (and<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">even for rows/columns/cells) something we really want, or are they an<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">unnecessary complication for small benefits?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">basically, i think that we would like to get styles for as many things as<br></blockquote><blockquote type="cite">possible. frame styles are (somehow) already planned...<br></blockquote><br></div></blockquote> +1</div><div><br><blockquote type="cite"><div>Yes, and after my slightly embarrassing ignorance of the fact that<br>InDesign actually has a quite comprehensive support for table and cell<br>styles in my initial post (corrected by Leonard above) I must agree,<br>and will make sure Scribus supports this too.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">I'm guessing we want cell selection to work similar to word processors<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">and Indesign, where a user is able to enter a "cell selection" mode by<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">starting to select some text in a cell with the mouse and then<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">dragging outside the cell boundaries?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">in scribus you go to the "normal" mode to edit the container... i guess we<br></blockquote><blockquote type="cite">should keep this behavior...<br></blockquote><br>Yes, but this is where my concern over multiple layers of modality<br>come in. Do I understand you correctly that you actually want one<br>three modes of operation:<br><br>1) Normal Mode: The user is able to select, move and resize the table.<br>2) Table Editing Mode: The user is able to insert/remove/resize rows<br>and columns.<br>3) Cell Editing Mode: The users is able to edit cell content.<br><br>And if so, in which mode, 2 or 3, will the user be able to select a<br>rectangular region of cells by mouse-dragging? As you probably know,<br>in word processors and in InDesign, doing this is a matter of starting<br>to select a span of text in a cell and then going outside the cell,<br>which will enter a cell selection mode where a region of cells is<br>selected. This would be equivalent to cell selections being done in<br>mode 3 above (the innermost mode). The alternative is letting the user<br>do this in mode 2. With that approach, individual cells would then be<br>directly selectable by just clicking them, and a region of cells by<br>click-dragging.<br><br>In addition to selection of individual cells and rectangular region of<br>cells, we need selection of rows and columns, and I guess this will<br>work in mode 2 just like it does in word processors, the mouse cursor<br>will be changed to an arrow pointing right when hovering the left edge<br>of a row, and an arrow pointing down when hovering the top edge of a<br>column. Upon click the entire row or column will be selected,<br>respectively.<br><br>Or maybe you had something else in mind than these three modes of operation?<br><br></div></blockquote><div><br></div><div>I'd prefer only two modes of operation: normal/selection + editing text</div><div><br></div><div>We can add extra controls to table items which allow row/column resizing and selection. Same with context menus and shortcuts.</div><br><blockquote type="cite"><div><blockquote type="cite">the question is how to best select the elements... i tend to like the<br></blockquote><blockquote type="cite">current alt-click, but we should better document how to get the window<br></blockquote><blockquote type="cite">managers not to capture the alt-clicks.<br></blockquote><br>Ah, now I see what you mean. I was honestly not aware of the Alt<br>modifier to select items inside a group (is it used for something else<br>as well?), as I'm so used to having Alt for moving windows.<br><br>Perhaps in addition to the cell selection behavior I explained above,<br>we could allow the user to, while in the normal mode (mode 1), select<br>individual cells by Alt-clicking. But I'm pretty sure that somewhere<br>we need to give the user the ability to select a rectangular region of<br>cells.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">=== Notification of Text Overflow in Text Frames ===<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Using text frames for cell content means the table will have to be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">notified when overflow occurs in a text frame, to be able to correctly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">re-layout the table starting from the row in which the overflow<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">occurred. If we eventually want to have width-growing columns, we'll<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also need a way to be notified when a line break is about to occur in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">a text frame. So the question is; do text frames currently emit any<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">signals to indicate that content is overflowing? It seems they are<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">not, but one place where such a signal could possibly be emitted is in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">PageItem_TextFrame::DrawObj_Decoration (around line 2720). It might<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">not be a correct solution though, perhaps the table should instead<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">listen to insertions being made in the text frame, and query the frame<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for its overflow state using PageItem::frameOverflows()?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">do we want the cells to automatically grow?<br></blockquote><blockquote type="cite">in scribus, nothing automatically grows...<br></blockquote><br>Well I've just assumed that we want this as it's how almost every<br>other table I've ever seen works, but indeed, nothing automatically<br>grows in Scribus. Naturally non-growing behavior should be supported<br>even if auto-growing is implemented. But what do you other guys think?<br>Grow or not?<br></div></blockquote><div><br></div><div><br></div><div>My opinion: only grow/shrink cell height, but don't do that to cell width. </div><div>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).</div><div><br></div><div>Shrinking frame height to text height should be added to normal text frames as an option anyway (maybe as a vertical align option?)</div><div><br></div><blockquote type="cite"><div><br><blockquote type="cite"><br></blockquote><blockquote type="cite">text overflow can be queried from the scripter, you can go there to find out<br></blockquote><blockquote type="cite">how to do it :-)<br></blockquote><br>Good tip. After writing my initial mail and that wiki page, I realized<br>that some of what I said was non-sensical, as I was suggesting to emit<br>signals for this inside the decoration drawing method of PageItem,<br>which doesn't make sense. Listening to text insertions and then<br>querying the item for overflow is probably the way to go.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">In addition to being notified of when overflow happens, the table will<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also need to be able to query the text frame for the height of its<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">content, to be able to resize it correctly during table layout. Is<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this possible using the current API? If not, what would it take to add<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">it's not done and i'm not 100% it's a good idea to implement it...<br></blockquote><blockquote type="cite">it will certainly be helpful for newcomers (but what will they think when<br></blockquote><blockquote type="cite">the page is filled and there is no place for growing the frame? should we<br></blockquote><blockquote type="cite">automatically create a new page? ask for it? ... not sure it's a good<br></blockquote><blockquote type="cite">idea...)<br></blockquote><br>Hm yes. I guess it would just grow and the user would realize that his<br>table doesn't fit the page and cope with it. But I see your point.<br><br>If you really don't want rows and tables to automatically grow, you've<br>cut a good chunk out of the table layout logic out of my work :)<br>Again, what do you other guys think? MrB?<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">=== Editing of Cell Content ===<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">As the text frames have their own modal way of being edited, and on<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">top of that we'll probably have a modal way of editing tables (see<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">above under Interaction Questions), how will we combine the two when<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">it comes to editing cell content? I really don't think we want a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">multi-layered modal interaction, where the user first has to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">double-click the table, and then again double-click a cell in order to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">edit its content.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">double clicking a cell should start the edit mode.<br></blockquote><br>Okay, but related to my questions regarding the 3 modes above. Is that<br>what you want, or should cells be directly editable by double-clicking<br>in normal mode, cutting the number of modes down to 2? It's very good<br>that we work this out now before I start!<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">the question is how to find the context in the modal editing... imo we could<br></blockquote><blockquote type="cite">have both in the PP (table / cell)<br></blockquote><br>Yes, I think so too. Having both table and cell properties up when<br>inside a cell makes sense.<br><br>This context sensitive PP you talk of, has it been made public yet?<br>Will it be merged to my GSoC git repo?<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On top of this is the question of keyboard navigation between cells,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which I'm sure we want. The table will probably have to somehow filter<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the keyboard events before they hit the underlying text frame of the<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">cell in order to get this to work.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(shift) tab should be captured and used as next cell...<br></blockquote><blockquote type="cite">not sure if we want other navigation keys...<br></blockquote><br>Alright. Possible other ways of navigation can be figured out later.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">=== Disabling Decorations / Resize Handles of Text Frames ===<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I will have to figure out how drawing of decorations, and possibly<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">also the resize handles of text frames can be disabled. The table will<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">only be interested in the text displaying / editing capabilities of<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the text frames, and will not want them to draw anything else such as<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">borders, decorations or resize handles. Perhaps this is an easy thing,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">but still something I'll have to investigate.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">i think that it should work in the same way as for text frames...<br></blockquote><br>Hm. You mean the handles of the text frames being used for cell<br>content should be visible when a cell is selected? I would have<br>thought that the table wants to draw any cell selection decoration and<br>handles itself, to have full control over how they look. Do you also<br>think they should be visible for all the cells in a selected region of<br>cells. Will that not look cluttered?<br><br>And for cell borders, I'm not 100% sure yet if we can re-use the<br>border support of the text frames, or if the table will have to do the<br>painting of cell borders itself. I'll look into this. It will depend<br>on what border model we want to have i think; the CSS collapsing<br>border model, or something else. I'll also take a look at what border<br>model InDesign is using.<br><br></div></blockquote><div><br></div><div>I wouldn't use the borders of text frames. Cell borders are more complex.</div><div><br></div><div>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.</div><div><br></div><div>In edit mode I'd expect the margins/tab ruler to be displayed just for the current cell.</div><div><br></div><div><br></div><div>/Andreas</div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">hope that helps... :-)<br></blockquote><br>It most certainly does. Thanks a lot for the input.<br><br>Elvis<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">keep up the good work!<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">ciao<br></blockquote><blockquote type="cite">a.l.e<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">scribus-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:scribus-dev@lists.scribus.net">scribus-dev@lists.scribus.net</a><br></blockquote><blockquote type="cite"><a href="http://lists.scribus.net/mailman/listinfo/scribus-dev">http://lists.scribus.net/mailman/listinfo/scribus-dev</a><br></blockquote><blockquote type="cite"><br></blockquote><br>_______________________________________________<br>scribus-dev mailing list<br><a href="mailto:scribus-dev@lists.scribus.net">scribus-dev@lists.scribus.net</a><br>http://lists.scribus.net/mailman/listinfo/scribus-dev<br></div></blockquote></div><br></body></html>