[scribus-dev] Preparations for GSoC

[a.l.e]

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.



> 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