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 tom
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
Andre Poenitz wrote:
> Well. I did ;-}
I didn't even had time to cvs up && make ;-)
Alfredo
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...)
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 c
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
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
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
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.
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
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
=
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 PR
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 0x08b04b5
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 n
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/y
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
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 Cur
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
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
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
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
Descriptio
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 paren
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 h
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 w
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 followi
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 clicki
Can't view it with Netscape 4.75 any more, but it looks good under
Opera.
Bye for awhile,
Garst
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 o
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...
> >
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: 0x
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
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/
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 mean
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 mean
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
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 n
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 asse
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;
>
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
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 inset
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
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 insetl
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
Sp
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
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.
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
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 see
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.
In
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
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
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 thin
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 ;
-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
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?
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 develo
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
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, eve
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 mat
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 docume
59 matches
Mail list logo
