[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

Hi a.l.e.

2011/5/18 a.l.e <ale.comp_06 at xox.ch>:
> hi
>
>> While summarizing the thread, I also came to think of another thing;
>> how do we want the table width to react when the table frame is
>> resized? Should it follow the frame width, or should the width of the
>> table be completely independent of the frame width? Or should there be
>> something similar to what we have for images ("To Frame Size" in the
>> Scaling properties)?
>>
>> And should there be no way for the user to resize both the width and
>> height of the table and have the row heights and column widths follow
>> proportionally? Isn't that a valid use case?
>
> personally, when i create a table there are good chances that i want to have full control on the size of the cells. this is even more true in a DTP context.
>
> i won't define the cells one by one, but i will tend to have a fixed width for the columns and a fixed height for the rows (not all the rows and columns being equal, of course... but probably most of them).

Yes, I imagine this is the most common way of working and of course we
should support that.

>
> so, to me, it's very important to be able to easily redefine widths and heights. on the other hand, an automatic resize will rather make my work harder than facilitate it.

I did not mean for this to be the only way of resizing a table of
course. It's just that I see that it's the default behavior when
resizing a table by dragging it's corners in InDesign; both rows and
columns are scaled proportionally.

Imagine that you had gone through the process of setting up the widths
and heights of the columns and rows like you describe, but then
realize that you need the table just a little bit bigger; without this
feature you would then have to individually make each row and column
slightly bigger. So I think we should at least consider having the
feature, perhaps not the default behavior, but still possible.

Now why I asked was more because I wonder how this will be implemented
as Scribus' tables will be different in that their bottom edge will
not follow the bottom edge of the frame. So how do we give the user
the ability to scale the entire table?

What do you imagine should happen to the table when the user resizes
the table by the way? Nothing? Or should it adapt it's width to the
frame width?

I'm starting to think that nothing at all should happen actually, and
that we should just have an "Adjust Frame to Table" option such as
that available for images.

Then table resizing would be strictly done "inside" the frame, it's
corner could be grabbed to resize it, and with a modifier the
proportional behavior could be enabled, while the default would be to
just resize the last row and column.

>
> of course, there should be an easy way to import tables from *office (where the cells automatically grow) and it should be possible to make the cells fit from the scripter (for tables created from csv files; and we already have a way to test for overflowing text...).

Yes, I understand you favor that rows don't grow automatically, so I
think we should support both auto-growing and fixed. Perhaps I'll
start with the fixed behavior, as that will be easiest to implement.

> finally, when the table is resized, i'd prefer to see a "gray" area which invites me to resize the columns or the rows (i could imagine a context menu on the "gray" area which lets me equally or proportionally distribute the exceeding / missing width to each column or resize just one specific column).

Hm, a context menu on a "gray" gray are seems hard to discover to me
and not very intuitive. But perhaps I'm just not understanding you
right here. Let me make a picture... *makes picture*. Check the
attached picture, is that what you meant? If so, I'm not so sure about
the usability of that..

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

> and, of course, this is my own personal opinion!

Of course ;)

Elvis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ale_idea.png
Type: image/png
Size: 48051 bytes
Desc: not available
URL: <http://lists.scribus.net/pipermail/scribus-dev/attachments/20110518/f5e9681a/attachment-0001.png>