Andre Poenitz wrote:
On Wed, Mar 19, 2008 at 12:33:20PM -0400, Richard Heck wrote:
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.
Could this 'InsetTableCell' just be an extended InsetText containg the
other data members of the current CellData?
That was kind of what I had in mind at one point, and it may be that
this is the best solution in the longer term: To have a Tabular
basically be a matrix of InsetTableCell objects rather than of CellData
objects, each of which embeds an InsetText. But I absolutely do not
understand the Tabular code well enough to even want to try to do this.
And the current problem we face doesn't, I think, require it.
In fact, I'm now thinking---see my other message---that there's actually
an easy way to do this: Create an InsetTableCell that is a pretty
trivial subclass of InsetText but that contains a reference back to the
CellData, and use it where we're now using the InsetText; it'll also
have its own code, solving a different problem, and it will override
forceEmptyLayout() and the like, but otherwise just pass everything to
InsetText. CellData already has the copy and assignment constructors
needed to make this work, I believe; we just need to reset the reference
to CellData in these cases.
rh
