[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: A little more mentoring needed
From:       Thomas Zander <zander () kde ! org>
Date:       2009-06-22 11:37:11
Message-ID: 200906221437.12632.zander () kde ! org
[Download RAW message or body]

On Monday 22. June 2009 12.33.44 Elvis Stansvik wrote:
> Hi again,
>
> I've hit a couple of snags that I'd like to bring up.
>
> I spent some of this midsummer's weekend looking at how Qt does its
> table layout, and I must say I'm a little disheartened by the amount
> of code I have to re-implement. About 700 lines of pretty complex code
> in qtextdocumentlayout.cpp seems to be devoted to table layout. I
> guess I someone naively thought that I'd get at least some layouting
> capabilities out of Qt by being QTextTable based. But no use crying
> over that, and it's nothing but my own fault for not doing enough
> research.

Yeah, lets just start small and get basic stuff working first. No cell 
spanning, no borders. Just plain table cells.

> One of the problems I've hit is that I need a way to store a table
> layout data object for each table during layout. This object is
> essentially a set of vectors with cell dimensions/positions which,
> together with the padding/margin/borders of the table/cells, will give
> me a way to get a "content" rectangle for each table cell into which I
> can direct the layout engine. These vectors will also be updated as
> the layout process progresses. E.g. cell heights will be adjusted to
> accomodate the height of the cell contents. Now, the problem is that
> QTextTable/QTextFrame lacks a user data API, so the technique used for
> e.g. blocks, which are decorated with a KoTextBlockData instance using
> the user data API, won't work for QTextTables. Qt solves this
> internally by having an internal
> QTextFrame::setLayoutData()/layoutData() API. I'm frankly a little
> lost here. I've considered storing these objects "on the side" as e.g.
> QMap<int, TableLayoutData>, but the question is then what this would
> be indexed by? The table's position in the document? Would that really
> be safe?

"On the side" sounds fine to me.
My thinking was that next to the Layout class we would have a TableLayout 
class and that is a member of the Layout.
The TableLayout will then be able to be tested separately and it can hold 
information on the table data.
The good thing is that Qt sends any text change messages to our 
KoTextDocumentLayout, which can just forward this information to our Layout, 
and that one to the TableLayout class.

Storing pointers to the QTextFrame or even to the QTextTable is safe. They 
are QObjects so you can just use a QPointer for them for even more 
convenience.

> The second problem is again about entry points in the layout engine.
> In my head, the layout/drawing process of tables would work in the
> following manner:
>
> (1) A table is found.
>     - A layout data object for the table is created and set up with
> initial values.
>     - This layout data object provides a convenience API such as
> QRectF &cellRect(int row, int col).
> (2) For each row of the table, after the content of the cells have
> been laid out, the layout data object is updated and cell heights
> adjusted.
> (3) Layout done.

In ODF there are multiple ways of determining the cell width; one is where 
its specified by the ODF, the other is you figure it out based on content.
For the second way you need to a 2-pass layout. But please ignore that for 
now.
So your strategy looks good to me.
Just make lots of unit tests to allow easy refactoring later :)

> And if a draw is requested (Layout::draw()), the tables will be
> painted according to their layout data, which after layout will be
> correct when it comes to cell rectangles and table dimensions et.c.

Agreed.

> Now I can't find any mention of QTextFrame in the layout engine at
> all. It seems that nowhere does it deal with QTextFrames directly.

In the KOffice layout code thats correct.
In Qt the gui/text/qtextdocumentlayout.cpp has layoutFrame which is called 
recursively.

> What I'd like to find (or create) is a place in the engine that I know
> will be reached on every QTextFrame entered, to be able to do a single
> qobject_cast to QTextTable and if it succeeds, do (1). I'm just not
> sure how to go about this. Layout::nextParag() seems like it is the
> primary entry point in the Layout class, but it deals exclusively with
> individual blocks, and not frames.

I think the overall design can be tweaked a lot later, lets focus on basic 
functionality first :) Perfection being the enemy of productivity and all.
I suggest to just add to the nextParagraph() method a;
 QTextCursor frameFinder(newBlock);
 QTextTable *table = frameFinder.currentTable();
 if (table != m_tableLayout->currentTable()) {
   m_tableLayout.setCurrentTable(table);
 }

This implies the introduction of the m_tableLayout member as something like 
TableLayout class in the plugin. This class would then manage the table 
info.

> These are my biggest hurdles at the moment, and I'd really like to get
> some help/feedback here, because it's these dead ends I keep running
> into that cost me too much time. Time that I really don't have if I'm
> going to have something to show for the midterm evaluation.

Yes, please do continue asking questions!
You know that the prime think in GSoC is communication and working together 
and something that is maintainable afterwards. The code quality itself is 
secondary.

> I also know there's a lot of pressure to get tables done before 2.1,
> and that there's probably those of you who did not agree with giving
> such a big job to someone not well versed in the layout code. 

Don't worry, I don't expect more than basic tables and a good start of a 
framework. (which is what your GSoC application said)

> But
> better try to make the best of it instead of fretting over that. And I
> like pressure, as long as you stay positive. Keeps me on my toes :)

Uhm, ok :)

> Looking forward to some answers, and please point out if there's
> something that is just wrong, bad design or misconceived in the above.

If you want we can schedule a skype meeting.
Hope these answers help.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]