Andre Poenitz wrote:
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way
to enforce this so we don't have to check manually (even some assert at
run time would be nice).
On Tue, Aug 28, 2007 at 12:05:25AM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> >This seems good indeed. In the long run, however, we should think of a way
> >to enforce this so we don't have to check manually (even some assert at
> >run time would be nice). Moreover, I don't see
Alfredo Braunstein wrote:
This seems good indeed. In the long run, however, we should think of a way to
enforce this so we don't have to check manually (even some assert at run time
would be nice). Moreover, I don't see what do we gain by using a lyxfunc
internally, probably we should just put
On Mon, Aug 27, 2007 at 07:36:43PM +, Alfredo Braunstein wrote:
> > // store some values to be used inside of the handlers
> > getPos(beforeDispX_, beforeDispY_);
> >
> > For trunk, I think we should replace all occurence of
> > cur.dispatch() with this->dispatch() in Text3::dispatch()
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Alfredo Braunstein wrote:
> > I did a bit of research, and I think I found something, and it seems
> > a mess. Please correct me if I'm wrong, this is what I understand:
> >
> > Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
> > Cursor::dispatc
Abdelrazak Younes wrote:
Martin Vermeer wrote:
I expect you will have to do the rowpainter cleanup
at the same time.
I'd like to do it in three steps: first remove the hack, then put in
place a better design, then optimize if need be.
When I say better design, I mean that the rowpainter use
On Aug 27, 2007, at 9:13 AM, Abdelrazak Younes wrote:
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the
getPos() call
above at the beginning of the LFUN mach
Bennett Helm wrote:
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos()
call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, bu
On Aug 27, 2007, at 5:27 AM, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos
() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that we
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
For BRANCH_1_5 I think the simpler solution is to move the getPos() call
above at the beginning of the LFUN machinery: LyXFunc::dispatch().
I'll try that solution, but I'd prefer that we use my solution for
trunk. Opinion Jurgen?
^^^
rep
Abdelrazak Younes wrote:
> > For BRANCH_1_5 I think the simpler solution is to move the getPos() call
> > above at the beginning of the LFUN machinery: LyXFunc::dispatch().
>
> I'll try that solution, but I'd prefer that we use my solution for
> trunk. Opinion Jurgen?
For branch, your solution is
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see beforeDisp
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Text::dispatch(LFUN_FLOAT_INSERT) calls dispatches
Cursor::dispatch(LFUN_CAPTION_INSERT) to insert the CAPTION. One
possible general problem with this may be that Cursor::dispatch is not
reentrant-safe (see beforeDispatch members).
I've look
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
Martin Vermeer wrote:
> > I surely won't miss it.
>
> Famous last words ;-)
Indeed ;-)
Jürgen
On Sun, Aug 26, 2007 at 12:32:21PM +0200, Jürgen Spitzmüller wrote:
> Abdelrazak Younes wrote:
> > Any objection that I remove the wide hack now?
>
> I surely won't miss it.
Famous last words ;-)
- Martin
Abdelrazak Younes wrote:
> Any objection that I remove the wide hack now?
I surely won't miss it.
Jürgen
Martin Vermeer wrote:
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
This wide stuff is really bad...
Yes, I think we should get rid of it now in trunk. The pixmap cache is good
enough that Mac plaftform don't need this hack anymore. Moreover I
On Sun, Aug 26, 2007 at 12:08:42PM +0200, Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
> > Abdelrazak Younes wrote:
> >>> Nope... unfortunately. I am sure this is a metrics problem actually.
> >> Hum... "I am _not_ sure..."
> > Actually that's what I've read for some reason ;-) I would nev
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless
like to commit the patch, as valgrind tells
Abdelrazak Younes wrote:
>> Actually that's what I've read for some reason ;-) I would nevertheless
>> like to commit the patch, as valgrind tells that otherwise the
>> wide_inset_ value is used before initialized.
>
> Sure, go ahead.
I'll do on tuesday for branch if Juergen agrees. The rational
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Nope... unfortunately. I am sure this is a metrics problem actually.
Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the wide_ins
Alfredo Braunstein wrote:
> Abdelrazak Younes wrote:
>
>
>>> Nope... unfortunately. I am sure this is a metrics problem actually.
>>
>> Hum... "I am _not_ sure..."
>
> Actually that's what I've read for some reason ;-) I would nevertheless
> like to commit the patch, as valgrind tells that oth
Abdelrazak Younes wrote:
>> Nope... unfortunately. I am sure this is a metrics problem actually.
>
> Hum... "I am _not_ sure..."
Actually that's what I've read for some reason ;-) I would nevertheless like
to commit the patch, as valgrind tells that otherwise the wide_inset_ value
is used befor
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for
Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
Alfredo Braunstein wrote:
Alfredo Braunstein wrote:
Ouch! Confirmed on WinXP too! Please fill-it in.
What's the exact recipe? I cannot reproduce here (linux)
Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
read. :-
Abdelrazak Younes wrote:
> Alfredo Braunstein wrote:
>> Alfredo Braunstein wrote:
>>
>>
> Ouch! Confirmed on WinXP too! Please fill-it in.
>>> What's the exact recipe? I cannot reproduce here (linux)
>>
>> Humm, I mean I cannot reproduce with trunk. Sorry for not being able to
>> read. :-/
27 matches
Mail list logo
