> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I see. But then it is kind of global property "singleton",
Andre> nothing that needs to be replicated in the "cosmetic cursors"
Andre> used e.g. for iteration.
Yes.
JMarc
On Wed, Mar 28, 2007 at 05:53:20PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> I agree this would be the right thing to do. Or rather move the
> >> current font to the cursor.
>
> Andre> Why do we need to cache the current font at all? I
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> It is not caching. If I select Emph, I change current_font_ (for
>> the next insertion), not anything in the paragraph (this is how I
>> understand it in any case).
Bo> So, setCurrentFont should be applied at each text cursor move, not
Bo> mous
It is not caching. If I select Emph, I change current_font_ (for the
next insertion), not anything in the paragraph (this is how I
understand it in any case).
So, setCurrentFont should be applied at each text cursor move, not
mouse move. Either we add a mouse-move-version of editXY, or separate
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> I agree this would be the right thing to do. Or rather move the
>> current font to the cursor.
Andre> Why do we need to cache the current font at all? I recreating
Andre> it so expensive?
It is not caching. If I select Emph, I change
On Wed, Mar 28, 2007 at 09:06:43AM -0500, Bo Peng wrote:
> >I meant that changes of inset button behaviour looked straightforward
> >enough, but the devil is in the details.
>
> I plead guilty, but, :-)
>
> The devils lie in the fact that lyx kernel can not handle mouse
> movement well. The kerne
On Wed, Mar 28, 2007 at 10:53:08AM +0200, Jean-Marc Lasgouttes wrote:
> > "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>
> Richard> I suppose that's possible, but the problem seems to me to be
> Richard> the opposite. The way the code was, editXY was being called
> Richard> in BufferV
I meant that changes of inset button behaviour looked straightforward
enough, but the devil is in the details.
I plead guilty, but, :-)
The devils lie in the fact that lyx kernel can not handle mouse
movement well. The kernel is designed around text cursor which is
deeply entangled with lyxtext
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> But we are adding yet another way to find insets,
Abdelrazak> I know but I want to get rid of the other ones (not now)
Abdelrazak> because they have nothing to do in the LyXText class. I
Abdelrazak> will add some comments to
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jean-Marc Lasgouttes wrote:
>>> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
>>
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was
Jean-Marc Lasgouttes wrote:
"Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was being called
Richard> in BufferView::workAreaDispatch for the sole purpose of
Richard>
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> I suppose that's possible, but the problem seems to me to be
Richard> the opposite. The way the code was, editXY was being called
Richard> in BufferView::workAreaDispatch for the sole purpose of
Richard> finding the deepest inset
Jean-Marc Lasgouttes wrote:
> Richard> Here's another idea. Basically, what I've done is added an
> Richard> optional "setFont" argument to editXY, so we can call it with
> Richard> setFont = false during mere mouse movements and still take
> Richard> advantage of its recursion without messing up t
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> editXY sets font. When mouse moves, it calls editXY to identify
Bo> inner most nested inset so the current font changes unnecessary.
Bo> The proper solution may be moving setCurrentFont out of editXY and
Bo> setCurrentFont when needed, and an e
On Tue, Mar 27, 2007 at 04:33:38PM -0500, Bo Peng wrote:
> >I did not closely follow this bug hinting frenzy, but are you sure
> >that what is missing is not just a LyXText::setCurrentFont(LCursor &
> >cur) at the right place? I do not see why there would be a need to
> >change fonts on a cursor mo
I did not closely follow this bug hinting frenzy, but are you sure
that what is missing is not just a LyXText::setCurrentFont(LCursor &
cur) at the right place? I do not see why there would be a need to
change fonts on a cursor move.
editXY sets font. When mouse moves, it calls editXY to identif
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> Here's another idea. Basically, what I've done is added an
Richard> optional "setFont" argument to editXY, so we can call it with
Richard> setFont = false during mere mouse movements and still take
Richard> advantage of its recur
How about this hugely ugly patch? It basically restore changed font
after cursor move.
Have not really tested.
Bo
Index: src/BufferView.C
===
--- src/BufferView.C(revision 17599)
+++ src/BufferView.C(working copy)
@@ -1100,
On Tue, Mar 27, 2007 at 02:27:21PM -0400, Richard Heck wrote:
>
> Here's another idea. Basically, what I've done is added an optional
> "setFont" argument to editXY, so we can call it with setFont = false
> during mere mouse movements and still take advantage of its recursion
> without messing up
Bernhard Roider wrote:
Richard Heck wrote:
Here's another idea. Basically, what I've done is added an optional
"setFont" argument to editXY
I thought about that yesterday and i assume it to be the fastest
solution for now - but i agree that it is not very nice:
Anyway, it can be made pretty
Richard Heck wrote:
Here's another idea. Basically, what I've done is added an optional
"setFont" argument to editXY
I thought about that yesterday and i assume it to be the fastest solution for now - but i agree that
it is not very nice:
Anyway, it can be made pretty later.
other ways i
Here's another idea. Basically, what I've done is added an optional
"setFont" argument to editXY, so we can call it with setFont = false
during mere mouse movements and still take advantage of its recursion
without messing up the font. setFont then has to be carried through the
whole editXY hierar
I've figured out what's causing bug 3144 and posted a comment to
bugzilla about it. Someone who knows the code well should now be able to
solve the problem. I don't understand it well enough myself.
Richard
24 matches
Mail list logo
