[scribus-dev] Preparations for GSoC

[Elvis Stansvik]

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:

http://wiki.scribus.net/wiki/images/4/4e/Resizing_table_workflow_mockup.png

Elvis

>
>
>
>> But anyway, I feel that things are starting to crystallize more now.
>> And a lot of good has come out of this thread.
>>
>> > and yes, i was writing about a right click for a context menu...
>> > but -- as for every function in scribus -- you will find the same
>> > command also in the main navigation.
>>
>> Hm, yes. But this state where the gray area is shown, it feels like a
>> transient (temporary) state only visible right after the user has
>> requested a resize of a table by dragging its corners. Should menu
>> actions related to such a contextual/transient action really be
>> visible somewhere in the main menus of Scribus? I'm not sure.. But
>> anyway, these are details for later I think.
>
> the gray area is shown until the user has not set the cells size to fill the table size (and a warning is issued in the preflight verifier if the user does not so)
>
> the user can also manually change the sizes to fill the table area (or not to so, if she does not want it).
>
> that's the way i see it working :-)
>
> i agree that it's not the way most program do work, but it would finally be a way that works for me! :-)
> no more fights to get the correct result when resizing a table.
> (to the defense of the other apps: there is no one correct way to handle the table resizing. it all depends on the content of the columns and rows!)
>
> ciao
> a.l.e
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>