Stefan Schimanski wrote:
Am 09.03.2008 um 16:04 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Am 09.03.2008 um 15:03 schrieb Abdelrazak Younes:
Stefan Schimanski wrote:
Hi!
Can anybody summarize the situation and issues to switch to
InsetMathMbox?
This would be the solution for all text in math purpose. There are
a number of bugs related to the fact that text in math are not real
Text object.
Last time I tried, InsetMathMbox needed some work in order to be
complete; essentially metrics and drawing code.
Having this in 1.6 would be a great step forward.
I am playing around with it. The main problem right now is that Text
objects need a buffer object assigned, e.g. for Text::write. Some
math macros use mbox insets, but they are buffer independent (=
global). I just tried to create a dummy Buffer for those cases, but
get some crashes now.
No, you should instead implement Inset::setBuffer() in the proper
math inset (the one that contains the InsetMathMbox).
This buffer variable in every inset is a mess. I still don't like the
idea at all. It changes the ownership of insets from MathAtom
effectively to the buffer. The consequence is that we cannot have
insets anymore independently from the Buffer,
I think you still can, that's still the case for simple insets like
InsetMathChar or the formatting insets for example. The question is why
would you want to use an Inset independently from a Buffer?
or at least we cannot use all of the functionality of an inset if it
is not assigned to a buffer.
Well, that's a chicken and egg problem: you don't want to use a
functionality that requires a Buffer.
And even worse, it is not defined anywhere which functionality might
depend on the assigned buffer.
You have a point here and that's why I proposed to enforce that
dependency in the constructor instead of using setBuffer(). Andre' has
started some work along this path IIRC.
Spreading setBuffer calls around the LyX code is not elegant either.
The compiler cannot tell us where we forgot to do it, or where an
inset has a buffer variable, but to an old/different buffer.
Right, the Buffer passing in the ctor is then the solution. setBuffer()
should then become private and CutAndPaste methods would have to be
declared friend.
What does it buy us after all other than some "Cursor & cur" arguments?
It was a bit more "some" and there was also something related to Macro
IIRC, Andre' knows the details.
I am trying to get the InsetMathMBox working and hit several problems
with this change. The text inset depends on the Buffer variable
unfortunately and the mathed insets do not have it set. The problem
appears especially when mbox appears in math macros. Which Buffer do
the global math macros belong to?
Hum, if a macro does not need a Buffer, than let's make it independent
from a Buffer.
What about cases like asArray/asString? We need to set the buffer
there as well, also in the parser in general.
Yes, and this Buffer information would have been required anyway. At
Macro instantiation, the difference is that instead of passing it the
Buffer, you have to retrieve it from the context in which the macro is
used. That context is the containing InsetMathHull, isn't it?
A bit frustrated :-/
Don't be, contrarily to you, I have the feeling that this Buffer in
Inset change enables us to really think about what goes to where.
Abdel.
