[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

2011/5/19 Elvis Stansvik <elvstone at gmail.com>:
> 2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
>> hi elvis,
>>
>>> >> Now that I think about it, you probably meant the menu should be
>>> >> visible directly on this gray area, without the user having to
>>> >> right-click? Then it's a little better, but it's still a pretty
>>> >> advanced feature. But I like playing with crazy ideas ;)
>>> >
>>> > you got it 100% with your schema!
>>> >
>>> > shrinking the table won't be as "nice"... but should also be doable.
>>>
>>> Alright, but then I guess you mean that the user would confirm these
>>> choices somehow (distribute vs. giving explicit sizes to rows columns)
>>> for the table size change to finally take effect? It feels like a bit
>>> much work for the user for just changing the size of a table. Or
>>> rather, it feels like a power feature, and one that diverges quite a
>>> lot from established ways of working with tables in other software.
>>> But of course it's good to be open to new innovative ideas, so I'm not
>>> saying I'm completely against it.
>>
>> personally, i'm mostly struggling with the way most software handles table resizing...
>> (i admit that i don't work much with tables, though... and that i avoid resizing them!)
>>
>> however, no, the user should not confirm each choice. here a typical workflow:
>> - the user creates a table with equal width columns / rows (or by defining custom measurements in the insert table dialog)
>> - she can interactively resize columns and rows
>>  (btw, what happens if she shrinks the height of a row? do the other rows grow? does the whole table shrink? there is no correct way to handle this: i think this also a case for the gray area...)
>> - at some time later she resizes the table to a new size
>> - the cells are not resized
>> - once the user is sure of the new size, she choses among four ways of solving the "issue" by using the context menu (or the main item menu):
>>  - resize each cell proportionally (depends on the current size),
>>  - resize each cell by the same amount each
>>  - resize only one column / row
>>  - resize the table to fit the cells (horizontal / vertical) size (goes back to the previous state)
>>  those context menu items could appear when you right click on a table and the cells don't fill the table frame.
>
> Inspired by your ideas, I made a mockup of a similar workflow for
> resizing tables that I think could work out:

Some more notes/observations about this:

1) By default, row heights would never shrink below the size of the
cell content, but we could have a table (possibly row) property "Allow
cell frames to overflow" to allow this.
2) With this way of working, table size, both width and height, is
completely detached from frame size. They are not linked in any way.
However, we could have options similar to those for images: "Adjust
Frame to Table" and "Adjust Table to Frame". The latter would show the
same options for distributing the space as shown in the widget in the
mockup.
3) If the user has picked e.g. "Proportional" for distributing
horizontal space, but then starts resizing columns anyway, the combo
in the widget could automatically go to "Manual", as a convenience.

I believe this could work out quite well. A DTP user will know the
exact space she wants to give the table frame on the page, but this
workflow will help her distribute the space of the frame to the table
in an easy way, while still giving her full control if she needs it.

Elvis