[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

2011/5/18 Elvis Stansvik <elvstone at gmail.com>:
> 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?

Here I mean "resizes the table _frame_" of course.

Elvis

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