Re: playing a bit...
On Sun, Nov 09, 2003 at 04:55:08PM +0100, Alfredo Braunstein wrote: > With the attached patch, I am able to obtain the attached screenshot > (without cheating, that is). > > Of course, everything blows up (at selection displaying time) if the start > and end of the match are not on the same document level, this breaks up > replace, backward searches and a few other useful things but... isn't it > cute? Good stuff ;-) 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...)
Re: playing a bit...
Andre Poenitz wrote: > On Sun, Nov 09, 2003 at 04:55:08PM +0100, Alfredo Braunstein wrote: >> With the attached patch, I am able to obtain the attached screenshot >> (without cheating, that is). >> >> Of course, everything blows up (at selection displaying time) if the >> start and end of the match are not on the same document level, this >> breaks up replace, backward searches and a few other useful things but... >> isn't it cute? > > Good stuff ;-) Thank John Maddock ;-) In fact, I think we can easily put together some working version of this for 1.4.x. (possibly with a checkbox disabling replace and backward(*) search for regex searches). The only undefined corners are: what to do with selections ending in different levels (possibly eat the insets in the selection. Maybe in the future LyX will support this type of selections...), and what syntax to use for searching insets types etc... In any case, I personally want to focus in helping with core changes/regression fixing for the moment. (*) even if it's not directly supported in the boost library, I think it's not that hard, it would suffice to revert the regex expression, and revert the iterators... Regards, Alfredo
Re: playing a bit...
On Mon, Nov 10, 2003 at 09:50:53AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > On Sun, Nov 09, 2003 at 04:55:08PM +0100, Alfredo Braunstein wrote: > >> With the attached patch, I am able to obtain the attached screenshot > >> (without cheating, that is). > >> > >> Of course, everything blows up (at selection displaying time) if the > >> start and end of the match are not on the same document level, this > >> breaks up replace, backward searches and a few other useful things but... > >> isn't it cute? > > > > Good stuff ;-) > > Thank John Maddock ;-) > > In fact, I think we can easily put together some working version of this for > 1.4.x. (possibly with a checkbox disabling replace and backward(*) search > for regex searches). The only undefined corners are: what to do with > selections ending in different levels (possibly eat the insets in the > selection. Maybe in the future LyX will support this type of > selections...), and what syntax to use for searching insets types etc... > > In any case, I personally want to focus in helping with core > changes/regression fixing for the moment. Rest assured you do not run out of work once I commit ;-) I wonder a bit about the rest. Has been pretty quiet here for a couple of days... Andre'
Re: long shot "final"
Andre Poenitz wrote: > Unless someone shouts really loudly, I'll commit as soon a I finished > writing the ChangeLogs. I'll send a word of warning to the user list as > well I guess that the worst that can happend is to lose a day or two because of having to retreat to today's cvs... ;-) The linecount is pretty impressive though... or should I say scary? Aiho! I don't ask how many they are, let them come one by one! Alfredo
Re: long shot "final"
On Mon, Nov 10, 2003 at 10:01:19AM +0100, Alfredo Braunstein wrote: > Aiho! I don't ask how many they are, let them come one by one! Here we go. Andre' PS: Anybody interested in a copy of 19 source trees with "gradual changes" for historical reasons?
Re: playing a bit...
-BEGIN PGP SIGNED MESSAGE- On Montag, 10. November 2003 09:50, Alfredo Braunstein wrote: ... > In fact, I think we can easily put together some working version of this > for 1.4.x. (possibly with a checkbox disabling replace and backward(*) > search for regex searches). The only undefined corners are: what to do with > selections ending in different levels (possibly eat the insets in the > selection. Maybe in the future LyX will support this type of > selections...), and what syntax to use for searching insets types etc... Considering the fact, that the regular expresion may match big portions of text, there may even be a possibility to restrict it in some way? Something like expression fits within 20 paragraphs with value (20) and "unit" like characters or words. Boys, you are good. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP69XZ7ewfbDGmeqhAQHtkwP/YgDDdYG/9AkGVZjlGajoybUjudcu5I89 o/21LgdzhHzq7SxWA1E7LiEu5ZoZzcVBGnoByXQOwZiqht4BCdqPr4dr7eCH8XLG fLUQ34iYUIz2aABQPIdwTw6ZBjWcnQUob/NEwqAsstHAU413m44JQHXpQ5CE7ANG 7H/QgxqbwFQ= =Ow+L -END PGP SIGNATURE-
Re: 1.4.0cvs warning
On Mon, Nov 10, 2003 at 10:07:44AM +0100, Andre Poenitz spake thusly: > I plan to commit a couple of core changes that will make 1.4.0cvs > unusable for a couple of days. The situation should improve quickly, but > if you plan to submit your thesis tomorrow, do not run 'cvs up'. Did just that ;-) Add #include to cursor.h. - Martin pgp0.pgp Description: PGP signature
Re: playing a bit...
Kornel Benko wrote: > Considering the fact, that the regular expresion may match big > portions of text, there may even be a possibility to restrict it > in some way? > Something like > expression fits within 20 paragraphs > with value (20) and "unit" like characters or words. In principle I think you can achieve that already with POSIX regex expressions, although probably the resulting expression would be possibly pretty cluttered. Maybe it's an option to consider. > Boys, you are good. Note that it's practically not my doing, I've simply put the wonderful boost::regex library to work. Unfortunately I'll have to decline the compliment... ;-) Alfredo
How the new cursor works
A short overview. Everything 'above' the main LyXText remain unchanged. I'll call the main LyXText and the insets etc 'canvas' from now on. There are two kinds of events in the canvas: Mouse events and Keyboard events. They are split in BufferView_pimpl::dispatch(). For mouse events we build a 'cursor helper', i.e. a stack of insets leading to the xy position of the click. Then we dispatch to the inset on the tip of this stack. If that fails, we dispatch to the LyXText surrounding that inset. [Possible thinko: are there cases where insets further up in the hierarchy should take notice of mouse clicks?] Keybord events are more regular: From BufferView_pimpl::dispatch() they are sent to the BufferViews's cursor LCursor::dispatch(). So Keyboard events always go to the cursor. The cursor loops over all insets from innermost to outermost and tries to dispatch to the insets. If an inset dispatches the request, we break from the loop. An inset can also say 'FINISHED(RIGHT/UP/DOWN)' in which case the cursor is pruned to this level and an LFUN_FINISHED_RIGHT etc is disptached to the surrounding inset. This inset can return 'dispatched' or 'finished' as well. If the outermost inset does not successfully dispatch an LFUN or a resulting 'FINISHED', the request is passed to the main text. If the main text doesn't handle it, it goes to the last of BufferView_pimpl::dispatch() and later we don't care. The InsetFoo::dispatch's are very regular now: one big switch to handle special cases and a 'default' to pass it to a generic dispatcher. For InsetCollapsable that's the LyXText::dispatch of its text_, For InsetTabular it's the LyXText of the currently active cell. InsetTabulars basically have a two-level structure and the also show up as two levels in the cursor: One level is the InsetTabular and a 0 LyXText, the second one is the 'active' cell. I am not sure I like this, but that's the 'natural' solution given the previous state of the art. Andre'
[patch]
Has been dead for a while...
--
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...)
? 1.diff
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.902
diff -u -p -r1.902 ChangeLog
--- ChangeLog 10 Nov 2003 09:06:38 - 1.902
+++ ChangeLog 10 Nov 2003 09:54:26 -
@@ -1,6 +1,10 @@
2003-11-10 André Pönitz <[EMAIL PROTECTED]>
+ * inset.h: remove Inset::id_
+
+2003-11-10 André Pönitz <[EMAIL PROTECTED]>
+
* inset.[Ch]:
* insetbox.[Ch]:
* insetcollapsable.[Ch]:
Index: inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.137
diff -u -p -r1.137 inset.h
--- inset.h 10 Nov 2003 09:06:41 - 1.137
+++ inset.h 10 Nov 2003 09:54:26 -
@@ -291,8 +291,6 @@ protected:
mutable int top_baseline;
///
mutable int scx;
- /// Used to identify the inset for cursor positioning when undoing
- unsigned int id_;
///
mutable Dimension dim_;
@@ -316,7 +314,7 @@ class InsetOld_code {
InsetOld::Code val_;
public:
InsetOld_code(InsetOld::Code val) : val_(val) {}
- operator InsetOld::Code() const{ return val_; }
+ operator InsetOld::Code() const { return val_; }
};
@@ -324,13 +322,13 @@ public:
* returns true if pointer argument is valid
* and points to an editable inset
*/
-bool isEditableInset(InsetOld const * i);
+bool isEditableInset(InsetOld const * inset);
/**
* returns true if pointer argument is valid
* and points to a highly editable inset
*/
-bool isHighlyEditableInset(InsetOld const * i);
+bool isHighlyEditableInset(InsetOld const * inset);
#endif
[patch] crash
Open the UG, click on the first footnote -> crash
The problem is that the bv_owner of the text is set on InsetText::dispatch,
but the insetHist check is done before that.
The attached solves it, even if it doesn't seem the right solution.
bv_owner -> bv() changes were good to find the crash.
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.454
diff -u -p -u -r1.454 BufferView_pimpl.C
--- BufferView_pimpl.C 10 Nov 2003 09:06:31 - 1.454
+++ BufferView_pimpl.C 10 Nov 2003 09:54:55 -
@@ -887,6 +887,7 @@ namespace {
while ((inset_hit = text->checkInsetHit(x, y))) {
inset = inset_hit;
text = inset_hit->getText(0);
+ text->init(bv);
lyxerr << "Hit inset: " << inset << " at x: " << x
<< " y: " << y << endl;
theTempCursor.push(static_cast(inset));
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.495
diff -u -p -u -r1.495 text2.C
--- text2.C 10 Nov 2003 09:06:37 - 1.495
+++ text2.C 10 Nov 2003 09:54:58 -
@@ -74,7 +74,7 @@ LyXText::LyXText(BufferView * bv, InsetT
ParagraphList & paragraphs)
: height(0), width(0), inset_owner(inset), bv_owner(bv),
in_inset_(ininset), paragraphs_(¶graphs),
- cache_pos_(-1)
+ cache_pos_(-1)
{}
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.171
diff -u -p -u -r1.171 text3.C
--- text3.C 10 Nov 2003 09:06:37 - 1.171
+++ text3.C 10 Nov 2003 09:55:00 -
@@ -307,7 +307,7 @@ string const freefont2string()
InsetOld * LyXText::checkInsetHit(int & x, int & y)
{
- int y_tmp = y + bv_owner->top_y();
+ int y_tmp = y + bv()->top_y();
LyXCursor cur;
setCursorFromCoordinates(cur, x, y_tmp);
@@ -498,7 +498,7 @@ void LyXText::cursorNext()
nextRow(cpit, crit);
LyXCursor cur;
setCursor(cur, parOffset(cpit), crit->pos(), false);
- if (cur.y() < bv_owner->top_y() + bv()->workHeight())
+ if (cur.y() < bv()->top_y() + bv()->workHeight())
cursorDown(true);
bv()->updateScrollbar();
}
Re: [patch] crash
On Mon, Nov 10, 2003 at 11:04:44AM +0100, Alfredo Braunstein wrote:
> Open the UG, click on the first footnote -> crash
>
> The problem is that the bv_owner of the text is set on InsetText::dispatch,
> but the insetHist check is done before that.
>
> The attached solves it, even if it doesn't seem the right solution.
> bv_owner -> bv() changes were good to find the crash.
>
> Index: BufferView_pimpl.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
> retrieving revision 1.454
> diff -u -p -u -r1.454 BufferView_pimpl.C
> --- BufferView_pimpl.C 10 Nov 2003 09:06:31 - 1.454
> +++ BufferView_pimpl.C 10 Nov 2003 09:54:55 -
> @@ -887,6 +887,7 @@ namespace {
> while ((inset_hit = text->checkInsetHit(x, y))) {
> inset = inset_hit;
> text = inset_hit->getText(0);
> + text->init(bv);
Would just setting the view be enough?
Andre'
Re: [patch] crash
Alfredo Braunstein wrote: > The attached solves it, even if it doesn't seem the right solution. There is an architectural problem here: the Cursor doesn't know that the inset is collapsed and tries to go further down. Maybe checkInsetHit still needs to be recursive after all. Regards, Alfredo
Re: [patch] crash
On Mon, Nov 10, 2003 at 11:10:23AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> > The attached solves it, even if it doesn't seem the right solution.
>
> There is an architectural problem here: the Cursor doesn't know that the
> inset is collapsed and tries to go further down.
> Maybe checkInsetHit still needs to be recursive after all.
Couldn't it simply return 'nonEditable' or whatever suitable (maybe an
additional check returning 0 for collapsed insets) that makes
InsetOld * checkInset(LyXText & text,
LyXCursor const & cur, int & x, int & y)
{
lyx::pos_type const pos = cur.pos();
ParagraphList::iterator par = text.getPar(cur);
if (pos >= par->size() || !par->isInset(pos))
return 0;
InsetOld /*const*/ * inset = par->getInset(pos);
if (!isEditableInset(inset))
return 0;
// get inset dimensions
BOOST_ASSERT(par->getInset(pos));
LyXFont const & font = text.getFont(par, pos);
int const width = inset->width();
int const inset_x = font.isVisibleRightToLeft()
? (cur.x() - width) : cur.x();
Box b(
inset_x + inset->scroll(),
inset_x + width,
cur.y() - inset->ascent(),
cur.y() + inset->descent()
);
if (!b.contains(x, y)) {
lyxerr[Debug::GUI] << "Missed inset at x,y "
<< x << ',' << y
<< " box " << b << endl;
return 0;
}
text.setCursor(cur.par(), pos, true);
x -= b.x1;
// The origin of an inset is on the baseline
y -= text.cursor.y();
return inset;
}
return 0?
Btw: I just noticed that this does set the cursor... maybe it should be
split into a strictly 'informational' part (i.e. answer the question
whether the inset was hit) and the 'inset locking' part (set the cursor
to the place)
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...)
Re: [patch] crash
Andre Poenitz wrote: > Would just setting the view be enough? Probably not, as LyXText::checkInsetHit needs a RowList. But I think it's wrong in any case to call it, see my other post. Alfredo
QT configuration failure.
Hello, I cannot configure lyx-qt today: ./configure --with-frontend="qt xforms" --with-qt-includes=/usr/include/qt3/ --with-qt-libraries=/usr/lib/qt3/ --with-qt-dir=/usr/share/qt3/ --with-version-suffix=-devel ends up with: Configuration Host type: i686-pc-linux-gnu Special build flags:warnings assertions xforms-image-loader compression C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (3.3.2) C++ Compiler flags: -O -fno-exceptions -W -Wall Linker flags: Qt Frontend: Qt version: XForms Frontend: libXpm version: 4.11 libforms version: 1.0.0 LyX binary dir: /usr/local/bin LyX files dir: /usr/local/share/lyx-devel Could it be last Lars' configure.ac changes? Regards, João.
Re: [patch] crash
On Mon, Nov 10, 2003 at 11:14:28AM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > Would just setting the view be enough? > > Probably not, as LyXText::checkInsetHit needs a RowList. But I think it's > wrong in any case to call it, see my other post. Hm.. iterating over the insetlist instead of setting these cursor helpers perhaps? 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...)
Re: [patch] crash
Andre Poenitz wrote:
> return 0?
I don't understand, how do you click on button insets (or closed
collapsables) if they are not hit by insetFromCoords?
The inset *has* to be hit, it's the lyxtext inside that is "not present".
Maybe:
while ((inset_hit = text->checkInsetHit(x, y))) {
+ if (!inset_hit->isHiglyEditable())
+ break;
inset = inset_hit;
text = inset_hit->getText(0);
lyxerr << "Hit inset: " << inset << " at x: " << x
<< " y: " << y << endl;
theTempCursor.push(static_cast(inset));
}
or something? *Then*, we should open the inset, and *then* put the cursor
inside, right?
> Btw: I just noticed that this does set the cursor... maybe it should be
> split into a strictly 'informational' part (i.e. answer the question
> whether the inset was hit) and the 'inset locking' part (set the cursor
> to the place)
Agreed.
Alfredo
Re: [patch] crash
On Mon, Nov 10, 2003 at 11:11:41AM +0100, Andre Poenitz spake thusly:
>
> On Mon, Nov 10, 2003 at 11:04:44AM +0100, Alfredo Braunstein wrote:
> > Open the UG, click on the first footnote -> crash
> >
> > The problem is that the bv_owner of the text is set on InsetText::dispatch,
> > but the insetHist check is done before that.
> >
> > The attached solves it, even if it doesn't seem the right solution.
> > bv_owner -> bv() changes were good to find the crash.
> >
> > Index: BufferView_pimpl.C
> > ===
> > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
> > retrieving revision 1.454
> > diff -u -p -u -r1.454 BufferView_pimpl.C
> > --- BufferView_pimpl.C 10 Nov 2003 09:06:31 - 1.454
> > +++ BufferView_pimpl.C 10 Nov 2003 09:54:55 -
> > @@ -887,6 +887,7 @@ namespace {
> > while ((inset_hit = text->checkInsetHit(x, y))) {
> > inset = inset_hit;
> > text = inset_hit->getText(0);
> > + text->init(bv);
>
> Would just setting the view be enough?
>
> Andre'
I found that trying to open a closed collapsable inset crashes, but
closing an open one (and opening it again etc.) does not.
Is the bv defined for an inset that is loaded in collapsed state?
- Martin
pgp0.pgp
Description: PGP signature
Re: QT configuration failure.
Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes: | Qt Frontend: | Qt version: | XForms Frontend: | libXpm version: 4.11 | libforms version: 1.0.0 | LyX binary dir: /usr/local/bin | LyX files dir: /usr/local/share/lyx-devel > > | Could it be last Lars' configure.ac changes? No changes for a long time. -- Lgb
Re: [patch] crash
On Mon, Nov 10, 2003 at 11:31:55AM +0100, Alfredo Braunstein wrote:
> Maybe:
>
> while ((inset_hit = text->checkInsetHit(x, y))) {
> + if (!inset_hit->isHiglyEditable())
> + break;
> inset = inset_hit;
> text = inset_hit->getText(0);
> lyxerr << "Hit inset: " << inset << " at x: " << x
> << " y: " << y << endl;
> theTempCursor.push(static_cast(inset));
> }
Something with that idea attached. It solves the particular problem and
seems to be a proper solutuion. And removes 30 lines...
Note that we now simply iterator over the insetlist and do not need the
row structure anymore.
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: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.454
diff -u -p -r1.454 BufferView_pimpl.C
--- BufferView_pimpl.C 10 Nov 2003 09:06:31 - 1.454
+++ BufferView_pimpl.C 10 Nov 2003 11:23:08 -
@@ -882,13 +882,17 @@ namespace {
{
LyXText * text = bv->text;
InsetOld * inset = 0;
- InsetOld * inset_hit = 0;
theTempCursor = LCursor(bv);
- while ((inset_hit = text->checkInsetHit(x, y))) {
+ while (true) {
+ InsetOld * inset_hit = text->checkInsetHit(x, y);
+ if (!inset_hit)
+ break;
inset = inset_hit;
+ if (!inset_hit->descendable())
+ break;
text = inset_hit->getText(0);
lyxerr << "Hit inset: " << inset << " at x: " << x
- << " y: " << y << endl;
+ << " text: " << text << " y: " << y << endl;
theTempCursor.push(static_cast(inset));
}
return inset;
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text3.C,v
retrieving revision 1.171
diff -u -p -r1.171 text3.C
--- text3.C 10 Nov 2003 09:06:37 - 1.171
+++ text3.C 10 Nov 2003 11:23:08 -
@@ -239,55 +239,6 @@ namespace {
bv->owner()->view_state_changed();
}
- // check if the given co-ordinates are inside an inset at the
- // given cursor, if one exists. If so, the inset is returned,
- // and the co-ordinates are made relative. Otherwise, 0 is returned.
- InsetOld * checkInset(LyXText & text,
- LyXCursor const & cur, int & x, int & y)
- {
- lyx::pos_type const pos = cur.pos();
- ParagraphList::iterator par = text.getPar(cur);
-
- if (pos >= par->size() || !par->isInset(pos))
- return 0;
-
- InsetOld /*const*/ * inset = par->getInset(pos);
-
- if (!isEditableInset(inset))
- return 0;
-
- // get inset dimensions
- BOOST_ASSERT(par->getInset(pos));
-
- LyXFont const & font = text.getFont(par, pos);
-
- int const width = inset->width();
- int const inset_x = font.isVisibleRightToLeft()
- ? (cur.x() - width) : cur.x();
-
- Box b(
- inset_x + inset->scroll(),
- inset_x + width,
- cur.y() - inset->ascent(),
- cur.y() + inset->descent()
- );
-
- if (!b.contains(x, y)) {
- lyxerr[Debug::GUI] << "Missed inset at x,y "
- << x << ',' << y
- << " box " << b << endl;
- return 0;
- }
-
- text.setCursor(cur.par(), pos, true);
-
- x -= b.x1;
- // The origin of an inset is on the baseline
- y -= text.cursor.y();
-
- return inset;
- }
-
} // anon namespace
@@ -307,28 +258,34 @@ string const freefont2string()
InsetOld * LyXText::checkInsetHit(int & x, int & y)
{
- int y_tmp = y + bv_owner->top_y();
-
- LyXCursor cur;
- setCursorFromCoordinates(cur, x, y_tmp);
+ ParagraphList::iterator pit = ownerParagraphs().begin();
+ ParagraphList::iterator end = ownerParagraphs().end();
- InsetOld * inset = checkInset(*this, cur, x, y_tmp);
- if (inset) {
- y = y_tmp;
- return inset;
+ lyxerr << "checkInsetHit:
Re: [patch] crash
Andre Poenitz wrote: > Something with that idea attached. It solves the particular problem and > seems to be a proper solutuion. And removes 30 lines... > > Note that we now simply iterator over the insetlist and do not need the > row structure anymore. Compiling. Note that we should anyway assert on "no rows", be cause "no rows" means "no position information at all" so the checkInsetHit call would be completely bogus. Alfredo
Re: [patch] crash
On Mon, Nov 10, 2003 at 12:33:03PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > Something with that idea attached. It solves the particular problem and > > seems to be a proper solutuion. And removes 30 lines... > > > > Note that we now simply iterator over the insetlist and do not need the > > row structure anymore. > > Compiling. Note that we should anyway assert on "no rows", be cause "no > rows" means "no position information at all" so the checkInsetHit call > would be completely bogus. No, it means 'no _internal_ position information'. The xy placement of the inset and its dimension are valid after the first draw (the dimension even already after the first metrics). This is sufficient for 'inset hit'. But I just noticed we need to a bit more careful: If an inset is not visible anymore (because the user scrolled down) it keeps its xy chace with bogus values... 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...)
Re: [patch] crash
Andre Poenitz wrote: >> Compiling. Note that we should anyway assert on "no rows", be cause "no >> rows" means "no position information at all" so the checkInsetHit call >> would be completely bogus. > > No, it means 'no _internal_ position information'. ... what about the inset size? Height in particular. > The xy placement of the inset and its dimension are valid after the > first draw (the dimension even already after the first metrics). The first metrics then imply knowing the rowbreaking (otherwise how would it know its height?) > This is sufficient for 'inset hit'. ... > But I just noticed we need to a bit more careful: If an inset is not > visible anymore (because the user scrolled down) it keeps its xy chace > with bogus values... Ugh... Alfredo
Re: [patch] crash
On Mon, Nov 10, 2003 at 12:45:14PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> Compiling. Note that we should anyway assert on "no rows", be cause "no > >> rows" means "no position information at all" so the checkInsetHit call > >> would be completely bogus. > > > > No, it means 'no _internal_ position information'. > > ... what about the inset size? Height in particular. Ah... that's what you mean. Ok, for this we need rows. And we should have them as the inset must have been drawn before we could click inside... So an ASSERT would be ok in this case. 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...)
Re: [patch] crash
On Mon, Nov 10, 2003 at 12:45:14PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> Compiling. Note that we should anyway assert on "no rows", be cause "no > >> rows" means "no position information at all" so the checkInsetHit call > >> would be completely bogus. > > > > No, it means 'no _internal_ position information'. > > ... what about the inset size? Height in particular. > > > The xy placement of the inset and its dimension are valid after the > > first draw (the dimension even already after the first metrics). > > The first metrics then imply knowing the rowbreaking (otherwise how would it > know its height?) > > > This is sufficient for 'inset hit'. > > ... > > > But I just noticed we need to a bit more careful: If an inset is not > > visible anymore (because the user scrolled down) it keeps its xy chace > > with bogus values... > > Ugh... We need the notion of 'visible paragraphs of main text'. BufferView::updateInset() would benefit from it as well... Should not be hard: A pair of ParagraphList::iterators build by summing up a few y values around bv->text->cursorPar()... 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...)
Re: QT configuration failure.
On Mon, 10 Nov 2003, Lars Gullik Bjønnes wrote: > Joao Luis Meloni Assirati <[EMAIL PROTECTED]> writes: > > | Qt Frontend: > | Qt version: > | XForms Frontend: > | libXpm version: 4.11 > | libforms version: 1.0.0 > | LyX binary dir: /usr/local/bin > | LyX files dir: /usr/local/share/lyx-devel > > > > > | Could it be last Lars' configure.ac changes? > > No changes for a long time. OK, the problem was here. For some reason the multithreaded qt stopped being detected in debian unstable. I am using the non-multithreaded version (libqt3-dev) instead and it works. Thanks, João.
Re: [patch] crash
Andre Poenitz wrote: >> > But I just noticed we need to a bit more careful: If an inset is not >> > visible anymore (because the user scrolled down) it keeps its xy chace >> > with bogus values... >> >> Ugh... > > We need the notion of 'visible paragraphs of main text'. > BufferView::updateInset() would benefit from it as well... > > Should not be hard: A pair of ParagraphList::iterators build by summing > up a few y values around bv->text->cursorPar()... Why don't we set them up in the draw() stage? This is where the correct cache positions get computed anyway. Alfredo
1.4.0cvs warning
A note to the adventurous souls already using 1.4.0cvs: I plan to commit a couple of core changes that will make 1.4.0cvs unusable for a couple of days. The situation should improve quickly, but if you plan to submit your thesis tomorrow, do not run 'cvs up'. This affects only the current development version (1.4.0cvs). The stable branch (1.3.x) is safe. For serious work, 1.3.3 is recommended. You have been warned. Andre'
Crash when clicking in math inset
Hi André,
I send attached a small file.
When I click several times over the display math I get a crash always after
this debug message on screen:
BufferView::Pimpl::fitCursor.
checkInsetHit: x: 346 y: 106
examining inset 0x84d4808 xy: 257/111 x: 257...485 y: 60...136
Hit inset: 0x84d4808
dispatching action 220 to inset 0x84d4808
--
José Abílio
LyX and docbook, a perfect match. :-)
#LyX 1.4.0cvs created this file. For more info see http://www.lyx.org/
\lyxformat 225
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 1
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\tracking_changes 0
\end_header
\begin_layout Itemize
Example:
\end_layout
\begin_layout Itemize
\begin_inset Formula \[
a\, X_{1}+b\, X_{2}\stackrel{d}{=c\, X}+d,\]
\end_inset
\end_layout
\end_document
Re: [patch] crash
On Mon, Nov 10, 2003 at 01:09:55PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> > But I just noticed we need to a bit more careful: If an inset is not > >> > visible anymore (because the user scrolled down) it keeps its xy chace > >> > with bogus values... > >> > >> Ugh... > > > > We need the notion of 'visible paragraphs of main text'. > > BufferView::updateInset() would benefit from it as well... > > > > Should not be hard: A pair of ParagraphList::iterators build by summing > > up a few y values around bv->text->cursorPar()... > > > Why don't we set them up in the draw() stage? This is where the correct > cache positions get computed anyway. Good idea. 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...)
[patch] merge update() & updateInset()
and most of the explicit update() calls in the dispatchers can
bprobably be removed as well. The dispatch result should take care of
it...
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: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.207
diff -u -p -r1.207 BufferView.C
--- BufferView.C10 Nov 2003 09:06:31 - 1.207
+++ BufferView.C10 Nov 2003 13:14:50 -
@@ -394,12 +394,6 @@ void BufferView::hideCursor()
}
-void BufferView::updateInset(InsetOld const * inset)
-{
- pimpl_->updateInset(inset);
-}
-
-
bool BufferView::ChangeRefsIfUnique(string const & from, string const & to)
{
// Check if the label 'from' appears more than once
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.151
diff -u -p -r1.151 BufferView.h
--- BufferView.h10 Nov 2003 09:06:31 - 1.151
+++ BufferView.h10 Nov 2003 13:14:50 -
@@ -86,19 +86,6 @@ public:
bool fitCursor();
/// perform pending painting updates
void update();
- /** update for a particular inset. Gets a pointer and not a
-* reference because we really need the pointer information
-* to find it in the buffer.
- *
-* Extracted from Matthias notes:
-*
-* If a inset wishes any redraw and/or update it just has to call
-* updateInset(this). It's is completly irrelevant, where the inset is.
- * UpdateInset will find it in any paragraph in any buffer.
-* Of course the insets in the current paragraph/buffer
-* are checked first, so no performance problem should occur.
-*/
- void updateInset(InsetOld const *);
/// reset the scrollbar to reflect current view position
void updateScrollbar();
/// FIXME
@@ -196,9 +183,9 @@ public:
bool dispatch(FuncRequest const & argument);
/// set target x position of cursor
- void BufferView::x_target(int x);
+ void x_target(int x);
/// return target x position of cursor
- int BufferView::x_target() const;
+ int x_target() const;
/// access to cursor
LCursor & cursor();
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.455
diff -u -p -r1.455 BufferView_pimpl.C
--- BufferView_pimpl.C 10 Nov 2003 11:26:33 - 1.455
+++ BufferView_pimpl.C 10 Nov 2003 13:14:50 -
@@ -599,9 +599,17 @@ void BufferView::Pimpl::update()
{
//lyxerr << "BufferView::update()" << endl;
// fix cursor coordinate cache in case something went wrong
+
+ // check needed to survive LyX startup
if (bv_->getLyXText()) {
- // check needed to survive LyX startup
bv_->getLyXText()->redoCursor();
+
+ // update all 'visible' paragraphs
+ ParagraphList::iterator beg, end;
+ getVisiblePars(beg, end);
+ bv_->text->redoParagraphs(beg, end);
+
+ updateScrollbar();
}
screen().redraw(*bv_);
}
@@ -938,7 +946,7 @@ bool BufferView::Pimpl::workAreaDispatch
cmd2.y -= inset->y();
res = inset->dispatch(cmd2);
if (res.update())
- bv_->updateInset(inset);
+ bv_->update();
res.update(false);
}
@@ -1094,8 +1102,7 @@ bool BufferView::Pimpl::dispatch(FuncReq
InsetBase * inset = owner_->getDialogs().getOpenInset(name);
if (inset) {
// This works both for 'original' and 'mathed' insets.
- // Note that the localDispatch performs updateInset
- // also.
+ // Note that the localDispatch performs update also.
FuncRequest fr(bv_, LFUN_INSET_MODIFY, ev.argument);
inset->dispatch(fr);
} else {
@@ -1107,21 +1114,10 @@ bool BufferView::Pimpl::dispatch(FuncReq
case LFUN_INSET_INSERT: {
InsetOld * inset = createInset(ev);
- if (inset && insertInset(inset)) {
- updateInset(inset);
-
- string const name = ev.getArg(0);
- if (name == "bibitem") {
- // We need to do a redraw because the maximum
- // InsetBibitem width could have changed
-#warning check whether the update() is needed at
lyx.org
Can't view it with Netscape 4.75 any more, but it looks good under Opera. Bye for awhile, Garst
Re: [patch] merge update() & updateInset()
Andre Poenitz wrote: > and most of the explicit update() calls in the dispatchers can > bprobably be removed as well. The dispatch result should take care of > it... Things are looking much better. The following seems to be the reason of a few of the bogus insetHits we were getting while clicking in the main text. Is it right?: Index: BufferView_pimpl.C === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v retrieving revision 1.456 diff -u -p -u -r1.456 BufferView_pimpl.C --- BufferView_pimpl.C 10 Nov 2003 13:23:08 - 1.456 +++ BufferView_pimpl.C 10 Nov 2003 13:51:52 - @@ -933,7 +933,7 @@ bool BufferView::Pimpl::workAreaDispatch // handle this event. // built temporary path to inset - InsetOld * inset = insetFromCoords(bv_, cmd.x, cmd.y); + InsetOld * inset = insetFromCoords(bv_, cmd.x, cmd.y + top_y()); FuncRequest cmd1(cmd, bv_); DispatchResult res; There is another problem I think: and it is the outer cursor getting out-of-sync with where the real action is happening (if the action happends inside an inset). There are a few things that rely on that sync, and shouldn't (fitCursor for instance). Alfredo
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 02:59:51PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > and most of the explicit update() calls in the dispatchers can > > bprobably be removed as well. The dispatch result should take care of > > it... > > Things are looking much better. > > The following seems to be the reason of a few of the bogus insetHits we were > getting while clicking in the main text. Is it right?: > > Index: BufferView_pimpl.C > === > RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v > retrieving revision 1.456 > diff -u -p -u -r1.456 BufferView_pimpl.C > --- BufferView_pimpl.C 10 Nov 2003 13:23:08 - 1.456 > +++ BufferView_pimpl.C 10 Nov 2003 13:51:52 - > @@ -933,7 +933,7 @@ bool BufferView::Pimpl::workAreaDispatch > // handle this event. > > // built temporary path to inset > - InsetOld * inset = insetFromCoords(bv_, cmd.x, cmd.y); > + InsetOld * inset = insetFromCoords(bv_, cmd.x, cmd.y + top_y()); > FuncRequest cmd1(cmd, bv_); > DispatchResult res; I don't really know. I am still a bit confused about coordinates... > There is another problem I think: and it is the outer cursor getting > out-of-sync with where the real action is happening (if the action happends > inside an inset). Like asynchronous inset updates because the conversion finished? This should be harmless, they simply get ignored. But that's ok as they are off-screen anyway. Next time we come to that place, the paragraph (and scrollbar size) is adjusted. The only 'problem' is that the scrollbar position does not match exactly reality, but its 'not that bad'. > There are a few things that rely on that sync, and > shouldn't (fitCursor for instance). Anything else than the scrollbar issues? 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...)
Re: [patch] merge update() & updateInset()
Andre Poenitz wrote: > I don't really know. I am still a bit confused about coordinates... Hum... it would be time to take a decision then? ;-) Are inset coordinates relative to the parent or absolute? >> There is another problem I think: and it is the outer cursor getting >> out-of-sync with where the real action is happening (if the action >> happends inside an inset). > > Like asynchronous inset updates because the conversion finished? > > This should be harmless, they simply get ignored. But that's ok as they > are off-screen anyway. Next time we come to that place, the paragraph > (and scrollbar size) is adjusted. > > The only 'problem' is that the scrollbar position does not match exactly > reality, but its 'not that bad'. > > >> There are a few things that rely on that sync, and >> shouldn't (fitCursor for instance). > > Anything else than the scrollbar issues? IIUC, it's worse than that, for instance fitCursor, and your recently introduced getVisiblePars use the top old cursor (bv_->text->cursor), that can be completely out-of-sync with where the action is happening, am I right? Alfredo
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 03:12:02PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > I don't really know. I am still a bit confused about coordinates... > > Hum... it would be time to take a decision then? ;-) Are inset coordinates > relative to the parent or absolute? I don't even have a gut feeling here... Another option would be to have absolute _screen_ coordinates for insets. > >> There is another problem I think: and it is the outer cursor getting > >> out-of-sync with where the real action is happening (if the action > >> happends inside an inset). > > > > Like asynchronous inset updates because the conversion finished? > > > > This should be harmless, they simply get ignored. But that's ok as they > > are off-screen anyway. Next time we come to that place, the paragraph > > (and scrollbar size) is adjusted. > > > > The only 'problem' is that the scrollbar position does not match exactly > > reality, but its 'not that bad'. > > > > > >> There are a few things that rely on that sync, and > >> shouldn't (fitCursor for instance). > > > > Anything else than the scrollbar issues? > > IIUC, it's worse than that, for instance fitCursor, and your recently > introduced getVisiblePars use the top old cursor (bv_->text->cursor), that > can be completely out-of-sync with where the action is happening, am I > right? Yes. But it's just for redrawing, nothing else. And we always redraw the whole screen. It's not bad if we miss an action because the cursor is too far off: It won't be visible anyway. Andre'
Re: [patch] merge update() & updateInset()
Andre Poenitz wrote: > On Mon, Nov 10, 2003 at 03:12:02PM +0100, Alfredo Braunstein wrote: >> Andre Poenitz wrote: >> >> > I don't really know. I am still a bit confused about coordinates... >> >> Hum... it would be time to take a decision then? ;-) Are inset >> coordinates relative to the parent or absolute? > > I don't even have a gut feeling here... > > Another option would be to have absolute _screen_ coordinates for insets. Uhmm... indeed I think that this is what's in the code (so my patch is wrong). But there's something rotten about coordinates. For instance, in any hit in LyXTexT::checkInsetHit, y is incremented by top_y... so clearly checkInsetHit cannot be called in a loop like it is. >> IIUC, it's worse than that, for instance fitCursor, and your recently >> introduced getVisiblePars use the top old cursor (bv_->text->cursor), >> that can be completely out-of-sync with where the action is happening, am >> I right? > > Yes. > > But it's just for redrawing, nothing else. And we always redraw the > whole screen. > > It's not bad if we miss an action because the cursor is too far off: It > won't be visible anyway. No, I mean that the cursor recenters around completely wrong coordinates sometimes. (i.e., for instance click in the main text, scroll with the scrollbar, click somewhere inside an inset, and then everything is wrong) I think that the old code used to put the top cursor behind the top locked inset or something. Alfredo
Re: [patch] merge update() & updateInset()
Hmm collapsable insets seem to work OK now. But "button insets" like label and index entry and URL (CommandInset derived) don't respond to clicking. And I cannot insert them anymore :-( I'm getting ### NOT DISPATCHED BY Cursor::dispatch() ### ... and no inset. - Martin pgp0.pgp Description: PGP signature
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 03:33:51PM +0100, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > On Mon, Nov 10, 2003 at 03:12:02PM +0100, Alfredo Braunstein wrote: > >> Andre Poenitz wrote: > >> > >> > I don't really know. I am still a bit confused about coordinates... > >> > >> Hum... it would be time to take a decision then? ;-) Are inset > >> coordinates relative to the parent or absolute? > > > > I don't even have a gut feeling here... > > > > Another option would be to have absolute _screen_ coordinates for insets. > > Uhmm... indeed I think that this is what's in the code (so my patch is > wrong). But there's something rotten about coordinates. Indeed. But it has been like that all the time. Corrections. Corrections of correction... > For instance, in any hit in LyXTexT::checkInsetHit, y is incremented > by top_y... so clearly checkInsetHit cannot be called in a loop like > it is. Good point. Do you know whether we need to modify the value at all? > > It's not bad if we miss an action because the cursor is too far off: > > It won't be visible anyway. > > No, I mean that the cursor recenters around completely wrong > coordinates sometimes. (i.e., for instance click in the main text, > scroll with the scrollbar, click somewhere inside an inset, and then > everything is wrong) I can see it. > I think that the old code used to put the top > cursor behind the top locked inset or something. Does not sound like a nice solution... Should we try to use 'absolute screen coordinates' all over the place? There would be a 'top_y' as we have now (and maybe top_x), but everything else is relative to this (top_x, top_y) point. 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...)
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 05:23:14PM +0200, Martin Vermeer wrote: > Hmm collapsable insets seem to work OK now. But "button insets" like > label and index entry and URL (CommandInset derived) don't respond to > clicking. They do not set their top_baseline/top_x in draw. I've just seen this myself. I'll fix that tonight. > And I cannot insert them anymore :-( Poor little tiger ;-) > I'm getting ### NOT DISPATCHED BY Cursor::dispatch() ### ... and no > inset. Care to investigate? 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...)
[patch] click on TOC
Bugfix _and_ a step towards IU in one patch...
mathed's xo_/yo_ and inset's top_x/top_baseline cache have been
functionally the same. This uses now xo_/yo_ all over the place and
removes mathed's "double caching"
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...)
? 1.diff
? 1.diff.gz
? 2.diff
? 3.diff
? ?t
? fullredraw.diff
? par-row.diff
? textcache.diff
? insets/.insetcommand.C.swp
? insets/.insettoc.C.swp
? insets/1.diff
? mathed/cursor.diff
? support/1.diff
Index: insets/inset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.C,v
retrieving revision 1.116
diff -u -p -r1.116 inset.C
--- insets/inset.C 10 Nov 2003 09:06:40 - 1.116
+++ insets/inset.C 10 Nov 2003 15:27:52 -
@@ -26,14 +26,14 @@ using std::string;
InsetOld::InsetOld()
: InsetBase(),
- top_x(0), top_baseline(0), scx(0), owner_(0),
+ xo_(0), yo_(0), scx(0), owner_(0),
background_color_(LColor::inherit)
{}
InsetOld::InsetOld(InsetOld const & in)
: InsetBase(),
- top_x(0), top_baseline(0), scx(0), owner_(0),
+ xo_(0), yo_(0), scx(0), owner_(0),
name_(in.name_), background_color_(in.background_color_)
{}
Index: insets/inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.139
diff -u -p -r1.139 inset.h
--- insets/inset.h 10 Nov 2003 11:26:33 - 1.139
+++ insets/inset.h 10 Nov 2003 15:27:52 -
@@ -213,9 +213,9 @@ public:
///
LColor_color backgroundColor() const;
///
- int x() const { return top_x; }
+ int x() const { return xo_; }
///
- int y() const { return top_baseline; }
+ int y() const { return yo_; }
///
virtual void deleteLyXText(BufferView *, bool = true) const {}
/// returns the actuall scroll-value
@@ -288,9 +288,9 @@ public:
virtual void addPreview(lyx::graphics::PreviewLoader &) const {}
protected:
///
- mutable int top_x;
+ mutable int xo_;
///
- mutable int top_baseline;
+ mutable int yo_;
///
mutable int scx;
///
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.202
diff -u -p -r1.202 insetcollapsable.C
--- insets/insetcollapsable.C 10 Nov 2003 14:29:39 - 1.202
+++ insets/insetcollapsable.C 10 Nov 2003 15:27:52 -
@@ -146,8 +146,8 @@ void InsetCollapsable::draw(PainterInfo
button_dim.y1 = -aa;
button_dim.y2 = -aa + dim_collapsed.height();
- top_x = x;
- top_baseline = y;
+ xo_ = x;
+ yo_ = y;
if (!isOpen()) {
draw_collapsed(pi, x, y);
@@ -327,7 +327,7 @@ InsetCollapsable::priv_dispatch(FuncRequ
int InsetCollapsable::insetInInsetY() const
{
- return inset.y() - top_baseline + inset.insetInInsetY();
+ return inset.y() - yo_ + inset.insetInInsetY();
}
Index: insets/insetcommand.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcommand.C,v
retrieving revision 1.102
diff -u -p -r1.102 insetcommand.C
--- insets/insetcommand.C 10 Nov 2003 13:23:11 - 1.102
+++ insets/insetcommand.C 10 Nov 2003 15:27:52 -
@@ -48,6 +48,8 @@ void InsetCommand::metrics(MetricsInfo &
void InsetCommand::draw(PainterInfo & pi, int x, int y) const
{
+ xo_ = x;
+ yo_ = y;
button_.draw(pi, x, y);
}
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.372
diff -u -p -r1.372 insettabular.C
--- insets/insettabular.C 10 Nov 2003 13:23:12 - 1.372
+++ insets/insettabular.C 10 Nov 2003 15:27:53 -
@@ -255,8 +255,8 @@ void InsetTabular::draw(PainterInfo & pi
if (!owner())
x += scroll();
- top_x = x;
- top_baseline = y;
+ xo_ = x;
+ yo_ = y;
x += ADD_TO_TABULAR_WIDTH;
int cell = 0;
@@ -474,7 +474,7 @@ void InsetTabular::edit(BufferView * bv,
setPos(bv, x, y);
clearSelection();
finishUndo();
- int xx = cursorx_ - top_x + tabular.getBeginningOfTextInCell(actcell);
+ int xx = cursorx_ - xo_ + tabular.getBeginningOfTextInCell(actcell);
bv->cursor().push(this);
if (x > xx)
activateCellInset(bv, x - xx, y - cursory_);
@@ -623,7 +623,7 @@ InsetTabular::priv_dispatch(FuncRequest
clearSelection();
int column = actc
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 05:23:14PM +0200, Martin Vermeer wrote: > Hmm collapsable insets seem to work OK now. But "button insets" like > label and index entry and URL (CommandInset derived) don't respond to > clicking. And I cannot insert them anymore :-( > > I'm getting ### NOT DISPATCHED BY Cursor::dispatch() ### ... and no > inset. Actually, almost every "text related" LFUN handling should be moved from the BufferView::dispatch to LyXText::dispatched. Inserting an inset is "text related" 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...)
insethit
I don't know why, but we still get bogus insetHits from some far away tabular in the Userguide... Open UG, click somewhere in the main text: nothing happends but Hit inset: 0x8745900 dispatching action 219 to inset 0x8745900 InsetTabular::dispatch: action: 219 arg: '' x: 265 y: 98 Alfredo
Re: insethit
On Mon, Nov 10, 2003 at 05:01:38PM +0100, Alfredo Braunstein wrote: > I don't know why, but we still get bogus insetHits from some far away > tabular in the Userguide... This is probably the tabular's xo/yo cache set to some bogus value (read "0") as the inset was never drawn on screen so the xo/yo cache are never set. Quick & Dirty: Initialize xo/yo to '10/10'. No screen is _that_ large. Proper: check for insetHit only in the range of visible paragraphs. 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...)
Re: insethit
Andre Poenitz wrote: > On Mon, Nov 10, 2003 at 05:01:38PM +0100, Alfredo Braunstein wrote: >> I don't know why, but we still get bogus insetHits from some far away >> tabular in the Userguide... > > This is probably the tabular's xo/yo cache set to some bogus value > (read "0") as the inset was never drawn on screen so the xo/yo cache are > never set. > > Quick & Dirty: Initialize xo/yo to '10/10'. No screen is _that_ > large. > > Proper: check for insetHit only in the range of visible paragraphs. Ah, ok, I though that we did that already. I see, we have getVisiblePars but it's not called from checkInsetHit. Alfredo
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 04:14:38PM +0100, Andre Poenitz spake thusly: > Care to investigate? Sure. Here's the output when I click on a label, and then on another label further down: checkInsetHit: x: 79 y: 350 examining inset 0x08b1b538 xy: 0/0 x: 0...14 y: -21...6 examining inset 0x08b04b50 xy: 284/140 x: 284...393 y: 125...146 examining inset 0x08b051c8 xy: 30/164 x: 30...701 y: 149...224 examining inset 0x08b17288 xy: 58/350 x: 58...96 y: 335...356 Hit inset: 0x08b17288 dispatching action 217 to inset 0x08b17288 not dispatched by inner inset val: 0 cursor is: inset: 0x08b051c8 text: 0x08b05258 x: 30 y: 164 dispatching action: 217 arg: '' x: 79 y: 350 to surrounding LyXText 0x08b05258 LyXText::dispatch: cmd: action: 217 arg: '' x: 79 y: 350 Redraw screen BufferView::Pimpl::fitCursor. BufferView::fitLockedInsetCursor x: 62 y: 0 text->cursor.y: 350 insetInInsetY: 22 LyXScreen::fitManualCursor x: 62 y: 372 BufferView::Pimpl::fitCursor. BufferView::fitLockedInsetCursor x: 62 y: 0 text->cursor.y: 350 insetInInsetY: 22 LyXScreen::fitManualCursor x: 62 y: 372 checkInsetHit: x: 92 y: 535 examining inset 0x08b1b538 xy: 0/0 x: 0...14 y: -21...6 examining inset 0x08b04b50 xy: 284/140 x: 284...393 y: 125...146 examining inset 0x08b051c8 xy: 30/164 x: 30...701 y: 149...224 examining inset 0x08b17288 xy: 58/350 x: 58...96 y: 335...356 examining inset 0x08b04a88 xy: 58/538 x: 58...112 y: 523...544 Hit inset: 0x08b04a88 dispatching action 217 to inset 0x08b04a88 not dispatched by inner inset val: 0 cursor is: inset: 0x08b051c8 text: 0x08b05258 x: 30 y: 164 dispatching action: 217 arg: '' x: 92 y: 535 to surrounding LyXText 0x08b05258 LyXText::dispatch: cmd: action: 217 arg: '' x: 92 y: 535 Redraw screen BufferView::Pimpl::fitCursor. BufferView::fitLockedInsetCursor x: 62 y: 0 text->cursor.y: 538 insetInInsetY: 22 LyXScreen::fitManualCursor x: 62 y: 560 BufferView::Pimpl::fitCursor. BufferView::fitLockedInsetCursor x: 62 y: 0 text->cursor.y: 538 insetInInsetY: 22 LyXScreen::fitManualCursor x: 62 y: 560 ...and nothing happens. - Martin pgp0.pgp Description: PGP signature
[patch] a bit of fixing
Let me remember: - on clicks that do not hit anything, dispatch to the main text, not to the inner txt of the old par. Set the global cursor to that text (it was impossible to exit an inset by clicking) - Remove an unuseful fitCursor call (we cannot call fitcursor in unhandled click event: the PRESS event moves the screen, then the RELEASE event ends up in nowhere!). I think that there is one more left somewhere. - move getVisiblePars to paragraph_funcs and call it getParsInRange (get a range of pars in a range of y) - use that from checkInsetHit - take out references from checkInsetHit arguments (and so solve the y += top_y problem) Alfredo
Re: [patch] a bit of fixing
Alfredo Braunstein wrote:
> - on clicks that do not hit anything, dispatch to the main text, not to
> the inner txt of the old par. Set the global cursor to that text (it was
^^^
I meant old cursor.
Here is the patch.
Alfredo
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.457
diff -u -p -u -r1.457 BufferView_pimpl.C
--- BufferView_pimpl.C 10 Nov 2003 14:29:38 - 1.457
+++ BufferView_pimpl.C 10 Nov 2003 17:31:05 -
@@ -605,8 +605,11 @@ void BufferView::Pimpl::update()
bv_->getLyXText()->redoCursor();
// update all 'visible' paragraphs
- ParagraphList::iterator beg, end;
- getVisiblePars(beg, end);
+ ParagraphList::iterator beg;
+ ParagraphList::iterator end;
+ getParsInRange(buffer_->paragraphs(),
+ top_y(), top_y() + workarea().workHeight(),
+ beg, end);
bv_->text->redoParagraphs(beg, end);
updateScrollbar();
@@ -968,7 +971,8 @@ bool BufferView::Pimpl::workAreaDispatch
lyxerr << "cursor is: " << bv_->cursor() << endl;
lyxerr << "dispatching " << cmd1 << " to surrounding LyXText "
<< bv_->cursor().innerText() << endl;
- bv_->cursor().innerText()->dispatch(cmd1);
+ theTempCursor.innerText()->dispatch(cmd1);
+ cursor_ = theTempCursor;
//return DispatchResult(true, true);
}
@@ -979,7 +983,7 @@ bool BufferView::Pimpl::workAreaDispatch
// FIXME: we should skip these when selecting
owner_->updateLayoutChoice();
owner_->updateToolbar();
- fitCursor();
+// fitCursor();
// slight hack: this is only called currently when we
// clicked somewhere, so we force through the display
@@ -1341,20 +1345,3 @@ void BufferView::Pimpl::updateParagraphD
}
-void BufferView::Pimpl::getVisiblePars
- (ParagraphList::iterator & beg, ParagraphList::iterator & end)
-{
- beg = bv_->text->cursorPar();
- end = beg;
-
- for ( ; beg != bv_->text->ownerParagraphs().begin(); --beg)
- if (beg->y - top_y() < 0)
- break;
-
- if (beg != bv_->text->ownerParagraphs().begin())
- --beg;
-
- for ( ; end != bv_->text->ownerParagraphs().end(); ++end)
- if (end->y - top_y() > workarea().workHeight())
- break;
-}
Index: BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.109
diff -u -p -u -r1.109 BufferView_pimpl.h
--- BufferView_pimpl.h 10 Nov 2003 13:23:09 - 1.109
+++ BufferView_pimpl.h 10 Nov 2003 17:31:07 -
@@ -193,8 +193,6 @@ private:
void MenuInsertLyXFile(std::string const & filen);
/// our workarea
WorkArea & workarea() const;
- /// range of visible main text paragraphs
- void getVisiblePars(ParagraphList::iterator &, ParagraphList::iterator &);
///
LCursor cursor_;
Index: bufferview_funcs.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/bufferview_funcs.h,v
retrieving revision 1.27
diff -u -p -u -r1.27 bufferview_funcs.h
--- bufferview_funcs.h 10 Nov 2003 09:06:34 - 1.27
+++ bufferview_funcs.h 10 Nov 2003 17:31:08 -
@@ -61,7 +61,6 @@ std::string const currentState(BufferVie
void replaceSelection(LyXText * lt);
-
}; // namespace bv_funcs
#endif
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.252
diff -u -p -u -r1.252 lyxtext.h
--- lyxtext.h 10 Nov 2003 09:06:35 - 1.252
+++ lyxtext.h 10 Nov 2003 17:31:09 -
@@ -343,9 +343,8 @@ public:
void updateCounters();
/**
* Returns an inset if inset was hit, or 0 if not.
- * If hit, the coordinates are changed relative to the inset.
*/
- InsetOld * checkInsetHit(int & x, int & y);
+ InsetOld * checkInsetHit(int x, int y);
///
int singleWidth(ParagraphList::iterator pit, lyx::pos_type pos) const;
Index: paragraph_funcs.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph_funcs.C,v
retrieving revision 1.86
diff -u -p -u -r1.86 paragraph_funcs.C
--- paragraph_funcs.C 6 Nov 2003 10:52:15 - 1.86
+++ paragraph_funcs.C 10 Nov 2003 17:31:10 -
@@ -610,3 +610,24 @@ Paragraph const & ownerPar(Buffer const
BOOST_ASSERT(false);
return buf.paragraphs().front(); // shut up compiler
}
+
+
+
+
+void getParsInRange(ParagraphList & pl,
+ int ystart, int yend,
+ ParagraphList::iterator & beg,
+ ParagraphList::iterator & end)
+{
+ ParagraphList::iterator const endpar = pl.end();
+ ParagraphList::iterator const begpar = pl.begin();
+
+ BOOST_ASSERT(begpar != endpar);
+
+ beg = endpar;
+ for (--beg; beg != begpar && beg->y > ystart; --beg)
+ ;
+
+ for (end = beg ; end != endpar && end->y < yend; ++end)
+ ;
+}
Index: paragraph_funcs.h
===
Re: [patch] merge update() & updateInset()
Andre Poenitz wrote: >> For instance, in any hit in LyXTexT::checkInsetHit, y is incremented >> by top_y... so clearly checkInsetHit cannot be called in a loop like >> it is. > > Good point. > > Do you know whether we need to modify the value at all? It's not used now, but it looks as if it had some purpose once. (removed in patch in other thread) >> > It's not bad if we miss an action because the cursor is too far off: >> > It won't be visible anyway. >> >> No, I mean that the cursor recenters around completely wrong >> coordinates sometimes. (i.e., for instance click in the main text, >> scroll with the scrollbar, click somewhere inside an inset, and then >> everything is wrong) > > I can see it. the are still some exceding fitCursor calls. >> I think that the old code used to put the top >> cursor behind the top locked inset or something. > > Does not sound like a nice solution... Not at all. I was trying to understand what happened. > Should we try to use 'absolute screen coordinates' all over the place? > There would be a 'top_y' as we have now (and maybe top_x), but > everything else is relative to this (top_x, top_y) point. I think that all seems to go better now. I'd prefer if we stick with this scheme (insets have coordinates relative to top_y, paragraphs absolute coords, rows relative to paragraph) until we iron out all recently introduced regressions and then think again about it. I think that things are starting to look good... Alfredo
Re: [patch] a bit of fixing
On Mon, Nov 10, 2003 at 06:33:32PM +0100, Alfredo Braunstein wrote: > Let me remember: > > - on clicks that do not hit anything, dispatch to the main text, not to the > inner txt of the old par. Set the global cursor to that text Yes. > (it was impossible to exit an inset by clicking) My fault... > - Remove an unuseful fitCursor call (we cannot call fitcursor in unhandled > click event: the PRESS event moves the screen, then the RELEASE event ends > up in nowhere!). I think that there is one more left somewhere. Ah good.. > - move getVisiblePars to paragraph_funcs and call it getParsInRange (get a > range of pars in a range of y) > > - use that from checkInsetHit > > - take out references from checkInsetHit arguments (and so solve the y += > top_y problem) Fine. 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...)
Re: [patch] a bit of fixing
On Mon, Nov 10, 2003 at 06:42:42PM +0100, Alfredo Braunstein wrote: > Alfredo Braunstein wrote: > > > - on clicks that do not hit anything, dispatch to the main text, not to > > the inner txt of the old par. Set the global cursor to that text (it was >^^^ > I meant old cursor. > > Here is the patch. Just commit. 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...)
Re: [patch] merge update() & updateInset()
On Mon, Nov 10, 2003 at 07:07:48PM +0100, Alfredo Braunstein wrote: > > Should we try to use 'absolute screen coordinates' all over the place? > > There would be a 'top_y' as we have now (and maybe top_x), but > > everything else is relative to this (top_x, top_y) point. > > I think that all seems to go better now. I'd prefer if we stick with this > scheme (insets have coordinates relative to top_y, paragraphs absolute > coords, rows relative to paragraph) until we iron out all recently > introduced regressions and then think again about it. Fine with me. > I think that things are starting to look good... That's what I was hoping for... 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...)
[patch]
Small cleanup. Unused parameter + unneeded cast
--
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: InsetList.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/InsetList.C,v
retrieving revision 1.15
diff -u -p -r1.15 InsetList.C
--- InsetList.C 14 Oct 2003 13:01:39 - 1.15
+++ InsetList.C 10 Nov 2003 17:09:50 -
@@ -182,10 +182,8 @@ void InsetList::deleteInsetsLyXText(Buff
List::iterator it = list.begin();
List::iterator end = list.end();
for (; it != end; ++it) {
- if (it->inset && it->inset->isTextInset()) {
- static_cast
- (it->inset)->deleteLyXText(bv, true);
- }
+ if (it->inset)
+ it->inset->deleteLyXText(bv);
}
}
Index: insets/inset.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.C,v
retrieving revision 1.117
diff -u -p -r1.117 inset.C
--- insets/inset.C 10 Nov 2003 15:38:17 - 1.117
+++ insets/inset.C 10 Nov 2003 17:09:52 -
@@ -141,6 +141,13 @@ bool InsetOld::checkInsertChar(LyXFont &
}
+int InsetOld::scroll(bool recursive) const
+{
+ if (!recursive || !owner_)
+ return scx;
+ return 0;
+}
+
bool isEditableInset(InsetOld const * i)
{
return i && i->editable();
Index: insets/inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.140
diff -u -p -r1.140 inset.h
--- insets/inset.h 10 Nov 2003 15:38:17 - 1.140
+++ insets/inset.h 10 Nov 2003 17:09:52 -
@@ -217,13 +217,9 @@ public:
///
int y() const { return yo_; }
///
- virtual void deleteLyXText(BufferView *, bool = true) const {}
- /// returns the actuall scroll-value
- virtual int scroll(bool recursive=true) const {
- if (!recursive || !owner_)
- return scx;
- return 0;
- }
+ virtual void deleteLyXText(BufferView *) const {}
+ /// returns the actual scroll-value
+ virtual int scroll(bool recursive = true) const;
/// if this insets owns paragraphs (f.ex. InsetText) then it
/// should return it's very first one!
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.203
diff -u -p -r1.203 insetcollapsable.C
--- insets/insetcollapsable.C 10 Nov 2003 15:38:17 - 1.203
+++ insets/insetcollapsable.C 10 Nov 2003 17:09:53 -
@@ -351,9 +351,9 @@ void InsetCollapsable::setFont(BufferVie
}
-void InsetCollapsable::deleteLyXText(BufferView * bv, bool recursive) const
+void InsetCollapsable::deleteLyXText(BufferView * bv) const
{
- inset.deleteLyXText(bv, recursive);
+ inset.deleteLyXText(bv);
}
Index: insets/insetcollapsable.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.h,v
retrieving revision 1.145
diff -u -p -r1.145 insetcollapsable.h
--- insets/insetcollapsable.h 10 Nov 2003 11:26:33 - 1.145
+++ insets/insetcollapsable.h 10 Nov 2003 17:09:53 -
@@ -92,7 +92,7 @@ public:
void setAutoCollapse(bool f);
#endif
///
- void deleteLyXText(BufferView *, bool recursive=true) const;
+ void deleteLyXText(BufferView *) const;
/// Appends \c list with all labels found within this inset.
void getLabelList(Buffer const &, std::vector & list) const;
///
Index: insets/insettabular.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.C,v
retrieving revision 1.373
diff -u -p -r1.373 insettabular.C
--- insets/insettabular.C 10 Nov 2003 15:38:17 - 1.373
+++ insets/insettabular.C 10 Nov 2003 17:09:56 -
@@ -1650,8 +1650,9 @@ bool InsetTabular::activateCellInset(Buf
}
-void InsetTabular::deleteLyXText(BufferView * /*bv*/, bool /*recursive*/) const
+void InsetTabular::deleteLyXText(BufferView * /*bv*/) const
{
+#warning this is strange, isnt it? But this is 1.3.x code...
//resizeLyXText(bv, recursive);
}
Index: insets/insettabular.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insettabular.h,v
retrieving revision 1.164
diff -u -p -r1.164 insettabular.h
--- insets/insettabular.h 10 Nov 2003 09:06:46 - 1.164
+++ insets/insettabular.h 10 Nov 2003 17:09:56 -
@@ -122,7 +122,7 @@ public:
Re: [patch] a bit of fixing
On Mon, Nov 10, 2003 at 07:12:41PM +0100, Andre' Poenitz wrote: > On Mon, Nov 10, 2003 at 06:42:42PM +0100, Alfredo Braunstein wrote: > > Alfredo Braunstein wrote: > > > > > - on clicks that do not hit anything, dispatch to the main text, not to > > > the inner txt of the old par. Set the global cursor to that text (it was > >^^^ > > I meant old cursor. > > > > Here is the patch. > > Just commit. Well. I did ;-} Andre'
deleteInsetLyXText & Co
Does this serve any purpose nowadays? 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...)
Re: [patch] a bit of fixing
Andre Poenitz wrote: > Well. I did ;-} I didn't even had time to cvs up && make ;-) Alfredo
fitCursor is badly hosed
One of the problems I see is that the insets lose track of their position if we scroll away. Maybe a solution would be to cache the absolute y position of the tip inset in LCursor as soon as it is push()ed. If this seems reasonable I would try to do it tomorrow. Alfredo
Re: fitCursor is badly hosed
Alfredo Braunstein wrote:
> One of the problems I see is that the insets lose track of their position
> if we scroll away.
>
> Maybe a solution would be to cache the absolute y position of the tip
> inset in LCursor as soon as it is push()ed.
>
> If this seems reasonable I would try to do it tomorrow.
If done this and works reasonably well.
this deactivates the zillion fitCursor derivatives and helpers all around,
and does the [very simple] work in BufferView::Pimpl::fitCursor. I don't
understand the other code very well so I've not removed it.
Hints/explanations welcomed (the code in screen.C in particular).
The trick is to cache the cursor y position in LCursor at pushing time. In
that way we can make LCursor::getPos return an absolute y value, and so
make things much simpler.
there's still something tricky in the insets: we need to update() before
pushing the cursor, or otherwise the cached position may be wrong. And we
need not to call fitCursor before the right position is pushed into the
cursor (this one is easy: fitcursor should be called only by the
centralized mechanism, at the end of the call).
But we need to rationalize the update calls anyway, and when we do that, we
can add an LCursor::update_cache method or something to update the cache at
the exact moment we want (I think after an update, in workAreadispatch).
Comments?
Alfredo
Index: BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.458
diff -u -p -u -r1.458 BufferView_pimpl.C
--- BufferView_pimpl.C 10 Nov 2003 18:15:52 - 1.458
+++ BufferView_pimpl.C 10 Nov 2003 23:02:23 -
@@ -346,6 +346,18 @@ bool BufferView::Pimpl::fitCursor()
bool ret;
#ifndef LOCK
+ int x,y;
+
+ bv_->cursor().getPos(x, y);
+
+ if (y < top_y() || y > top_y() + workarea().workHeight()) {
+ int newtop = y - workarea().workHeight() / 2;
+ newtop = std::max(0, newtop);
+ top_y(newtop);
+ return true;
+ }
+ return false;
+
UpdatableInset * tli =
static_cast(cursor_.innerInset());
if (tli) {
@@ -958,7 +970,8 @@ bool BufferView::Pimpl::workAreaDispatch
case FINISHED_DOWN:
theTempCursor.pop();
bv_->cursor() = theTempCursor;
- bv_->cursor().innerText()->setCursorFromCoordinates(cmd.x, cmd.y);
+ bv_->cursor().innerText()->setCursorFromCoordinates(cmd.x, top_y() + cmd.y);
+ bv_->fitCursor();
return true;
default:
lyxerr << "not dispatched by inner inset val: " << res.val() << endl;
@@ -969,13 +982,15 @@ bool BufferView::Pimpl::workAreaDispatch
// otherwise set cursor to surrounding LyXText
if (!res.dispatched()) {
lyxerr << "cursor is: " << bv_->cursor() << endl;
- lyxerr << "dispatching " << cmd1 << " to surrounding LyXText "
-<< bv_->cursor().innerText() << endl;
- theTempCursor.innerText()->dispatch(cmd1);
+ lyxerr << "dispatching " << cmd1
+ << " to surrounding LyXText "
+ << bv_->cursor().innerText() << endl;
cursor_ = theTempCursor;
+ theTempCursor.dispatch(cmd1);
//return DispatchResult(true, true);
}
+ bv_->update();
// see workAreaKeyPress
cursor_timeout.restart();
screen().showCursor(*bv_);
Index: cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.C,v
retrieving revision 1.17
diff -u -p -u -r1.17 cursor.C
--- cursor.C 10 Nov 2003 13:23:09 - 1.17
+++ cursor.C 10 Nov 2003 23:02:24 -
@@ -113,6 +113,7 @@ void LCursor::push(UpdatableInset * inse
{
lyxerr << "LCursor::push() inset: " << inset << endl;
data_.push_back(CursorItem(inset));
+ cached_y_ = bv_->top_y() + inset->y();
}
@@ -161,7 +162,7 @@ void LCursor::getPos(int & x, int & y) c
if (data_.empty()) {
x = bv_->text->cursor.x();
y = bv_->text->cursor.y();
- y -= bv_->top_y();
+// y -= bv_->top_y();
} else {
// Would be nice to clean this up to make some understandable sense...
UpdatableInset * inset = innerInset();
@@ -176,7 +177,7 @@ void LCursor::getPos(int & x, int & y) c
//y = inset->insetInInsetY() + bv_->text->cursor.y();
inset->getCursorPos(bv_, x, y);
x += inset->x();
- y += inset->y();
+ y += cached_y_;
}
}
Index: cursor.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/cursor.h,v
retrieving revision 1.7
diff -u -p -u -r1.7 cursor.h
--- cursor.h 10 Nov 2003 09:40:14 - 1.7
+++ cursor.h 10 Nov 2003 23:02:24 -
@@ -82,6 +82,9 @@ public:
std::vector data_;
///
BufferView * bv_;
+private:
+ ///
+ int cached_y_;
};
#endif // LYXCURSOR_H
Index: frontends/screen.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/screen.C,v
retrieving revision 1.79
diff -u -p -u -r1.79 screen.C
--- frontends/screen.C 10 Nov 2003 09:06:38 - 1.79
+++ frontends/screen.C 10 Nov 2003
