[scribus-dev] Preparations for GSoC

[a.l.e]

hi elvis,

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

we should be able to copy paste any type of item into a text frame and 
use it as an inline object...

so, defining tables as "real" items just opens up new chances :-)
(and i hope that most people will want to create tables as real items!)



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

this is the best you can currently read about the scribus-oif project:

http://ospublish.constantvzw.org/news/scribus-re-loaded

a part of the PP redesign is to get it as a single panel window (but 
split in frame and content properties)

part of it is already in 1.5svn. part of it is in the 1.5 oif branch

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

in my mind 1 and 2 were mostly merged... but i didn't spend much to make 
my mind :-)

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

alt for moving windows should be deprecated!
the window key is much better for it.

you have to switch them also for inkscape...

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

alt+shift and alt+ctrl?


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

me? not grow.

if somebody wants autogrowing tables, he should do them in oo/lo and 
then have a way to import in a native scribus table.

just like he's dong with text.

DTP is about control... or not?


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

if we can find a way to edit all the properties with only two modes, i'd 
prefere that.

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

jean ghali is working onn it

the idea is public, but not much publicity has been made about it, yet 
(beside of the talk by jean and pierre last week at the lgm... which 
will be online at some time in the future...)


ciao
a.l.e

p.s.: i wrote this post yesterday... but then got some distractions...