Am 03.02.2016 um 10:20 schrieb Jean-Marc Lasgouttes:
OK, I'll try to have a go at it.
Thanks for having a look.
The problem is that every time I look
at this box code, my eyes bleed:
* type as a string instead of enum
I have not invented this. Why is important how a parameter is stored? If
it is important to use an enum, why was/is this then not used when the
box inset was created?
* special length as string instead of properly extending the Length class
* articificial use_parbox, use_makebox, inner_box parameters that have
to be set in a very precise manner in fragile code that I am not able to
follow.
It is not artificial. What do you find artificial? LaTeX is very
complicated here (some box types allow widths, some not, some boxes
allow to change more parameters than others...)
I can add comments to make it more clear why we do what we do.
I know this has been done to introduce features that are "important to
the user", but at some time, sanity is nice too. The insetbox parameters
should describe what we think the box is, not how LaTeX output is going
to happen.
Could you be more precise. What do you mean? To understand the logic of
the code one must know how LaTeX works - why \fbox\parbox is a different
to \parbox\fbox. Or how do you like to name a framed minipage with a
surrounding shadow box?
With that out of my chest, here is an actual question:
But in this case a makebox must be used. This is already handled
in the box dialog. The bug is that it is not yet handled if the box
changing commands are executed via the context menu.
Can you point me to the relevant code in GuiBox.cpp?
It is
void GuiBox::setInnerType(bool frameless
Additional question: what is this
else // if (for_box)
line about?
I also don't understand this comment too. In my opinion it can be
removed because there are only 2 cases:
- the box type was changed
- the box type was not changed so that the parameter set can be used as
it was given.
regards Uwe
