Stefan Schimanski wrote:
Am 19.03.2008 um 17:11 schrieb Richard Heck:
So, it seems to me that fixing "our most embarrassing bug" is going
to require doing something that maybe ought to have been done before,
namely, introducing an InsetTableCell that will contain a pointer (or
reference) to the associated CellData. Doing that much is near
trivial---InsetTableCell itself will override but a handful of
InsetText's methods---but I'm guessing this pointer will need
updating whenever the cell is copied or, at least, whenever the
CellData is copied. So one possibility here would be to write copy
(and assignment?) constructors for CellData. Is there any easier way
to do this than manually to copy all of the member data?
Here's another possibility. s/CellData/CellInfo/g, and then:
class CellInfo {
CellData cell_data_;
InsetTableCell itc_;
CellInfo(CellInfo const & ci) {
cell_data_ = ci.cell_data;
itc_ = ci.itc_;
itc_.cellDataPtr = cell_data_;
}
etc.
}
A handful of other changes, too, of course, but the idea obviously is
to wrap the data and associated inset in the CellInfo class and then
deal with the copy constructor more easily.
Will the InsetTableCell show up in the cursor as another slice? Or is
it just to get some functionality from InsetText?
Right now, each cell has an associated InsetText that contains the
cell's data. It's a member of CellData, and the table itself represents
its cells as a vector<CellData>. So not that much would actually be
changing in the code; the idea is just to replace the InsetText that is
already there with an InsetTableCell that would contain a pointer back
to the associated CellData, so we can find out, in particular, whether
our width has been explicitly set or is still default.
That might not be the idea solution, long term. I don't know nearly
enough about the tabular code even to have an opinion about that.
rh
