[scribus-dev] Preparations for GSoC

Elvis Stansvik elvstone at gmail.com
Tue May 17 11:06:31 UTC 2011


Hi Andreas,

2011/5/17 Andreas Vox <andreas.vox at googlemail.com>:
>
> ...
>
> I'd prefer only two modes of operation: normal/selection + editing text
> We can add extra controls to table items which allow row/column resizing and
> selection. Same with context menus and shortcuts.

Right, I tend to agree. Three different modes of editing is cumbersome.

But to clarify, do you mean it should be possible to manipulate these
controls for e.g. row height and column width in normal mode or only
after entering cell text editing mode?

>
> ...
>
> My opinion: only grow/shrink cell height, but don't do that to cell width.
> That way you can just use a text frame of the given cell width and ask for
> its needed height. That's much easier than figuring out the needed width
> (especially with multiline cells).

Yes, width growing tables is a pretty obscure feature, and I only
brought it up as a side note since it's a feature of e.g. ODF tables.
But again, it is obscure, and as you say, trickier to implement than
height growing. In fact, it's only now, two years after my 2009 GSoC,
that Casper in Calligra is starting to add support for it to Calligra.

But back to height growing. It seems a.l.e. is hesitant whether we
want this at all, seeing as nothing currently grows automatically in
Scribus.

> Shrinking frame height to text height should be added to normal text frames
> as an option anyway (maybe as a vertical align option?)

Are you talking about a manual option to shrink the text frame to the
height of the text it is currently holding, or about text frames that
automatically grows/shrinks as text is entered/deleted in the frame?
Is this an officially planned feature?

And does anyone else want to chime in on this? Should I aim to make
tables that will automatically grow vertically to fit content or not?
If I do, there'll naturally be support for turning off this behavior,
or the default could be off.

Would be nice to hear what MrB thinks too, as he's my mentor after all ;)

>
> ...
>
> I wouldn't use the borders of text frames. Cell borders are more complex.

Yes, unless we want the table borders to be really primitive, the
tables will need to take care of this themselves, so I agree.

> The controls of a text frame are drawn by the current canvas mode. For table
> frames I would expect different controls to be drawn to allow resizing of
> rows/columns.

That's sounds like how I imagined it to be done.

> In edit mode I'd expect the margins/tab ruler to be displayed just for the
> current cell.

Yes.

Last night I sat down and made a "dummy" table item and pushed it to
my repo, just to see how easy/hard adding a new type of item to
Scribus is. It was quite straightforward. The item can be inserted
exactly the same way as the current table implementation, and it
currently just shows the text "I am a table". Baby steps ;)

Anyway, thanks for the input Andreas!

MrB, would love to hear what you have to say on some of these questions.

Regards,
Elvis

>
> /Andreas
>
>
> hope that helps... :-)
>
> It most certainly does. Thanks a lot for the input.
>
> Elvis
>
>
> keep up the good work!
>
> ciao
>
> a.l.e
>
> _______________________________________________
>
> scribus-dev mailing list
>
> scribus-dev at lists.scribus.net
>
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev
>
>



More information about the scribus-dev mailing list