Le 03/07/2016 17:51, Guillaume Munch a écrit :
Dear List
Attached is a patch that makes many small decisions regarding how text
insets should be displayed under change tracking. You would probably
have some comment about these choices. It would be too long to explain
and it is hard to understan
nch
Date: Mon, 23 May 2016 10:01:29 +0100
Subject: [PATCH] Change tracking cue: InsetText and InsetCollapsible
* Underline or strike through the label as if it was text (it is).
* Strike through deleted InsetText, but let RowPainter handle the case of
non-MultiPar text insets.
* Change the colour
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 03:59:35PM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote:
[]
There was no crash here, I had the exception message box displayed and
the buffer closed.
How do you get a bac
On Sat, Mar 08, 2008 at 03:59:35PM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
>> On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote:
>> []
>>> There was no crash here, I had the exception message box displayed and
>>> the buffer closed.
>> How do you get a backtrace
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote:
[]
There was no crash here, I had the exception message box displayed and the
buffer closed.
How do you get a backtrace in this situation?
Well, I down need one, the message box tells me which inset i
Andre Poenitz schrieb:
On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote:
[]
There was no crash here, I had the exception message box displayed and the
buffer closed.
How do you get a backtrace in this situation?
I am on windows also, and it is hard this way. If the exce
On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote:
[]
> There was no crash here, I had the exception message box displayed and the
> buffer closed.
How do you get a backtrace in this situation?
Andre'
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 12:45:37PM +0100, Bernhard Roider wrote:
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence o
On Sat, Mar 08, 2008 at 12:45:37PM +0100, Bernhard Roider wrote:
> Andre Poenitz schrieb:
>> On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
>>> I've fixed the crash reported by Bernhard at r23549. But I'm still
>>> puzzled about something. The crash is probably a consequence of my
>>> at
Bernhard Roider wrote:
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
about something. The crash is probably a consequence of my attempt to work
on Paragraph.cpp, but I'm not sure exactly what's happened. The ba
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
>
> I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
> about something. The crash is probably a consequence of my attempt to work
> on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
> gives
lar problems
> elsewhere. If anyone has any ideas, I'd love to hear them.
Maybe the InsetText constructor constructs a paragraph that needs a
layout which in turn accesses parts of the non-yet-fully constructed
text ot paragraph.
Andre'
Ignore all of this: I finally figured out what the problem was.
rh
One more clue: It's a docstring, basic_string, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
att
One more clue: It's a docstring, basic_string, according ot gdb.
rh
rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor, and
from there in basic_s
Am Sonntag, 10. September 2006 10:41 schrieb Georg Baum:
> This patch is a fallout of the my plaintext work. It goes in now.
This too.
Georg
Fix return value of InsetInclude::plaintext
* src/insets/insetinclude.C
(InsetInclude::plaintext): Add line counting code
Index: src/insets
This patch is a fallout of the my plaintext work. It goes in now.
Georg
Log:
Fix return value of InsetText::plaintext
* src/insets/insetnote.C
(InsetNote::plaintext): Move line counting code from here ...
* src/insets/insettext.C
(InsetText::plaintext): ... here
On Wed, May 24, 2006 at 07:45:25PM +0200, Michael Gerz wrote:
> Martin,
>
> given the fact that you are not allowed to revert logical deletions within
> the inset (otherwise you run into an inconsistent state), I am tempted to
> remove linebreaks without CT marking. I.e. setAutoBreakRow does not
Martin,
given the fact that you are not allowed to revert logical deletions within
the inset (otherwise you run into an inconsistent state), I am tempted to
remove linebreaks without CT marking. I.e. setAutoBreakRow does not consider
the buffer's change tracking mode. Does this make sense to y
On Wed, May 24, 2006 at 08:19:33PM +0300, Martin Vermeer wrote:
> On Wed, May 24, 2006 at 06:26:18PM +0200, Michael Gerz wrote:
...
> In non-ct mode, you irreversibly lose the newlines. It would be nice to
> mark them "blue" under ct.
s/blue/red/
- martin
pgp4c4CqndxJe.pgp
Description: PGP s
Michael Gerz wrote:
> Does it make sense that setAutoBreakRows marks linebreaks as (logically)
> deleted if they are disallowed? Is the user allowed to revert the deletion
> later?
No, he is not. Actually I did not think about that case.
> This may lead to inconsistent states.
Yes. It should on
tells whether linebreaks
are allowed (LyXText::autoBreakRows_ == true) or not
(LyXText::autoBreakRows_ == false). This means that
InsetText::setAutoBreakRows needs to delete existing line breaks if the
flag is set to false.
Of course LyXText::autoBreakRows_ is misnamed, and it should be
documented
On Wed, May 24, 2006 at 06:26:18PM +0200, Michael Gerz wrote:
> Hello,
>
> could somebody please tell me the purpose of method
> InsetText::setAutoBreakRows?
>
> I am asking because setAutoBreakRows calls Paragraph::erase() which requires
> a trackChanges flags in the new
Michael Gerz wrote:
> Hello,
>
> could somebody please tell me the purpose of method
> InsetText::setAutoBreakRows?
It sets the corresponding flag of LyXText, but I guess you knew that.
> I am asking because setAutoBreakRows calls Paragraph::erase() which
> requires a trackCh
Hello,
could somebody please tell me the purpose of method InsetText::setAutoBreakRows?
I am asking because setAutoBreakRows calls Paragraph::erase() which requires a
trackChanges flags in the new CT code. I guess that the buffer parameter (ct
on/off) has to be passed to setAutoBreakRows but I
On Wed, Nov 03, 2004 at 12:53:42PM +0100, Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
> Juergen> Is it possible to check from within a text inset whether the
> Juergen> cursor is inside that given inset? I have tried cur.inset()
> Juergen> an
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Is it possible to check from within a text inset whether the
Juergen> cursor is inside that given inset? I have tried cur.inset()
Juergen> and failed. Basically, I want to draw a visual clue when the
Juergen> cursor is in
Andre Poenitz wrote:
> Use LCursor::isInside(InsetBase *)
Thanks, I try this when I'm back home (actually, I thought that this
function is still bound to mathed).
Jürgen
On Mon, Nov 01, 2004 at 12:55:52PM +0100, Juergen Spitzmueller wrote:
> Is it possible to check from within a text inset whether the cursor is
> inside that given inset? I have tried cur.inset() and failed.
> Basically, I want to draw a visual clue when the cursor is inside a
> char style inset (ju
Is it possible to check from within a text inset whether the cursor is inside
that given inset? I have tried cur.inset() and failed.
Basically, I want to draw a visual clue when the cursor is inside a char style
inset (just like mathed's inline insets do).
Thanks,
Jürgen
Andre Poenitz wrote:
> - replace the LyXText member in the Buffer pimpl by an InsetText.
> This means we can drop a lot of special casing for the access
> to the toplevel text as in
This seems a great move.
> [- rename BufferView::buffer to BufferView::setBuffer. Bett
| Step 2. Almost mechanical.
> >>
> >> I wonder why this is a good move.
> >
> | Because it consolidates common code of InsetText and Buffer in a single
> | place (LyXText).
>
> But hasn't this rendered multiple views of the same buffer virtually
> impossi
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | Step 2. Almost mechanical.
>>
>> I wonder why this is a good move.
>
| Because
On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Step 2. Almost mechanical.
>
> I wonder why this is a good move.
Because it consolidates common code of InsetText and Buffer in a single
place (LyXText).
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Step 2. Almost mechanical.
I wonder why this is a good move.
--
Lgb
el/src/lyxtext.h,v
retrieving revision 1.264
diff -u -p -r1.264 lyxtext.h
--- lyxtext.h 28 Nov 2003 15:53:23 - 1.264
+++ lyxtext.h 28 Nov 2003 17:14:28 -
@@ -53,7 +53,7 @@ class LyXText : public TextCursor {
// Public Functions
public:
/// Constructor
- LyXT
On Tue, Nov 18, 2003 at 11:16:30AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> > In the light of IU and simplicity I lean towards the first option, but
> >> > I am not sure. Behaviour would probably change then (i.e. multi-cell
> >> > selection in the mathed way, not the current
Alfredo Braunstein wrote:
> If the only possible drawbacks are selections, then I'd say go for
> it...
>
> (but of course, I'm not the only one here ;-)
Don't forget that the main motivation for _all_ these changes is a
desire for clean and understandable code. Mathed certainly fits the
bill th
Andre Poenitz wrote:
>> > In the light of IU and simplicity I lean towards the first option, but
>> > I am not sure. Behaviour would probably change then (i.e. multi-cell
>> > selection in the mathed way, not the current tabular way. I don't see
>> > that as disadvantage, but then I am not imparti
me how.
Reseting the selection in the edit() call might already help a bit.
> What should we do? My idea is that when pushing or popping we should
> update also the text->cursor info. The problem is that this is done in
> insets/ and in cursor.C, where we don't exactly have the informa
x27;t exactly have the information to do this.
We could search for the inset in the containing insettext (not a very nice
thing to do in insets/ at least)
On the end, maybe we should implement cursor on top of a PosIterator + tip
inset. (but after we have only one slice for tables)?
Alfredo
On Tue, Nov 18, 2003 at 09:50:32AM +0100, Alfredo Braunstein wrote:
> > I noticed some regression that might be related to the
> > CursorItem::cached_y_ change. Simply move through the attached doc
> > with to see what I mean. The interesting point comes when
> > leaving the inner inset.
>
> I se
Andre Poenitz wrote:
> On Mon, Nov 17, 2003 at 07:16:15PM +0100, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > not really needed.
>> >
>> > What's the current state of coordinate handling btw?
>>
>> My selection2.diff patch makes passing mouse events to the main LyXText
>> in coordi
On Mon, Nov 17, 2003 at 07:16:15PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > not really needed.
> >
> > What's the current state of coordinate handling btw?
>
> My selection2.diff patch makes passing mouse events to the main LyXText in
> coordinates relatives to the LyXText i
Andre Poenitz wrote:
> not really needed.
>
> What's the current state of coordinate handling btw?
My selection2.diff patch makes passing mouse events to the main LyXText in
coordinates relatives to the LyXText itself (like for insets right now),
i.e. no more as screen coordinates. This in parti
8,8 +688,8 @@ void InsetText::validate(LaTeXFeatures &
void InsetText::getCursorPos(BufferView *, int & x, int & y) const
{
- x = cx() - xo_;
- y = cy();
+ x = text_.cursor.x() + TEXT_TO_INSET_OFFSET;
+ y = text_.cursor.y() - dim_.asc + TEXT_TO_INSET_OFFSET;
}
InsetText is not copyable.
Well, it formally is, but it does not work. I suspect the TextCursor
part in 'its' LyXText to be the cause, most notable the
ParagraphList::iterators in there.
I came to this conclusion it out when trying to figure out why
tabulars are buggy. I have a f
Martin Vermeer <[EMAIL PROTECTED]> writes:
| 323} else {
| 324FuncRequest cmd1 = cmd;
| 325if (!bv->lockInset(this))
| 326return DISPATCHED;
| 327if (cmd.y <= button_dim.y2) {
| 328cmd1.y
On Tue, Sep 09, 2003 at 11:13:56AM +0200, Lars Gullik Bjønnes spake thusly:
>
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
> |
> >> Martin Vermeer <[EMAIL PROTECTED]> writes:
> >>
> >> | The last one was indeed c
Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
|
>> Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
>> | The last one was indeed close to trivial. Here's the patch.
>>
>> This is ok.
>>
>> --
>> Lgb
>
| And the firs
On Tue, Sep 09, 2003 at 10:33:35AM +0200, Lars Gullik Bjønnes spake thusly:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | The last one was indeed close to trivial. Here's the patch.
>
> This is ok.
>
> --
> Lgb
And the first one? There is a change in functionality there (bug fix)
Martin Vermeer <[EMAIL PROTECTED]> writes:
| The last one was indeed close to trivial. Here's the patch.
This is ok.
--
Lgb
ext.C 8 Sep 2003 00:33:38 - 1.493
+++ insettext.C 9 Sep 2003 06:34:40 -
@@ -109,8 +109,6 @@ void InsetText::init(InsetText const * i
boost::bind(&Paragraph::setInsetOwner, _1, this));
top_y = 0;
no_selection = true;
- drawTextXO
Here's another cleanup patch.
2003-09-09 Martin Vermeer <[EMAIL PROTECTED]>
* insettext.[Ch]: remove drawText[XY]Offset
Can these go in? They are close to trivial and everything still
seems to work :-)
- Martin
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki Un
Martin Vermeer <[EMAIL PROTECTED]> writes:
| I suppose somebody had a good reason once to introduce these... but
| they don't do anything now. Initialized to zero and added/subtracted
| to/from various things many times over.
>
| Who feels a sense of ownership over these vars?
| Who vaguely remem
I suppose somebody had a good reason once to introduce these... but
they don't do anything now. Initialized to zero and added/subtracted
to/from various things many times over.
Who feels a sense of ownership over these vars?
Who vaguely remembers what they were for, or were intended to be for?
W
On Tue, Aug 26, 2003 at 06:52:45PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > \begin{tabular}{|p{6cm}|}
> > \hline
> > \centering par1\tabularnewline
> > par2\tabularnewline
> > \hline
> > \end{tabular}
> >
> > looks identical to the last one and has 'centering' for centered
> >
Andre Poenitz wrote:
> \begin{tabular}{|p{6cm}|}
> \hline
> \centering par1\tabularnewline
> par2\tabularnewline
> \hline
> \end{tabular}
>
> looks identical to the last one and has 'centering' for centered
> paragraphs and nothing for 'normal' once.
Indeed. This is certainly the simplest solution
On Tue, Aug 26, 2003 at 04:06:53PM +0200, Juergen Spitzmueller wrote:
> Am Dienstag, 26. August 2003 15:53 schrieb Andre Poenitz:
> > Ok, you lost me.
> >
> > THis works, so what's wrong with using \centering all over the place?
>
> Maybe I am completely wrong, but compare
>
> \begin{tabular}{|p{
Am Dienstag, 26. August 2003 15:53 schrieb Andre Poenitz:
> Ok, you lost me.
>
> THis works, so what's wrong with using \centering all over the place?
Maybe I am completely wrong, but compare
\begin{tabular}{|p{6cm}|}
\hline
{\centering par1\par}\tabularnewline
\hline
\end{tabular}
to
\begin{ta
On Tue, Aug 26, 2003 at 03:50:49PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > > consider a cell
> > > par1
> > > par2
> > > par3
> >
> > How do I create such a thing in TeX/LyX?
>
> \begin{tabular}{|p{6cm}|}
> \hline
> {\centering par1\par}
>
> {\raggedright par2\par}
>
> par3
Andre Poenitz wrote:
> > consider a cell
> > par1
> > par2
> > par3
>
> How do I create such a thing in TeX/LyX?
\begin{tabular}{|p{6cm}|}
\hline
{\centering par1\par}
{\raggedright par2\par}
par3\tabularnewline
\hline
\end{tabular}
Juergen
On Tue, Aug 26, 2003 at 03:33:31PM +0200, Juergen Spitzmueller wrote:
> I'd rather let LyX use the appropriate command than inserting such stuff into
> the document. I think with the solution you and Alfredo pointed out, it
> should be possible.
As long as you don't start using fancy back pointe
On Tue, Aug 26, 2003 at 03:25:02PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > Can't this be solved by some TeX trickery?
>
> None that I'm aware of.
>
> > It's a TeX problem after all...
>
> Indeed.
>
> > What's wrong with using \centering in the other cells?
>
> We can use
Andre Poenitz wrote:
> Concerning the TeX trickery:
>
> \makeatletter
> [EMAIL PROTECTED]
> \makeatother
>
> \begin{tabular}{p{3cm}}a\xpar b \xpar c\xpar\end{tabular}
>
> is certainly not perfect, but seems to work by adding a \par unless
> the next token is \end.
>
> Would that help?
I'd rather l
On Tue, Aug 26, 2003 at 03:09:21PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > InsetText::paragraphs().back() is the last par in this text.
>
> thanks. is this a bool?
>
> > What exactly do you need?
>
> I'm trying to get the alignment i
Alfredo Braunstein wrote:
> No, a reference to the last par in the list if there is one.
> (InsetText::paragraphs() is a std::list). If you have a
> Paragraph par, you can check for &par == &InsetText::paragraphs().back().
> Better, if you have an iterator pit pointing to your
Andre Poenitz wrote:
> Can't this be solved by some TeX trickery?
None that I'm aware of.
> It's a TeX problem after all...
Indeed.
> What's wrong with using \centering in the other cells?
We can use centering in most cases, but if there are more than one paragraphs,
we need a way to switch b
Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
>> InsetText::paragraphs().back() is the last par in this text.
>
> thanks. is this a bool?
No, a reference to the last par in the list if there is one.
(InsetText::paragraphs() is a std::list). If you have a
Paragraph par, yo
On Tue, Aug 26, 2003 at 03:09:21PM +0200, Juergen Spitzmueller wrote:
> Andre Poenitz wrote:
> > InsetText::paragraphs().back() is the last par in this text.
>
> thanks. is this a bool?
No, a reference to the last par.
> I'm trying to get the alignment in floats and
Andre Poenitz wrote:
> InsetText::paragraphs().back() is the last par in this text.
thanks. is this a bool?
> What exactly do you need?
I'm trying to get the alignment in floats and table cells right (our current
\begin{center}...\end{center} inserts unwanted space).
http://bugzi
On Tue, Aug 26, 2003 at 02:49:46PM +0200, Juergen Spitzmueller wrote:
> is there a way to check if a paragraph is the very last paragraph in an
> insettext? (I'm interested in the last paragraphs of a table cell).
InsetText::paragraphs().back() is the last par in this text.
What exa
is there a way to check if a paragraph is the very last paragraph in an
insettext? (I'm interested in the last paragraphs of a table cell).
Thanks,
Juergen.
On Thu, Aug 07, 2003 at 03:20:19PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> >> | Duplicated and/or dead code.
> >>
> >> I do not a
On Thu, Aug 07, 2003 at 12:46:36PM +0100, John Levon wrote:
> On Thu, Aug 07, 2003 at 01:44:49PM +0200, Andre Poenitz wrote:
>
> > Duplicated and/or dead code.
>
> Have you given this some *proper* testing with undo ?
Of course not.
But from a first glance it did not crash more often with this
On Thu, Aug 07, 2003 at 01:56:41PM +0200, Andre Poenitz wrote:
> But from a first glance it did not crash more often with this change
> than without...
>
> Ok I'll split it into two and let you play around with the LyXFunc.C
> part...
I'd rather know what this code is supposed to do.
regard
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Duplicated and/or dead code.
I do not agree with how you remove the else
it is not longer obvious that the cases are exclusive... I have to
read each block to find that out.
--
Lgb
gument is valid
* and points to a highly editable inset
*/
-inline bool isHighlyEditableInset(InsetOld const * i)
-{
- return i && i->editable() == InsetOld::HIGHLY_EDITABLE;
-}
+bool isHighlyEditableInset(InsetOld const * i);
#endif
Index: insets/insettext.C
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | Duplicated and/or dead code.
>>
>> I do not agree with how you remove the else
>
| It's still in now.
>
>> it is not longer obviou
On Thu, Aug 07, 2003 at 01:44:49PM +0200, Andre Poenitz wrote:
> Duplicated and/or dead code.
Have you given this some *proper* testing with undo ? In particular in
various positions of tables etc. ?
john
On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | Duplicated and/or dead code.
>
> I do not agree with how you remove the else
It's still in now.
> it is not longer obvious that the cases are exclusive... I have to
> read each
/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.468
diff -u -p -r1.468 insettext.C
--- insets/insettext.C 5 Aug 2003 08:07:04 - 1.468
+++ insets/insettext.C 5 Aug 2003 08:08:59 -
@@ -1093,32 +1093,6 @@ InsetOld::RESULT InsetText::localDispatc
}
break
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Aug 07, 2003 at 03:20:19PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Thu, Aug 07, 2003 at 02:04:18PM +0200, Lars Gullik Bjønnes wrote:
>> >> Andre Poenitz <[EMAIL PROTECTED]> writes:
>> >>
>> >> |
sable::lfunMouseRelease(
if (collapsed_ && cmd.button() != mouse_button::button3) {
collapsed_ = false;
- inset.setUpdateStatus(InsetText::FULL);
bv->updateInset(this);
bv->buffer()->markDirty();
return;
@@
ext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.464
diff -u -p -r1.464 insettext.C
--- insettext.C 2 Aug 2003 11:30:27 - 1.464
+++ insettext.C 4 Aug 2003 15:09:58 -
@@ -395,7 +395,7 @@ void InsetText::setUpdateStatus(int
We're over the worst now.
This introduces two-phase-drawing for the two remaining insets
(InsetText and InsetTabular).
It also magically fixes the 'select from behind in tables' bug and
makes tables a bit faster again.
What needs to be done now is proper two-phase-drawing for
/insettext.C 17 Jul 2003 09:30:29 -
@@ -166,7 +166,6 @@ void InsetText::init(InsetText const * i
for_each(paragraphs.begin(), paragraphs.end(),
boost::bind(&Paragraph::setInsetOwner, _1, this));
top_y = 0;
- old_max_width = 0;
no_selection =
6,7 +656,7 @@ void BufferView::Pimpl::update(LyXText *
text->partialRebreak();
if (text->inset_owner) {
- text->inset_owner->setUpdateStatus(bv_, InsetText::NONE);
+ text->inset_owner->setUpdateStatus(InsetText::NONE);
u
ex: insettext.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.422
diff -u -p -r1.422 insettext.C
--- insettext.C 10 Jul 2003 14:44:13 - 1.422
+++ insettext.C 14 Jul 2003 13:42:35 -
@@ -274,10 +274,10 @@ void
=
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettext.C,v
retrieving revision 1.419
diff -u -p -r1.419 insettext.C
--- insettext.C 10 Jul 2003 10:06:19 - 1.419
+++ insettext.C 10 Jul 2003 10:12:11 -
@@ -1943,38 +1943,38 @@ int InsetText::cix(BufferView * bv) cons
int InsetTex
On Mon, Jul 07, 2003 at 11:40:25AM +0200, Andre Poenitz wrote:
> No known problems.
>
> [John, that should make you start...]
Can you please wait until at least Wednesday ...
regards
john
idths/heights only!
void reinit();
-private:
+ ///
+//private:
///
mutable int cur_cell;
///
@@ -422,6 +423,7 @@ private:
///
InsetText inset;
};
+ cellstruct * cellinfo_of_cell(int cell) const;
///
typedef std
On Mon, Jun 09, 2003 at 11:26:41AM +0100, Angus Leeming wrote:
> Differences between Alfredo's patch and my suggested change? I don't
Oh sorry.
> believe you. I reckon that you are comparing this to the situation
> without any patch at all.
Yes.
regards
john
John Levon wrote:
> On Sun, Jun 08, 2003 at 07:10:27PM +, Angus Leeming wrote:
>
>> > So this change will
>> > tipically avoid an unecesary check and speed up things when
>> > navigating
>>
>> and the speed up is how big exactly ;-)
>
> Physically noticable. Getting accurate metrics is some
On Sun, Jun 08, 2003 at 07:10:27PM +, Angus Leeming wrote:
> > So this change will
> > tipically avoid an unecesary check and speed up things when navigating
>
> and the speed up is how big exactly ;-)
Physically noticable. Getting accurate metrics is somewhat tricky.
regards
john
Alfredo Braunstein wrote:
> I don't agree... The name is likely to be always valid (except for an
> incomplete frontend, that shouldn't be used anyway).
Really? "fork", "preamble" ?
> So this change will
> tipically avoid an unecesary check and speed up things when navigating
> with a dialog ope
Alfredo Braunstein wrote:
> John Levon wrote:
>
>> Please do, it looks like we can regain a few percent from this
>
> Does this betters out things... and uh... is correct? (Angus please check)
>
> Regards, Alfredo
Looks good except for this:
> Index: frontends/Dialogs.C
> Dialog * Dialogs::f
John Levon wrote:
> whitespace horkage, it all got converted to spaces. Applied with -l,
> testing now
Uh... sorry. (Damn knode. Used to work.)
Regards, Alfredo
On Thu, Jun 05, 2003 at 09:26:40PM +0200, Alfredo Braunstein wrote:
> Does this betters out things... and uh... is correct? (Angus please check)
Seems to be significantly faster in the "move the cursor along" test
regards
john
1 - 100 of 195 matches
Mail list logo
