On 07/15/2009 10:40 AM, Jean-Marc Lasgouttes wrote:
lasgout...@lyx.org writes:
revert r30531, which causes a crash when copying an inset.
Basically, insets in cut stack do not have a buffer, and therefore cannot
access to buffer parameters. What is annoying here is that acceptChanges
requires this buffer params only to be able to read a font in moveItem,
in order to read the buffer language, and I doubt this is really needed...
Another change in this patch is that Inset::getLayout now returns a
plainLayout when the inset does not have a buffer_. This fixes a remaining
crash where dEPM reads isFreeSpacing() for an inset in the clipboard, but
this looks like a fragile situation. And it will not do the right thing when
doing depm in a freespacing inset.
The fact that we use the buffer_ member of insets for getLayout()
creates more situations where insets are not treated in the right way. I
am not sure how we can get out of this situation. A solution would be to
add a Inset::getLayout(Buffer) method, but this still feels like a hack.
Thoughts?
I guess I'm wondering why we are performing these sorts of operations on
things in the cut stack. Conceptually, it ought to be nothing but a
place to store things. Are we using the cut stack for purposes for which
it was not perhaps intended? To put it another way: Why are we doing
things that require reference to a buffer (or to the params of a buffer)
to things that don't have a buffer associated with them?
Richard
