Andre Poenitz wrote:
>
> My last patch gives us an almost working 'real' \mbox inset for
> mathed I.e. creation and editing works, but nothing I/O related.
>
> The reason for this is that mathed and texted still use different
> I/O schemes (I don't mean the format here, but mainly the signatures
My last patch gives us an almost working 'real' \mbox inset for mathed
I.e. creation and editing works, but nothing I/O related.
The reason for this is that mathed and texted still use different I/O
schemes (I don't mean the format here, but mainly the signatures of
I/O functions).
In mathed we
On Mon, Feb 16, 2004 at 11:03:39AM +0100, Andre' Poenitz wrote:
> This brings tabulars back from zombie state to 'staggering zombie'
> state. Left/Right should work, even (partially) with selection, up/down
> crashes (most of the time...)
I forgot to add: This also removes almost all of the remain
#x27;proper' LFUN handling in the
individual math insets (currently, MathNestInset catches all cursor
movement and diverts them to LCursor math specific code. No good IU...]
Andre'
1.diff.gz
Description: application/gunzip
Angus Leeming wrote:
> So, I'll keep on mentioning it why I notice too.
s/why/when/
A
Andre Poenitz wrote:
> This is possible, and actually close to my prefered way out.
> (Actually I'd prefer
>
> string getPossibleLabel(LCursor & cur, LyXText & text)
>
> over of your 'finer grained' version as this produces less clutter
> in the user code (no need to use .paragraph() in
On Fri, Feb 13, 2004 at 01:27:36PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > Again, mostly shifting stuff around. Some function to anon in the
> > only place they are used, rename the x/y version of edit to editXY,
> > remove a cursorPar() or two, make some #if 0'd chunk of cod
Andre Poenitz wrote:
>
> Again, mostly shifting stuff around. Some function to anon in the
> only place they are used, rename the x/y version of edit to editXY,
> remove a cursorPar() or two, make some #if 0'd chunk of code in
> insettabular compilable.
You know, I really like the feel of all th
Again, mostly shifting stuff around. Some function to anon in the only
place they are used, rename the x/y version of edit to editXY, remove a
cursorPar() or two, make some #if 0'd chunk of code in insettabular
compilable.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
Several items:
Also dispatch to InsetCommands (etc) near the temp cursor tip on mouse
events (this means the label dialog is working again)
Lots of BOOST_ASSERTs to bomb early.
Shift some InsetLabel specific code from BufferView*
Shift LFUN_PARAGRAPH_APPLY handling from BV to Text.
Remove a f
On Fri, Jan 30, 2004 at 01:30:59PM -0800, Kayvan A. Sylvan wrote:
> The lyx crashes situation is better. Thanks.
>
> Lyx still crashes on:
>
> 1. C-N (New document)
> 2. C-M (Insert math inset)
> 3. type X^Y in the math inset
>
> The "^" causes the crash on some of my machines, but the C-m cause
The lyx crashes situation is better. Thanks.
Lyx still crashes on:
1. C-N (New document)
2. C-M (Insert math inset)
3. type X^Y in the math inset
The "^" causes the crash on some of my machines, but the C-m causes
the crash on my Solaris box.
---Kayvan
--
Kayvan A. Sylv
Andre Poenitz wrote:
> [...]
If your patch does half of what you say it does: good work! ;-)
> Alfredo, I certainly would not mind if you had a look at the coordinate
> business. It's currently somewhere in the limbo between 'screen
> absolute' and 'document absolute' and I wouldn't be surprised
e actual bugfixing will
be only a line or two. Monster patches are to be expected, but that'll
be only renaming etc. [For one, I'd like to rename all 'MathFooInset' to
'InsetMathFoo' as cosmetical part of IU]
There's one bit left that's not IU-ed, and that's
On Mon, Jan 26, 2004 at 09:54:57AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > 1. This dumps most of the rest of the mathcursor implementation into
> > the cursor.[Ch], "globalizes" a bit of them.
>
> How likely is it that the 'non-integrated rest of the original math
> cursor'
Andre Poenitz wrote:
>
> 1. This dumps most of the rest of the mathcursor implementation into
> the cursor.[Ch], "globalizes" a bit of them.
How likely is it that the 'non-integrated rest of the original math
cursor' will be 'generalized for texted'? I guess 'erase', 'up',
'down' can all be ge
On Wed, Jan 21, 2004 at 08:47:47AM +0100, Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
> > Do whatever is easiest for you. Note that Alfredo is pretty good at
> > tracking down off by one errors.
>
> I hope that with this lousy flattering you are not pretending I'll do the
> dirty job.
He
Angus Leeming wrote:
> Do whatever is easiest for you. Note that Alfredo is pretty good at
> tracking down off by one errors.
I hope that with this lousy flattering you are not pretending I'll do the
dirty job.
Alfredo
On Tue, Jan 20, 2004 at 02:20:52PM +, Angus Leeming wrote:
> Do whatever is easiest for you. Note that Alfredo is pretty good at
> tracking down off by one errors. (You've already warned people not to
> use current cvs for real work.)
*grin*
As 'cvs commit' on A and 'cvs up' on B is simpler
Andre Poenitz wrote:
>> What's the current_ slice? I thought that the cursor (blinking
>> thing) was always the top-most slice.
>
> We are dispatching to the innermost inset willing to handle an LFUN.
> This means going down the slice stack. Of course we can't just pop
> slices while trying to dis
On Tue, Jan 20, 2004 at 03:05:56PM +0100, Andre' Poenitz wrote:
> > Why does LCursor::innerInsetTabular() exist? Shouldn't this be a
> > wrapper function in an anonymous namespace in insettabular.C?
>
> Possibly, yes.
In fact 'innerInsetOfType' should be sufficient at some point of time.
Andre'
ecessarily the cursor tip)
> Do you have any plans to address the nastiness in LCursor::getPos?
Well, I don't intend to enter all math at position (100,100), so this
should be obvious.
> Why does LCursor::innerInsetTabular() exist? Shouldn't this be a
> wrapper function
abular.C?
Will the LCursor member functions returning MathArray et al. survive
IU or will they eventually dissappear?
I see you've move stuff out of cursor_slice and into cursor. cursor
becomes an STL-like container, it would appear.
Why are these now public? Surely you've added all
This removes MathIterator by shifting the remaining bits towards the
global cursor.
Both the global cursor and the math cursor now have two CursorSlice
stacks of the same shape...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, eithe
On Tue, Jan 13, 2004 at 12:26:08PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This unifies a few types used in LCursor and the math cursor.
> >
> > Note that this unifies on the 'wrong side': paroffset_type should be
> > unsigned in the long run but there seems to be a place or
Andre Poenitz wrote:
>
> This unifies a few types used in LCursor and the math cursor.
>
> Note that this unifies on the 'wrong side': paroffset_type should be
> unsigned in the long run but there seems to be a place or two where
> the core code relies on signedness (a downward counting loop mos
This unifies a few types used in LCursor and the math cursor.
Note that this unifies on the 'wrong side': paroffset_type should be
unsigned in the long run but there seems to be a place or two where
the core code relies on signedness (a downward counting loop most
likely).
It works as-is and cou
On Tue, 16 Dec 2003, Angus Leeming wrote:
> In other words, I'm quite happy with 'mathed' and 'texted'.
I'll consider this settled then :)
(Now I'd just like to know what they are)
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
Christian Ridderström wrote:
>
> I get bad 'vibes' from the word 'texted'... if you verb 'text' and
> look at the imperfect tempus, you get 'texted', i.e. "wrote".
Pronounced 'text-ed': ie the act of sending a text message by mobile
phone.
> However, I might be confused by Swedish here since,
On Tue, 16 Dec 2003, Andre Poenitz wrote:
> > Thanks... I stored your answer in the so far very small glossary here:
> > http://wiki.lyx.org/pmwiki.php/Devel/Glossary
>
> Historically, mathed and the 'rest' (recently dubbed 'texted') were
> really two separate implementations and partially ev
On Tue, 16 Dec 2003, Jean-Marc Lasgouttes wrote:
> > "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:
>
> >> Users will find that they are then able to test these currently
> >> incompatible insets inside each other.
>
> Christian> Thanks... I stored your answer in the so far
On Mon, Dec 15, 2003 at 02:22:55PM -0300, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > Sure. Shouldn't be needed at all, as well as a lot of
> > setCursor(cursor.par(), cursor.pos()) spreaded all around.
>
> See attached.
Nice.
Andre'
On Mon, Dec 15, 2003 at 08:39:28PM +0100, Christian Ridderström wrote:
> > Users will find that they are then able to test these currently
> > incompatible insets inside each other.
> >
> > Developers will find that they have a chance of understanding the
> > code.
> >
> Thanks... I stored your
> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes:
>> Users will find that they are then able to test these currently
>> incompatible insets inside each other.
Christian> Thanks... I stored your answer in the so far very small
Christian> glossary here:
Christian> http://wiki.l
On Mon, 15 Dec 2003, Angus Leeming wrote:
> Christian Ridderström wrote:
>
> > I've seen 'IU' several times now in the headers of posts...
> > is this the same as UI?
>
> No.
> UI: user interface.
> IU: inset unification. The on-going proces
Christian Ridderström wrote:
> I've seen 'IU' several times now in the headers of posts...
> is this the same as UI?
No.
UI: user interface.
IU: inset unification. The on-going process of merging the mathed and
'other' insets.
Users will find that they are th
On Monday 15 December 2003 19:03, Christian Ridderström wrote:
> I've seen 'IU' several times now in the headers of posts...
> is this the same as UI?
Inset Unification
non-math + math (the same answer given to Michael last friday) :-)
> /Christian
--
José Ab
I've seen 'IU' several times now in the headers of posts...
is this the same as UI?
/Christian
--
Christian Ridderström http://www.md.kth.se/~chr
Alfredo Braunstein wrote:
> Sure. Shouldn't be needed at all, as well as a lot of
> setCursor(cursor.par(), cursor.pos()) spreaded all around.
See attached.
Alfredo
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-
Andre Poenitz wrote:
> Don't know. Maybe not needed at all... Care to have a look?
Sure. Shouldn't be needed at all, as well as a lot of
setCursor(cursor.par(), cursor.pos()) spreaded all around.
I'm having a look.
Alfredo
On Mon, Dec 15, 2003 at 12:05:49PM -0300, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > It also replaces the x and y field of the cursor by on-demand
> > computation of that values, so the per-text cursor stuff is preparing
> > for its demise.
>
> Btw, what is redoCursor good for, nowada
Andre Poenitz wrote:
> It also replaces the x and y field of the cursor by on-demand
> computation of that values, so the per-text cursor stuff is preparing
> for its demise.
Btw, what is redoCursor good for, nowadays?
Alfredo
Andre Poenitz wrote:
> Tables getting better (still far from good).
>
> Moreover, this introduces a new class CursorSlice which replaces
> mathed's MathPos and texted's CursorItem. So the content of the math
> cursor and the global cursor looks similar nowadays.
Seems very nice.
> It also repl
On Mon, Dec 15, 2003 at 11:37:59AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> > On Mon, Dec 15, 2003 at 11:24:11AM +, Angus Leeming wrote:
> >> It's a clever way of extending working mathed behaviour to the
> >> outside world. I find reading the patch quite funny: I can
> >> unders
Andre Poenitz wrote:
> On Mon, Dec 15, 2003 at 11:24:11AM +, Angus Leeming wrote:
>> It's a clever way of extending working mathed behaviour to the
>> outside world. I find reading the patch quite funny: I can
>> understand the changes without understanding the underlying code
>> ;-)
>
> Well
On Mon, Dec 15, 2003 at 11:24:11AM +, Angus Leeming wrote:
> It's a clever way of extending working mathed behaviour to the outside
> world. I find reading the patch quite funny: I can understand the
> changes without understanding the underlying code ;-)
Well, it is a kind of a merge. texte
Andre Poenitz wrote:
>
> Tables getting better (still far from good).
>
> Moreover, this introduces a new class CursorSlice which replaces
> mathed's MathPos and texted's CursorItem. So the content of the math
> cursor and the global cursor looks similar nowadays.
>
> It also replaces the x and
ot; << item.inset_
+//<< " text: " << item.text()
+ << " idx: " << item.idx_
+//<< " par: " << item.par_
+//<< " pos: " << item.pos_
+//<< " x: " <<
Straight forward stuff, it just touches all of mathed/* and insets/*.
I had to use a few (three?) static casts that will go away again after full
IU.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson
d derived things.
[For large chunks of text it is currently a real waste of RAM -- ~20
bytes per char IIRC. I have a patch reducing that to 4 bytes per char which
should be acceptable in the light of a transition to Unicode, but that's
not finished...]
When I think about it, (ii) seems to be t
Andre Poenitz wrote:
> On Thu, Jun 12, 2003 at 10:06:00AM +, Angus Leeming wrote:
>> André,
>>
>> how do you forsee IU of the simple things like "button insets" panning
>> out? Will they take a form similar to that in mathed where the inset
>> itsel
On Thu, Jun 12, 2003 at 10:06:00AM +, Angus Leeming wrote:
> André,
>
> how do you forsee IU of the simple things like "button insets" panning out?
> Will they take a form similar to that in mathed where the inset itself
> derives from MathNestInset and is wrapp
André,
how do you forsee IU of the simple things like "button insets" panning out?
Will they take a form similar to that in mathed where the inset itself
derives from MathNestInset and is wrapped in an interface to the outside
world (Formula), or will it be something like the code
On Mon, Jun 02, 2003 at 12:19:18PM +0200, Andre Poenitz wrote:
> As I said, we call metrics() immediately before draw() (and stores it in
> the 'dim_' 'cache) so there should be no need to do it in draw() again.
>
> If there was, something else is broken...
seems OK to me
regards
john
Simply pulls the different validate() trees to InsetBase.
Ok?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: insets/inset.C
As I said, we call metrics() immediately before draw() (and stores it in
the 'dim_' 'cache) so there should be no need to do it in draw() again.
If there was, something else is broken...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they d
On Sun, Jun 01, 2003 at 01:14:35AM +0100, John Levon wrote:
> On Fri, May 30, 2003 at 11:07:31AM +0200, Andre Poenitz wrote:
>
> > With this, we have IU for drawing related stuff
> > (i.e. both phases)
>
> You seem to mix up simple "no change" stu
On Fri, May 30, 2003 at 11:07:31AM +0200, Andre Poenitz wrote:
> With this, we have IU for drawing related stuff
> (i.e. both phases)
You seem to mix up simple "no change" stuff with semantic changes such
as :
@@ -342,15 +342,12 @@ void InsetGraphics::draw(PainterInfo & p
On Fri, May 30, 2003 at 04:42:29PM +0200, Andre Poenitz wrote:
> Do you think you (i.e. you and Lars) will figure that out by that time or
> should I try it myself.
I reckon we'll be OK.
The thing I'm worried about now is the unknown source of the
inset_[const_]iterator breakage (insert->citatio
On Fri, May 30, 2003 at 03:31:46PM +0100, John Levon wrote:
> > By removing the line buffer_ = lp.buffer_ ?
>
> Look up I already posted the patch :)
Fine.
I have to leave now and I'll be off until Monday.
Do you think you (i.e. you and Lars) will figure that out by that time or
should I try i
On Fri, May 30, 2003 at 04:09:58PM +0200, Andre Poenitz wrote:
> By removing the line buffer_ = lp.buffer_ ?
Look up I already posted the patch :)
It just needs Lars to fill in some bits I'm not comforatable with in cut
and paste
regards
john
On Fri, May 30, 2003 at 04:05:55PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Fri, May 30, 2003 at 01:26:14PM +0100, John Levon wrote:
> | > Never mind, it seemed OK anyway. Though I agree with Lars we should
> | > lockdown for a bit and concentrate on u
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, May 30, 2003 at 01:26:14PM +0100, John Levon wrote:
| > Never mind, it seemed OK anyway. Though I agree with Lars we should
| > lockdown for a bit and concentrate on undo and the broken inset
| > iterators
|
| Hm. All crashes I currently get are
On Fri, May 30, 2003 at 01:26:14PM +0100, John Levon wrote:
> Never mind, it seemed OK anyway. Though I agree with Lars we should
> lockdown for a bit and concentrate on undo and the broken inset
> iterators
Hm. All crashes I currently get are asserts in boost::optional.
They go magically away if
On Fri, May 30, 2003 at 08:54:20AM +0200, Andre Poenitz wrote:
> I really checked all mail before I commited, you just missed it by a few
> seconds.
Never mind, it seemed OK anyway. Though I agree with Lars we should
lockdown for a bit and concentrate on undo and the broken inset
iterators
regar
On Fri, May 30, 2003 at 11:07:31AM +0200, Andre' Poenitz wrote:
> To really benefit from the two-stage drawing,
"... on top of cleaner code ..."
This removes some _really_ ugly glue between
mathed and the outside work (most notably
the different metrics() hacks and the cached
font_ member)
> t
With this, we have IU for drawing related stuff
(i.e. both phases)
To really benefit from the two-stage drawing,
the row painter would need some work.
[After that I'd guess we could even have a shot
at removal of all 'update' stuff (at least
to get a feeling on what would brea
On Fri, May 30, 2003 at 08:47:26AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | This is "InsetUnificiation" for draw()
>
> I'd like this patch to go in, _BUT_ I'd like more to stabilize and
> remove the breakage we have a bit first.
Sorry, too late.
I re
Andre Poenitz <[EMAIL PROTECTED]> writes:
| This is "InsetUnificiation" for draw()
I'd like this patch to go in, _BUT_ I'd like more to stabilize and
remove the breakage we have a bit first.
John has been helping me with this, so the greatest help I (we) can
get now is to test and help finaliz
This is "InsetUnificiation" for draw()
[And incidentally the second phase of the two-phase drawing,
and 80 lines of removed code]
There should be no user visible change, but I am not 100% sure because
of the 'float x' -> 'int x' change.
Known drawback: For Insets that do not properly impl
70 matches
Mail list logo
