[scribus-dev] Tables GSoC - Weekly Report #5

[Elvis Stansvik]

2011/7/5 Andreas Vox <andreas.vox at googlemail.com>:
>
> Am 05.07.2011 um 18:56 schrieb Elvis Stansvik:
>
>> 2011/7/5 Craig Bradney <cbradney at zip.com.au>:
>>> On 7/5/11 1:43 PM, Elvis Stansvik wrote:
>>>
> ... let's shorten this a little :-)

Good idea ;)

>
>>>
>>> == Problems / Questions ==
>>> My biggest question right now is:
>>>
>>> * What should be the general approach for integration of text frames?
>>> The table will hold a set of text frames for its cells, but then? The
>>> user should be prohibited from doing certain things to the text
>>> frames, such as selecting and resizing them. This should be handled by
>>> the table. In a way they will be similar to locked text frames, until
>>> the user decides he wants to edit their content. Should I go for an
>>> approach where I add a bool isTableCellContent() or similar to
>>> PageItem_TextFrame? Or should PageItem_TextFrame even be inherited,
>>> creating a new item for cell content? I'm open to all ideas, so if you
>>> happen to have given this problem some thought, please share, because
>>> frankly I haven't (yet).
>>>
>>> == Next Week ==
>>> I'll yet again be working on catching up with my schedule, which means
>>> working on integration of text frames and basic UI. Since mid-term
>>> evaluation is next week, perhaps I should also write some kind of
>>> mid-term report. What do you think Craig, do you think its worthwhile
>>> or just a waste of coding time? Perhaps you feel up to date enough
>>> with my status. I also really should get around to making another blog
>>> post showing the new features, as I've only made one post so far.
>>>
>>>
>>>
>>> All in all, its very impressive. I'll catch up with you on IRC though.
>>
>> Great.
>>
>>> For frames.. remember we need to allow images (etc) in cells too.. so
>>> considering that is important when deciding on a method. I suspect a cell
>>> frame type is going to be required to inherit what is needed (only). You may
>>> even find (I suspect this to be the case) that you don't actually want all
>>> the mess/history that comes with text frames.
>>
>> Right. For cell background images, I imagined these will be drawn by
>> the table painter, same as for cell fills. I could take a look at the
>> image frame for inspiration. With "(etc)", what did you have in mind
>> more specifically?
>>
>> Regarding mess/history of text frames, do you mean to change tactic
>> and not use text frames at all? Or just that only parts of them should
>> be reused? How separate is the text layout engine of Scribus from the
>> text frame page item type? Is there an easy way of telling the text
>> layout engine "here, layout this text in this rect"? But then, I'd
>> lose a lot of text user interaction code that has gone into the text
>> frame page item and its associated canvas mode, wouldn't I? I feel I
>> really need to do some investigation of these parts of the code..
>
> Right now it's not easy to separate the text layout code from pageitem_textframe.
> This is  done in the OIF branch, though, so the question is if it's advisable to
> hack the old code to work with the new tables.

I see.

> Currently each pageitem_textframe has  a storytext (named itemText). StoryText is two-part:
> one part for the text data which is shared between all linked textframes in a chain
> and a layout part which exists for each textframe.  Text editing code is spread over
> canvasmode_edit, scribusview and probably other classes (= historic mess).

Right. It's too bad it's spread out like that, but that's what I feared.

> In the OIF branch storytext holds only the text data; the layout is split into a separate
> layout class which is based on a box model similar to TeX. These boxes allow
> layout independent of pageitems and any UI elements. In particular they offer methods
> to request the bounding box of a range of characters and to map an (x,y) position
> to a character index.

Sounds like a well thought out and needed design improvement.

> All editing code should eventually move into canvasmode_edit (or even a new canvasmode_textedit).

Sounds good.

> My gut feeling says right now it would be best to use a slaved textframe for each table cell,
> which is not known to the rest of scribus and use that for text layout only. Then rewrite the
> editing code for tables from scratch: just insert/delete chars at the correct position, re-layout
> and render.

This is also what I had in mind when it was first decided that text
frames should be used for cell content, to actually create a bunch of
text frames, but hide their "true nature" from the rest of Scribus.
Using text frames like this has a hackish vibe to it, but that was
known from the start.

Though perhaps I had some little hope of being able to reuse actual
(interactive) editing code. But I'm glad you seem to think re-writing
the editing code for table cells is doable.

> You would have a storytext for each table cell, too. For saving you could probably use the existing
> code and use additional attributes to link the storytext to the correct table cell.

Makes sense.

> I wouldn't bother with the story editor, though.
> Using story editor for editing single table cells is no fun and adapting story editor for tables is
> a no-no: story editor has to die soon, anyway.

Okidok.

> IMHO it would be acceptable if editing text in tables is suboptimal for now. We should put the effort
> into getting it right with the OIF code.

Ah this fabled OIF code, when will I see it? :) On a more serious
note, just what you described above seems like a huge improvement.

Thanks a lot for the input, it's exactly these kinds of gut feelings
et.c. from more experienced team members I'm after with my questions.

Elvis