Andre Poenitz wrote:
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that
On Mon, Oct 30, 2006 at 11:12:41AM +0100, Abdelrazak Younes wrote:
> Andre Poenitz wrote:
> >
> >Good in theory but it looks as if this is the kind of infomration that
> >would be useful for a 'non-drawing real painter' (as opposed to the
> >original nullpainter)
>
> I have implemented that and go
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Andre Poenitz wrote:
>> Good in theory but it looks as if this is the kind of infomration
>> that would be useful for a 'non-drawing real painter' (as opposed
>> to the original nullpainter)
Abdelrazak> I have implem
ullPainter altogether:
Shit... Some of my LyXText changes got in there. I will clean that up
immediately, should compilable again soon.
Here is the real rawpainter.C diff:
Index: D:/devel/lyx/trunk/src/rowpainter.C
===
--- D:/devel/lyx
Abdelrazak Younes wrote:
Andre Poenitz wrote:
Good in theory but it looks as if this is the kind of infomration that
would be useful for a 'non-drawing real painter' (as opposed to the
original nullpainter)
I have implemented that and got rid of the NullPainter altogether:
Shit... Some of m
py
lyx-devel/trunk/src/frontends/Makefile.am
lyx-devel/trunk/src/frontends/Painter.h
lyx-devel/trunk/src/frontends/qt4/QLPainter.C
lyx-devel/trunk/src/insets/insettabular.C
lyx-devel/trunk/src/mathed/InsetMathNest.C
lyx-devel/trunk/src/rowpainter.C
Modified: lyx-devel/trunk/d
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -,
[EMAIL PROTECTED] wrote:
-bool const inside = (y + rit->descent() >= 0
- && y - rit->ascent() < ww);
RowPainter rp(pi, text, pit, *rit, x, y);
//
Andre Poenitz wrote:
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
- bool const inside = (y + rit->descent() >= 0
- && y - rit->ascent() < ww);
RowPainter rp(pi, text, pit, *rit, x, y);
On Sun, Oct 29, 2006 at 04:39:51PM -, [EMAIL PROTECTED] wrote:
> Author: schmitt
> Date: Sun Oct 29 17:39:51 2006
> New Revision: 15605
>
> URL: http://www.lyx.org/trac/changeset/15605
> Log:
> * rowpainter.C: remove unused variable 'inside',
> a
Jean-Marc Lasgouttes wrote:
"Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
I guess this is not something I can consider for 1.4.
Andre> If we don't get mispositioning/coordcache crashes in 1.4, then
Andre> not.
I do have crashes with pageup in 1.4.
Then the nullpainter fix is your me
> "Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
>> I guess this is not something I can consider for 1.4.
Andre> If we don't get mispositioning/coordcache crashes in 1.4, then
Andre> not.
I do have crashes with pageup in 1.4.
JMarc
Quoting Abdelrazak Younes <[EMAIL PROTECTED]>:
This was exactly what I was investigation some months ago. But then
why not going to QPicture directly? This will need some changes to
the core but I really think that's the way to go.
I would be very surprised if recording the painter operations
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Asger Ottar Alstrup wrote:
| > Jean-Marc Lasgouttes wrote:
| >> I see. Isn't there some performance price?
| > Yes, but it is not noticeable in our testing. After all, we only
| > paint two extra paragraphs.
| >
| >> I gu
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Asger Ottar Alstrup wrote:
| > Jean-Marc Lasgouttes wrote:
| >> I see. Isn't there some performance price?
| > Yes, but it is not noticeable in our testing. After all, we only
| > paint two extra paragraphs.
| >
| >> I guess this is not something I c
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>:
"Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
Andre> With the real one.
Could you point me to one or two commits that implement this?
15455 maybe.
Andre> The problem was that the nullpainter did not compute positions
Andre> correctly
Asger Ottar Alstrup wrote:
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is ful
Jean-Marc Lasgouttes wrote:
I see. Isn't there some performance price?
Yes, but it is not noticeable in our testing. After all, we only paint
two extra paragraphs.
I guess this is not something I can consider for 1.4.
Sure it is. Without, the coord cache is full of crap, and that causes
> "Andre" == Andre Pönitz <[EMAIL PROTECTED]> writes:
Andre> With the real one.
Could you point me to one or two commits that implement this?
Andre> The problem was that the nullpainter did not compute positions
Andre> correctly. If it did so, it would need to use almost the same
Andre> log
Quoting Jean-Marc Lasgouttes <[EMAIL PROTECTED]>:
"Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
Asger> Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const bool inside'
Asger, is it safe to remove t
Jean-Marc Lasgouttes wrote:
Asger> The nullpainter is no good, because it can not calculate the
Asger> metrics of text, so it's basically useless. It was the cause of
Asger> wrong metrics in the coordcache, which caused all sorts of
Asger> problems.
what did you replace it with?
We use the rea
>>>>> "Asger" == Asger Ottar Alstrup <[EMAIL PROTECTED]> writes:
Asger> Michael Gerz wrote:
>>>> /home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
>>>> variable `const bool inside'
>> Asger, is it safe to remov
Michael Gerz wrote:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused
variable `const
bool inside'
>
Asger, is it safe to remove the variable?
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calcu
Asger Ottar Alstrup wrote:
Yes, and you can nuke the nullpainter as well while you are at it.
The nullpainter is no good, because it can not calculate the metrics
of text, so it's basically useless. It was the cause of wrong metrics
in the coordcache, which caused all sorts of problems.
Ple
Martin Vermeer wrote:
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably left b
On Sun, Oct 22, 2006 at 04:40:13PM +0200, Michael Gerz wrote:
> This one look suspicious:
>
> /home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
> `const
> bool inside'
>
> Michael
Yes, Asger threw the nullpainter out (r15455).
(Probably left
This one look suspicious:
/home/software/lyx-trunk/src/rowpainter.C:865: warning: unused variable
`const
bool inside'
Michael
On Thu, Jul 13, 2006 at 11:14:06AM +0200, Lars Gullik Bjønnes wrote:
> | Maybe you should do so.
>
> If 10G is all you can spare on lyx
Not on LyX. That's to be shared with a full SuSE 10.0 installation.
> when the cheapest disks out there is 200G then I am not so sure.
I have not closely follo
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| >
| > | On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| > | > | Nope there is a big difference. You are basically
On Tue, Jul 11, 2006 at 07:28:24PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
> | > | Nope there is a big difference. You are basically asking me to have 3
> | > | trees.
> | >
> | > Actu
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
| > | Nope there is a big difference. You are basically asking me to have 3
| > | trees.
| >
| > Actually I am asking you to have as many trees as necessary.
| > (branches really...)
|
On Sun, Jul 09, 2006 at 04:05:36PM +0200, Lars Gullik Bjønnes wrote:
> | Nope there is a big difference. You are basically asking me to have 3
> | trees.
>
> Actually I am asking you to have as many trees as necessary.
> (branches really...)
Have you ever considered that there are people running
Andre Poenitz wrote:
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
| | I cannot at the same time do
| | very small patches so that everyone can understand and wait tomorrow
| | for committing to trunk and then merging trunk with my branch.
|
| Sure you can.
And to expan
On Sun, Jul 09, 2006 at 01:47:07AM +0200, Lars Gullik Bjønnes wrote:
> | | I cannot at the same time do
> | | very small patches so that everyone can understand and wait tomorrow
> | | for committing to trunk and then merging trunk with my branch.
> |
> | Sure you can.
>
> And to expand a bit:
>
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | From what I've read, the merging algorithms of git are much more
| > | powerful than those of svn. But that is not really my point. Working
| > | with SVN means eithe
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously n
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | From what I've read, the merging algorithms of git are much more
| | powerful than those of svn. But that is not really my point. Working
| | with SVN means either that one guy controls everythi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| From what I've read, the merging algorithms of git are much more
| powerful than those of svn. But that is not really my point. Working
| with SVN means either that one guy controls everything (you)
Which is obviously not true. (Other than from an
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > then point us either at the patch or the revision number.
| > | > Then patches can (as long as they are not dependent on eacy other) be
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > then point us either at the patch or the revision number.
| > | > Then patches can (as long as they are not dependent on eacy other) be
| > | > cherry picked and mer
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > then point us either at the patch or the revision number.
| > Then patches can (as long as they are not dependent on eacy other) be
| > cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's t
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > then point us either at the patch or the revision number.
| > Then patches can (as long as they are not dependent on eacy other) be
| > cherry picked and merged easily to trunk.
|
| Talk about an easy procedure. It's too complicated for me, so no
Lars Gullik Bjønnes wrote:
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Georg Baum wrote:
| | > Abdelrazak Younes wrote:
| | >
| | >> I will commit to my branch to let Lars the time to review this patch. I
| | >> hope he will not be upse
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do no
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Abdelrazak Younes <[EMAIL PROTECTED]> writes:
|
| | Georg Baum wrote:
| | > Abdelrazak Younes wrote:
| | >
| | >> I will commit to my branch to let Lars the time to review this patch. I
| | >> hope he will not be upset to have multiple fix in the
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| If so, I should commit to trunk immediately and if someone is not OK
| for some reason the commit should be reverted. That is how you show
| trust to developers in my opinion. And please note that Lars quite
| often do not wait at all before committi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Georg Baum wrote:
| > Abdelrazak Younes wrote:
| >
| >> I will commit to my branch to let Lars the time to review this patch. I
| >> hope he will not be upset to have multiple fix in the same branch.
| > I fear he will, because this has nothing to do
Abdelrazak Younes wrote:
> They are related to the API changing I am doing so I cannot reproduce
> them either for trunk or for 1.4.2. FWIW, I am not even sure that they
> are still needed for my branch. But I think they should be applied anyway.
OK. Just in case you have the feeling a crash is un
Juergen Spitzmueller wrote:
Abdelrazak Younes wrote:
Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always whe
Abdelrazak Younes wrote:
> Sure but I don't have a 1.4 tree here. I have enough of two.
In case of crashes, you could tell us how to reproduce them, so we can check
if they also occur in the stable branch.
I do get crashes in 1.4.2svn occassionally (almost always when I don't have
time to track
Abdelrazak Younes wrote:
> It has because it is only triggered with my BufferView changes. But
> really, I think it is a perfect illustration of the failure of the
> current commit procedure. With a distributed SCM (git, mercurial, etc)
> my current practice would be encouraged. I cannot at the sa
Jose' Matos wrote:
On Friday 07 July 2006 17:13, Georg Baum wrote:
I fear he will, because this has nothing to do with the other stuff in your
branch.
+1
If I were you I would announce that this patch will go in trunk tomorrow
unless there are objections. This is a perfect example for this p
Georg Baum wrote:
Abdelrazak Younes wrote:
I will commit to my branch to let Lars the time to review this patch. I
hope he will not be upset to have multiple fix in the same branch.
I fear he will, because this has nothing to do with the other stuff in your
branch.
It has because it is only
On Friday 07 July 2006 17:13, Georg Baum wrote:
> I fear he will, because this has nothing to do with the other stuff in your
> branch.
+1
> If I were you I would announce that this patch will go in trunk tomorrow
> unless there are objections. This is a perfect example for this procedure:
> It i
Abdelrazak Younes wrote:
> I will commit to my branch to let Lars the time to review this patch. I
> hope he will not be upset to have multiple fix in the same branch.
I fear he will, because this has nothing to do with the other stuff in your
branch.
If I were you I would announce that this patc
Abdelrazak Younes wrote:
Hello,
I came across this bug while playing with the painting. As the emptyness
check is obviously correct I guess I will have no objection but I am
asking anyway because I am good boy.
Any objection?
I will commit to my branch to let Lars the time to review this p
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I came across this bug while playing with the painting. As the emptyness
check is obviously correct I guess I will have no objection but I am
asking anyway because I am good boy.
Why do you move
theCoords.parPos()[&tex
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> I came across this bug while playing with the painting. As the emptyness
> check is obviously correct I guess I will have no objection but I am
> asking anyway because I am good boy.
Why do you move
theCoords.parPos()[&text][pit] = Point(x,
Hello,
I came across this bug while playing with the painting. As the emptyness
check is obviously correct I guess I will have no objection but I am
asking anyway because I am good boy.
Any objection?
Abdel.
Index: rowpainter.C
>>>>> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Thu, Apr 06, 2006 at 05:34:55PM +0200, Michael Gerz wrote:
>> Martin ???
>>
>> diff -w -r --exclude=.svn --exclude=boost --exclude=po
>> --exclude=ChangeLo
On Thu, Apr 06, 2006 at 05:34:55PM +0200, Michael Gerz wrote:
> Martin ???
>
> diff -w -r --exclude=.svn --exclude=boost --exclude=po
> --exclude=ChangeLog lyx-devel-1.4.X/src/rowpainter.C lyx-d
> evel-1.5.0/src/rowpainter.C
> 756c756
> < &
Martin ???
diff -w -r --exclude=.svn --exclude=boost --exclude=po
--exclude=ChangeLog lyx-devel-1.4.X/src/rowpainter.C lyx-d
evel-1.5.0/src/rowpainter.C
756c756
< && sl.pos() < rit->endpos())
---
> && sl.pos() <= rit->endpos())
Michael
et; cur.forwardPosNoDescend()) {
+ Change change = cur.paragraph().lookupChangeFull(cur.pos());
if (change != orig_change) {
- // slight UI optimisation: for replacements, we get
- // text like : _old_new. Consider that as one change.
- if (!(orig_c
// text like : _old_new. Consider that as one change.
- if (!(orig_change.type == Change::DELETED &&
- change.type == Change::INSERTED))
- break;
+ break;
Martin Vermeer wrote:
> Yes, and I committed a patch to trunk
Perfect! From my POV, multi par change tracking seems to be finished and
working now, no more complaints :-)
Do you have a cumulative patch for 1.4 that combines all the changes and
subsequent fixes you (and others) have done? I'd li
On Sat, Mar 18, 2006 at 06:41:50PM +0100, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
...
> There's yet another similar problem BTW, for which I didn't find a solution.
> When you merge two (UNCHAGED) paragraphs in ct mode, the blue change bar is
> not immediately painted as well
Juergen Spitzmueller wrote:
> > If I did, it was accidental. Could well be. How does it show?
>
> While using the DEL key in ct mode, the deletion of the last character in a
> paragraph is not painted (only after another action).
There's yet another similar problem BTW, for which I didn't find a s
Also sprach Martin Vermeer:
> If I did, it was accidental. Could well be. How does it show?
While using the DEL key in ct mode, the deletion of the last character in a
paragraph is not painted (only after another action).
Jürgen
On Sat, Mar 18, 2006 at 06:03:41PM +0100, Juergen Spitzmueller wrote:
> Martin, you have (accidentally?) reverted my rowpainter fix belonging to the
> fix of bug 2185 in trunk (with your "speed up inside insets" patch).
> I gonna commit the attached fix again.
If I did, it was accidental. Could w
Martin, you have (accidentally?) reverted my rowpainter fix belonging to the
fix of bug 2185 in trunk (with your "speed up inside insets" patch).
I gonna commit the attached fix again.
Jürgen
Index: src/rowpainter.C
=
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Isn't this useful for BRANCH_1_4_X as well? Michael
Only when the fix to bug 880 is in.
JMarc
Isn't this useful for BRANCH_1_4_X as well?
Michael
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 13, 2006 12:05 PM
Subject: r13356 - in /lyx-devel/trunk/src: ChangeLog rowpainter.C
Author: vermeer
Date: Mon Mar 13
71 matches
Mail list logo
