Am Sonntag, dem 02.03.2025 um 21:08 +0100 schrieb Jean-Marc Lasgouttes:
> This one is for Jürgen. Coverity states it very clearly: "Local
> variable
> change_drawn is assigned only once, to a constant value, making it
> effectively constant throughout its scope. If this is not the intent,
> exami
Dear all,
This one is for Jürgen. Coverity states it very clearly: "Local variable
change_drawn is assigned only once, to a constant value, making it
effectively constant throughout its scope. If this is not the intent,
examine the logic to see if there is a missing assignment that would
make
On Fri, Mar 21, 2008 at 05:02:23PM +0100, Abdelrazak Younes wrote:
> Longer term, the text and math tabular code should be merged. We talked
> about that in the past following the last LyX meeting IIRC, see the
> archives.
More precisely: We talked about that during each and every of the
LyX mee
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
ref
ere are
>>> better ways to do this, longer term, but I am NOT about to start messing
>>> with the InsetTabular code in any serious way. The list of names at the
>>> start of InsetTabular.cpp is enough to scare me off for good. ;-)
>>>
>>> Comments welco
InsetTabular.cpp is enough to scare me off for good. ;-)
Comments welcome.
I would have prefered if the InsetTableCell and the CellData were
combined in a single class (assumng they were always 1:1) and the
whole stuff located in InsetTabular.cpp instead of a separate .h/.cpp
file
es at the
> start of InsetTabular.cpp is enough to scare me off for good. ;-)
>
> Comments welcome.
I would have prefered if the InsetTableCell and the CellData were
combined in a single class (assumng they were always 1:1) and the
whole stuff located in InsetTabular.cpp instead of a s
uot;
+#include
+
+namespace lyx {
+
+
+///
+class InsetTableCell : public InsetText {
+public:
+ ///
+ explicit InsetTableCell(Buffer const & buf,
+ Tabular::CellData const * cd, Tabular const * t);
+ ///
+ virtual InsetCode lyxCode() const { return CELL_CODE; }
+ ///
+ Inset * clone() { re
On Wed, Mar 19, 2008 at 02:19:09PM -0400, Richard Heck wrote:
> 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
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 up
hing 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&#
Juergen Spitzmueller wrote:
Richard Heck wrote:
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
Richard Heck wrote:
> 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 Cell
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
ref
Richard Heck wrote:
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 mu
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
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 nea
17 matches
Mail list logo
