On 08/09/2009 07:23 PM, Andre Poenitz wrote:
On Sun, Aug 09, 2009 at 11:45:29PM +0200, Vincent van Ravesteijn wrote:
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
for all operation that involves a Paragraph or an Inset copy.
2) set the buff
On Sun, Aug 09, 2009 at 11:45:29PM +0200, Vincent van Ravesteijn wrote:
>
>>>
>>> So we have two solutions:
>>> 1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
>>> for all operation that involves a Paragraph or an Inset copy.
>>> 2) set the buffer for all paragraphs and inse
On Sun, Aug 09, 2009 at 11:47:27PM +0200, Abdelrazak Younes wrote:
> On 09/08/2009 23:45, Vincent van Ravesteijn wrote:
>>
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do
this for all operation that involves a Paragraph or an Inset c
On 09/08/2009 23:26, Abdelrazak Younes wrote:
On 09/08/2009 23:15, Edwin Leuven wrote:
abdel wrote:
But how should we mark those changes? A deletion and an insertion seem heavy to
me
it's better than nothing. if a co-author moves a paragraph i like to see it...
I agree but I would
On 09/08/2009 23:45, Vincent van Ravesteijn wrote:
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do
this for all operation that involves a Paragraph or an Inset copy.
2) set the buffer for all paragraphs and insets in updateLabel() as
this is guara
So we have two solutions:
1) set the Buffer again for pars_[pit] and pars_[pit - 1] and do this
for all operation that involves a Paragraph or an Inset copy.
2) set the buffer for all paragraphs and insets in updateLabel() as this
is guaranted to be be called each time each time a new Parag
On Sun, Aug 09, 2009 at 08:59:47PM +0200, Abdelrazak Younes wrote:
> On 09/08/2009 20:50, Vincent van Ravesteijn wrote:
>> Abdelrazak Younes schreef:
>>> On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
> Hi,
>
> There used to be a recursive call to set
On 09/08/2009 23:15, Edwin Leuven wrote:
abdel wrote:
But how should we mark those changes? A deletion and an insertion seem heavy to
me
it's better than nothing. if a co-author moves a paragraph i like to see it...
I agree but I would prefer a button text..."> which will move the
abdel wrote:
> But how should we mark those changes? A deletion and an insertion seem heavy
> to me
it's better than nothing. if a co-author moves a paragraph i like to see it...
On 09/08/2009 22:59, Vincent van Ravesteijn wrote:
Pavel Sanda schreef:
Abdelrazak Younes wrote:
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers
(Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about
Vincent van Ravesteijn wrote:
>> note we have LFUN_OUTLINE_DRAGMOVE now, which i suspect to be prone to
>> bugs
>> now, but would be good base for big enhacement - drag & drop inside
>> outliner.
>>
>> pavel
>>
> Yes, I was just wondering wether this function will get some use.
i put it in to
On 09/08/2009 23:00, rgheck wrote:
On 08/09/2009 03:11 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs witho
On 08/09/2009 03:53 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs without ensuring that a decent buffer is
On 08/09/2009 03:11 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around
paragraphs without ensuring that a decent buffer is
Pavel Sanda schreef:
Abdelrazak Younes wrote:
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers (Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the
list, but in retro
Abdelrazak Younes wrote:
> On 09/08/2009 22:36, Edwin Leuven wrote:
>>> The two features were developped by two different developpers (Edwin for
>>> LFUN_PARAGRAPH_MOVE*
>>>
>>
>> developed is a big word. i think we had some discussion about it on the
>> list, but in retrospect i think i sho
On 09/08/2009 22:36, Edwin Leuven wrote:
The two features were developped by two different developpers (Edwin for
LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the list,
but in retrospect i think i should've used cut and paste. in particular bec
> The two features were developped by two different developpers (Edwin for
> LFUN_PARAGRAPH_MOVE*
developed is a big word. i think we had some discussion about it on the list,
but in retrospect i think i should've used cut and paste. in particular because
now moving paragraphs is ignored by cha
On 09/08/2009 21:57, Vincent van Ravesteijn wrote:
I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
just have to wait for the next one :-)
Abdel.
Can you then also explain me why this is not using the same code as
Text3.cpp:outline(OutlineUp).
The two features were d
On 09/08/2009 22:00, Kornel Benko wrote:
Sorry Abdel, but
No, I am sorry. Will fix it now.
Abdel.
Am Sonntag 09 August 2009 schrieb Vincent van Ravesteijn:
> > I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
> > just have to wait for the next one :-)
> >
> > Abdel.
Sorry Abdel, but
...
In file included from /usr/src/lyx/lyx-devel/src/ParagraphList.h:17,
f
I just fixed LFUN_PARAGRAPH_MOVE_DOWN LFUN_PARAGRAPH_MOVE_UP. Now we
just have to wait for the next one :-)
Abdel.
Can you then also explain me why this is not using the same code as
Text3.cpp:outline(OutlineUp).
Vincent
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only
On 09/08/2009 21:33, Vincent van Ravesteijn wrote:
Nothing. But updateLabels() do a whole lot more than just updating
the labels.
, which indicates that we have been misusing the updateLabels for a
long time.
So, I would rather start cleaning up this mess rather than hiding this
by renaming
Nothing. But updateLabels() do a whole lot more than just updating the
labels.
, which indicates that we have been misusing the updateLabels for a long
time.
So, I would rather start cleaning up this mess rather than hiding this
by renaming the function.
Vincent
On 09/08/2009 21:18, Vincent van Ravesteijn wrote:
And the reason why you decided this?
To repeat myself over and over again. What has setBuffer to do with
labels that need to be updated ?
Nothing. But updateLabels() do a whole lot more than just updating the
labels. So to answer your ques
And the reason why you decided this?
To repeat myself over and over again. What has setBuffer to do with
labels that need to be updated ?
Vincent
Richard Heck wrote:
>> I see. Then someone needs the fix all cases where something is copied.
>>
> That was the intention. I guess we missed a few
i think its the time for John to run his keylogger script
on the new trunk again :)
pavel
On 09/08/2009 21:09, rgheck wrote:
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only
On 09/08/2009 21:07, Vincent van Ravesteijn wrote:
There was a large FIXME next to this call that this should be done in
the pasteSelectionHelper,
//FIXME: We should call setBuffer() on each inserted paragraph.
// instead, we call setBuffer() for the main inset at the beginning
// of update
On 08/09/2009 03:08 PM, Abdelrazak Younes wrote:
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only at one place. That place would be so
On 08/09/2009 03:00 PM, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been
remov
On 09/08/2009 21:00, Vincent van Ravesteijn wrote:
Basically we think it's a bit lazy to start moving around paragraphs
without ensuring that a decent buffer is set. Moreover, I think that
we should do it only at one place. That place would be somewhere in
CutAndPaste. There is no other reason
There was a large FIXME next to this call that this should be done in
the pasteSelectionHelper,
//FIXME: We should call setBuffer() on each inserted paragraph.
// instead, we call setBuffer() for the main inset at the beginning
// of updateLabels()
IIRC this was your FIXME ;-)
We cam
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of t
On 09/08/2009 20:50, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been
removed?
Abdelrazak Younes schreef:
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of t
On 09/08/2009 20:48, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of the buffer absence.
Try LFUN
Abdelrazak Younes schreef:
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed?
Now we get crashes with a lot of LFUNs because of the buffer absence.
Try LFUN_PARAGRAPH_MOVE_UP for example...
Abdel.
The rea
Hi,
There used to be a recursive call to setBuffer() at the top of
Buffer::updateLabels(); is there a reason why this has been removed? Now
we get crashes with a lot of LFUNs because of the buffer absence. Try
LFUN_PARAGRAPH_MOVE_UP for example...
Abdel.
40 matches
Mail list logo
