This time from my gentoo server PC. This server doesn't have X or
anything installed so I can't run the build on it. But I thought I'd
try another distro. I've seen the qt2 warnings before, but those DLOPEN
ones are new.
Cheers
Koz
Using Autoconf version 2.13
Locating GNU m4...
On Sun, 16 Mar 2003, Michael A. Koziarski wrote:
John Levon wrote:
Guess it needs installing.
Sure, I've put it back. Now we need someone to make some nice images
for the numbers one through eight. If there are any changes required,
we may need to upgrade to gnomes current helper.
On Sun, Mar 16, 2003 at 05:33:03PM +1030, Darren Freeman wrote:
Bug severity is a very subjective thing.
It pisses me off daily, therefore to me it *is* major ;)
No.
http://bugzilla.lyx.org/bug_status.html#severity
Major major loss of function
Minor minor loss of function, or other
Is there some terribly good reason this isn't just LYX_USERDIR ?
john
The isNewline() call on line 2611 of LyXText::backspace on text.C is
responsible of a getChar() on a bogus pos when backspacing the last char on
a paragraph (we have already called erase on this pos).
This code (the while going from 2610 to 2621) is supposed to get sure to not
have a linebreak at
Dekel == Dekel Tsur [EMAIL PROTECTED] writes:
Dekel On Fri, Mar 14, 2003 at 02:55:25AM +, John Levon wrote:
why do we have both again ?
Dekel Currently insetnote is not versatile enough:
Dekel - The text does not appear in the .tex file, so if you give
Dekel someone the .tex file, he
John == John Levon [EMAIL PROTECTED] writes:
John Is there some terribly good reason this isn't just LYX_USERDIR ?
Not tzerribly good, but we should add LYX_USERDIR_14x for current cvs.
I think it is useful when one has several versions installed at the
same time. Of course, we already have
On Sun, Mar 16, 2003 at 01:55:55PM +0100, Jean-Marc Lasgouttes wrote:
John Is there some terribly good reason this isn't just LYX_USERDIR ?
Not tzerribly good, but we should add LYX_USERDIR_14x for current cvs.
I think it is useful when one has several versions installed at the
same time.
On Sun, Mar 16, 2003 at 01:37:23PM +0100, Alfredo Braunstein wrote:
The isNewline() call on line 2611 of LyXText::backspace on text.C is
responsible of a getChar() on a bogus pos when backspacing the last char on
a paragraph (we have already called erase on this pos).
OK we need to fix that
John Levon wrote:
Hi John,
You're mis-reading the code. What it's actually doing is removing any
I normally do ;)
newlines *at the start of the main body*. Now, in a normal paragraph,
that's not really needed (beginningOfBody() == 0 then).
^
But it oviously does
On Sun, Mar 16, 2003 at 02:22:06PM +0100, Alfredo Braunstein wrote:
But it oviously does even in normal paragraphs (there's no check that
beginningofBogy != 0). Why? Does then the constrain below applies also to
normal paragraphs?
Well, I dunno if there's cases latex will fail to compile it,
Current behaviour is higly counterintuitive.
Why is it ? I don't follow when there is a circumstance that starting a
par with a newline makes sense.
Maybe not at the end, but what if you want to replace the existing text
before the newline with new text? You remove it, and the newline is
On Sun, Mar 16, 2003 at 02:43:14PM +0100, Alfredo Braunstein wrote:
Maybe not at the end, but what if you want to replace the existing text
before the newline with new text? You remove it, and the newline is gone.
Hmm yes ... but what can we do ? We must not allow the user to generate
bad
John Levon wrote:
On Sat, Mar 15, 2003 at 07:22:03PM +0100, Helge Hafting wrote:
Backtrace please. There have been no changes I am aware of in the spell
code that could cause such a change.
Here's the backtrace from what happens when I press F7.
Lyx is running remotely, i.e. X via an adsl link.
On Sun, Mar 16, 2003 at 03:37:09PM +0100, Helge Hafting wrote:
(pspell, gcc-3.2, debian unstable)
#0 0x40683aeb in __dynamic_cast () from /usr/lib/libstdc++.so.5
#1 0x40ec88ac in pspell_aspell::PA_Manager::PA_Manager ()
from /usr/lib/libpspell_aspell.so.2
#2 0x40ec9df3 in
Do we really still need support for this stuff ?
john
John Levon wrote:
On Sun, Mar 16, 2003 at 03:37:09PM +0100, Helge Hafting wrote:
(pspell, gcc-3.2, debian unstable)
#0 0x40683aeb in __dynamic_cast () from /usr/lib/libstdc++.so.5
#1 0x40ec88ac in pspell_aspell::PA_Manager::PA_Manager ()
from /usr/lib/libpspell_aspell.so.2
#2 0x40ec9df3 in
On Sun, Mar 16, 2003 at 04:22:58PM +0100, Helge Hafting wrote:
think this is LyX's bug ...
So I have a broken pspell then. Probably only luck it worked before?
I guess so. It's small possibility of their being some weird
interaction, but seeing as all the versions of pspell work for me,
On Sun, Mar 16, 2003 at 11:36:52AM -0400, Garst R. Reese wrote:
aspell-0.50.3 or later.
This (of course:) breaks pspell.m4, but it is easy to fix.
Not in 1.3.x, at least it works for me
regards
john
Garst R. Reese wrote:
Helge Hafting wrote:
So I have a broken pspell then. Probably only luck it worked before?
pspell/aspell went through a number of lib reorganizations in fairly
rapid sequence. It is pretty easy to get incompatible versions of pspell
and aspell libs.
This seems to be the
On Sun, Mar 16, 2003 at 05:04:05PM +0100, Helge Hafting wrote:
This seems to be the case indeed. It is currently impossible for me
to use pspell, debian's aspell-no (Norwegian dictionary) is
incompatible with libaspell15, and pspell needs that one. Seems I'll
be using single-language ispell
John Levon wrote:
On Sun, Mar 16, 2003 at 05:04:05PM +0100, Helge Hafting wrote:
This seems to be the case indeed. It is currently impossible for me
to use pspell, debian's aspell-no (Norwegian dictionary) is
incompatible with libaspell15, and pspell needs that one. Seems I'll
be using
38 files changed, 132 insertions(+), 455 deletions(-)
This fixes bug 791 (regression in 1.3 release) and probably several
cases of bug 818. Things are not noticably slower and I have not
observed any drawing regressions (though it is but lightly tested).
Basically, we remove any attempt to
John Levon wrote:
38 files changed, 132 insertions(+), 455 deletions(-)
Shocking
This fixes bug 791 (regression in 1.3 release) and probably several
cases of bug 818. Things are not noticably slower and I have not
observed any drawing regressions (though it is but lightly tested).
On Sun, Mar 16, 2003 at 08:11:57PM +0100, Alfredo Braunstein wrote:
Dumb of me, what's a section being cleared?
When we paint a row we need to paint the background. Also insets like
Note have yellow backgrounds, and they need to be painted too.
Before the patch, we had some horrible passing
John Levon wrote:
Hmm yes ... but what can we do ? We must not allow the user to generate
bad latex.
[...]
Isn't this latex ?
I know. I don't know exactly what's the current general approach here, but
nobody would stops us from 'hiding' or 'workaround' latex restriction in
LyX, especially if
Continuing in the same vein. Trying to make this stuff somewhat
understandable. Note that this probably makes CHANGED_IN_DRAW
somewhat slower.
7 files changed, 95 insertions(+), 130 deletions(-)
Next we see if we can remove the refresh_y altogether in the
postRowPaint() case. It should not be
On Sun, Mar 16, 2003 at 08:32:39PM +0100, Alfredo Braunstein wrote:
I can imagine that we want to stop users from using linebreaks for
formatting... then why do we allow multiple consecutive linebreaks? Eating
10 linebreaks _after_ the cursor with one backspace is not what I would
call
John Levon wrote:
When we paint a row we need to paint the background. Also insets like
[...]
Thanks. Alfredo
John Levon [EMAIL PROTECTED] writes:
| 38 files changed, 132 insertions(+), 455 deletions(-)
|
| This fixes bug 791 (regression in 1.3 release) and probably several
| cases of bug 818. Things are not noticably slower and I have not
| observed any drawing regressions (though it is but lightly
John Levon [EMAIL PROTECTED] writes:
| Continuing in the same vein. Trying to make this stuff somewhat
| understandable. Note that this probably makes CHANGED_IN_DRAW
| somewhat slower.
|
| 7 files changed, 95 insertions(+), 130 deletions(-)
|
| Next we see if we can remove the refresh_y
On Sun, Mar 16, 2003 at 09:30:49PM +0100, Lars Gullik Bj?nnes wrote:
This one is not as obvious to me as the first one, but it seems to
make things clearer.
It's really a first step more than anything else. I really want to deal
with all the status() checks in insettext.C somehow (that is,
It seems *particularly* ad hoc. It's certainly not a complete solution,
since there is still other insets I can insert in the label part that
makes things go wrong (same goes for the lyx screen visually, e.g.
include file, where there *is* no meaningful -display(false)).
Can I just remove it, or
On Fri, Mar 14, 2003 at 03:22:00PM -0400, Garst R. Reese wrote:
I could read this file yesterday.
Today it hangs until I kill lyx, then it gives the traceback.
ps shows that python is running. It looks like the coversion script is
looping.
bash$ lyx
lyx2lyx: A development version file.
I have a patch ready (that seems to work) that does 99.9% of these
changes.
I am not sure that it cleans up a lot, but I guess it is a bit saner
anyway.
There shouldn't bee too many ws only chunks in this patch, but there
might be some.
Please comment.
(I had to zip this... size unzipped
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
| The following patch fixes some compilation problems when
| BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
| (first hunk: when BOOST_NO_WREGEX is defined we end up including
| wchar) and something I found when trying to compile
Kayvan A. Sylvan [EMAIL PROTECTED] writes:
| I am resending my Cygwin make patch, since it has not been applied yet.
|
| Apply the following patch and add the attached cygwin.m4 to config.
You are not forgotten.
--
Lgb
On Mon, Mar 17, 2003 at 12:54:40AM +0100, Lars Gullik Bj?nnes wrote:
Please comment.
If bv_owner is always != 0, what is the isTopLevel() test all about ?
This seems dubious to me, look at RowPainter::paintFirst() - if bv_owner
was always set, then we'd get the top margin at the top of every
OK, here's a bug, interesting to see if others can reproduce on their
cleaner trees. Open the user guide and open the footnote at the top. Now
place the cursor right after Introduction. You'll need to resize the
window / change font size so that, at this point, the button of the
footnote is at
Dear List,
The CVS versions of LyX obviously don't come with docs, they're in
another module checked out separately.
What I suggest is that the lyx-devel repository come with either a) an
extension to the makefile which adds relative symlinks as appropriate,
or b) some symlinks to the current
On Mon, Mar 17, 2003 at 01:15:21AM +0100, Lars Gullik Bjønnes wrote:
Kayvan A. Sylvan [EMAIL PROTECTED] writes:
| I am resending my Cygwin make patch, since it has not been applied yet.
|
| Apply the following patch and add the attached cygwin.m4 to config.
You are not forgotten.
Thank
Hello,
Thanks a lot.
Do this change appears in lyx-1.3.1 ?
Now I know I have problem with table in minipages. So, I will find
another solution.
Yann COLLETTE
José Matos wrote:
On Thursday 13 March 2003 13:17, Yann COLLETTE wrote:
Hello,
I've got a huge file composed with lyx-1.1.6fix4 I
Title: ΪÁ˸üºÃµØ·þÎñÓÚÖйúÆóÒµ£¬±¾¹«Ë¾£¨½ðÖÇÉÌÒµÑо¿¹«Ë¾£©ÌØÍƳöÓн±µ÷²é»î¶¯
ΪÁ˸üºÃµØ·þÎñÓÚÖйúÆóÒµ£¬±¾¹«Ë¾£¨½ðÖÇÉÌÒµÑо¿¹«Ë¾£©ÌØÍƳöÓн±µ÷²é»î¶¯¡£Ï£ÍûÄúÄÜÔÚ°Ùæ֮Öгé³ö¼¸·ÖÖÓʱ¼ä£¬Ìîд¸½¼þÖеÄÎÊ¾í£¬²¢·¢»ØÎÒ¹«Ë¾£¬²»Ê¤¸Ð¼¤£¡ £¨¸½¼þÖеÄÒ»¸öwordÎļþÒѾŵ¶Üɱ¶¾£¬Çë·ÅÐÄ´ò¿ª£©
John Levon wrote:
I'm not quite sure what behaviour has changed, though it might be the
work Alfredo did with top_y possibly ? Can you explain again what
behaviour changes you made for the graphics stuff ?
The change was pretty general (an safe): change all first_y as right value
with top_y()
This time from my gentoo server PC. This server doesn't have X or
anything installed so I can't run the build on it. But I thought I'd
try another distro. I've seen the qt2 warnings before, but those DLOPEN
ones are new.
Cheers
Koz
Using Autoconf version 2.13
Locating GNU m4...
On Sun, 16 Mar 2003, Michael A. Koziarski wrote:
> John Levon wrote:
>
> >Guess it needs installing.
> >
> Sure, I've put it back. Now we need someone to make some nice images
> for the numbers one through eight. If there are any changes required,
> we may need to upgrade to gnomes current
On Sun, Mar 16, 2003 at 05:33:03PM +1030, Darren Freeman wrote:
> Bug severity is a very subjective thing.
>
> It pisses me off daily, therefore to me it *is* major ;)
No.
http://bugzilla.lyx.org/bug_status.html#severity
"Major major loss of function"
"Minor minor loss of function, or
Is there some terribly good reason this isn't just LYX_USERDIR ?
john
The isNewline() call on line 2611 of LyXText::backspace on text.C is
responsible of a getChar() on a bogus pos when backspacing the last char on
a paragraph (we have already called erase on this pos).
This code (the while going from 2610 to 2621) is supposed to get sure to not
have a linebreak at
> "Dekel" == Dekel Tsur <[EMAIL PROTECTED]> writes:
Dekel> On Fri, Mar 14, 2003 at 02:55:25AM +, John Levon wrote:
>> why do we have both again ?
Dekel> Currently insetnote is not versatile enough:
Dekel> - The text does not appear in the .tex file, so if you give
Dekel> someone the
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> Is there some terribly good reason this isn't just LYX_USERDIR ?
Not tzerribly good, but we should add LYX_USERDIR_14x for current cvs.
I think it is useful when one has several versions installed at the
same time. Of course, we
On Sun, Mar 16, 2003 at 01:55:55PM +0100, Jean-Marc Lasgouttes wrote:
> John> Is there some terribly good reason this isn't just LYX_USERDIR ?
>
> Not tzerribly good, but we should add LYX_USERDIR_14x for current cvs.
> I think it is useful when one has several versions installed at the
> same
On Sun, Mar 16, 2003 at 01:37:23PM +0100, Alfredo Braunstein wrote:
> The isNewline() call on line 2611 of LyXText::backspace on text.C is
> responsible of a getChar() on a bogus pos when backspacing the last char on
> a paragraph (we have already called erase on this pos).
OK we need to fix
John Levon wrote:
Hi John,
> You're mis-reading the code. What it's actually doing is removing any
I normally do ;)
> newlines *at the start of the main body*. Now, in a normal paragraph,
> that's not really needed (beginningOfBody() == 0 then).
^
But it oviously does
On Sun, Mar 16, 2003 at 02:22:06PM +0100, Alfredo Braunstein wrote:
> But it oviously does even in normal paragraphs (there's no check that
> beginningofBogy != 0). Why? Does then the constrain below applies also to
> normal paragraphs?
Well, I dunno if there's cases latex will fail to compile
>> Current behaviour is higly counterintuitive.
>
> Why is it ? I don't follow when there is a circumstance that starting a
> par with a newline makes sense.
Maybe not at the end, but what if you want to replace the existing text
before the newline with new text? You remove it, and the newline
On Sun, Mar 16, 2003 at 02:43:14PM +0100, Alfredo Braunstein wrote:
> Maybe not at the end, but what if you want to replace the existing text
> before the newline with new text? You remove it, and the newline is gone.
Hmm yes ... but what can we do ? We must not allow the user to generate
bad
John Levon wrote:
On Sat, Mar 15, 2003 at 07:22:03PM +0100, Helge Hafting wrote:
Backtrace please. There have been no changes I am aware of in the spell
code that could cause such a change.
Here's the backtrace from what happens when I press F7.
Lyx is running remotely, i.e. X via an adsl link.
On Sun, Mar 16, 2003 at 03:37:09PM +0100, Helge Hafting wrote:
> (pspell, gcc-3.2, debian unstable)
>
> #0 0x40683aeb in __dynamic_cast () from /usr/lib/libstdc++.so.5
> #1 0x40ec88ac in pspell_aspell::PA_Manager::PA_Manager ()
>from /usr/lib/libpspell_aspell.so.2
> #2 0x40ec9df3 in
Do we really still need support for this stuff ?
john
John Levon wrote:
On Sun, Mar 16, 2003 at 03:37:09PM +0100, Helge Hafting wrote:
(pspell, gcc-3.2, debian unstable)
#0 0x40683aeb in __dynamic_cast () from /usr/lib/libstdc++.so.5
#1 0x40ec88ac in pspell_aspell::PA_Manager::PA_Manager ()
from /usr/lib/libpspell_aspell.so.2
#2 0x40ec9df3 in
On Sun, Mar 16, 2003 at 04:22:58PM +0100, Helge Hafting wrote:
> >think this is LyX's bug ...
>
> So I have a broken pspell then. Probably only luck it worked before?
I guess so. It's small possibility of their being some weird
interaction, but seeing as all the versions of pspell work for me,
On Sun, Mar 16, 2003 at 11:36:52AM -0400, Garst R. Reese wrote:
> aspell-0.50.3 or later.
> This (of course:) breaks pspell.m4, but it is easy to fix.
Not in 1.3.x, at least it works for me
regards
john
Garst R. Reese wrote:
Helge Hafting wrote:
So I have a broken pspell then. Probably only luck it worked before?
pspell/aspell went through a number of lib reorganizations in fairly
rapid sequence. It is pretty easy to get incompatible versions of pspell
and aspell libs.
This seems to be the
On Sun, Mar 16, 2003 at 05:04:05PM +0100, Helge Hafting wrote:
> This seems to be the case indeed. It is currently impossible for me
> to use pspell, debian's aspell-no (Norwegian dictionary) is
> incompatible with libaspell15, and pspell needs that one. Seems I'll
> be using single-language
John Levon wrote:
On Sun, Mar 16, 2003 at 05:04:05PM +0100, Helge Hafting wrote:
This seems to be the case indeed. It is currently impossible for me
to use pspell, debian's aspell-no (Norwegian dictionary) is
incompatible with libaspell15, and pspell needs that one. Seems I'll
be using
38 files changed, 132 insertions(+), 455 deletions(-)
This fixes bug 791 (regression in 1.3 release) and probably several
cases of bug 818. Things are not noticably slower and I have not
observed any drawing regressions (though it is but lightly tested).
Basically, we remove any attempt to
John Levon wrote:
>
> 38 files changed, 132 insertions(+), 455 deletions(-)
Shocking
> This fixes bug 791 (regression in 1.3 release) and probably several
> cases of bug 818. Things are not noticably slower and I have not
> observed any drawing regressions (though it is but lightly tested).
On Sun, Mar 16, 2003 at 08:11:57PM +0100, Alfredo Braunstein wrote:
> Dumb of me, what's a section being cleared?
When we paint a row we need to paint the background. Also insets like
Note have yellow backgrounds, and they need to be painted too.
Before the patch, we had some horrible passing
John Levon wrote:
> Hmm yes ... but what can we do ? We must not allow the user to generate
> bad latex.
[...]
> Isn't this latex ?
I know. I don't know exactly what's the current general approach here, but
nobody would stops us from 'hiding' or 'workaround' latex restriction in
LyX, especially
Continuing in the same vein. Trying to make this stuff somewhat
understandable. Note that this probably makes CHANGED_IN_DRAW
somewhat slower.
7 files changed, 95 insertions(+), 130 deletions(-)
Next we see if we can remove the "refresh_y" altogether in the
postRowPaint() case. It should not
On Sun, Mar 16, 2003 at 08:32:39PM +0100, Alfredo Braunstein wrote:
> I can imagine that we want to stop users from using linebreaks for
> formatting... then why do we allow multiple consecutive linebreaks? Eating
> 10 linebreaks _after_ the cursor with one backspace is not what I would
> call
John Levon wrote:
> When we paint a row we need to paint the background. Also insets like
[...]
Thanks. Alfredo
John Levon <[EMAIL PROTECTED]> writes:
| 38 files changed, 132 insertions(+), 455 deletions(-)
|
| This fixes bug 791 (regression in 1.3 release) and probably several
| cases of bug 818. Things are not noticably slower and I have not
| observed any drawing regressions (though it is but lightly
John Levon <[EMAIL PROTECTED]> writes:
| Continuing in the same vein. Trying to make this stuff somewhat
| understandable. Note that this probably makes CHANGED_IN_DRAW
| somewhat slower.
|
| 7 files changed, 95 insertions(+), 130 deletions(-)
|
| Next we see if we can remove the "refresh_y"
On Sun, Mar 16, 2003 at 09:30:49PM +0100, Lars Gullik Bj?nnes wrote:
> This one is not as obvious to me as the first one, but it seems to
> make things clearer.
It's really a first step more than anything else. I really want to deal
with all the status() checks in insettext.C somehow (that is,
It seems *particularly* ad hoc. It's certainly not a complete solution,
since there is still other insets I can insert in the label part that
makes things go wrong (same goes for the lyx screen visually, e.g.
include file, where there *is* no meaningful ->display(false)).
Can I just remove it,
On Fri, Mar 14, 2003 at 03:22:00PM -0400, Garst R. Reese wrote:
> I could read this file yesterday.
> Today it hangs until I kill lyx, then it gives the traceback.
> ps shows that python is running. It looks like the coversion script is
> looping.
>
> bash$ lyx
> lyx2lyx: A development version
I have a patch ready (that seems to work) that does 99.9% of these
changes.
I am not sure that it cleans up a lot, but I guess it is a bit saner
anyway.
There shouldn't bee too many "ws only" chunks in this patch, but there
might be some.
Please comment.
(I had to zip this... size unzipped
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| The following patch fixes some compilation problems when
| BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
| (first hunk: when BOOST_NO_WREGEX is defined we end up including
| ) and something I found when trying to compile
"Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
| I am resending my Cygwin make patch, since it has not been applied yet.
|
| Apply the following patch and add the attached cygwin.m4 to config.
You are not forgotten.
--
Lgb
On Mon, Mar 17, 2003 at 12:54:40AM +0100, Lars Gullik Bj?nnes wrote:
> Please comment.
If bv_owner is always != 0, what is the isTopLevel() test all about ?
This seems dubious to me, look at RowPainter::paintFirst() - if bv_owner
was always set, then we'd get the top margin at the top of every
OK, here's a bug, interesting to see if others can reproduce on their
cleaner trees. Open the user guide and open the footnote at the top. Now
place the cursor right after "Introduction". You'll need to resize the
window / change font size so that, at this point, the button of the
footnote is at
Dear List,
The CVS versions of LyX obviously don't come with docs, they're in
another module checked out separately.
What I suggest is that the lyx-devel repository come with either a) an
extension to the makefile which adds relative symlinks as appropriate,
or b) some symlinks to the current
On Mon, Mar 17, 2003 at 01:15:21AM +0100, Lars Gullik Bjønnes wrote:
> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes:
>
> | I am resending my Cygwin make patch, since it has not been applied yet.
> |
> | Apply the following patch and add the attached cygwin.m4 to config.
>
> You are not
Hello,
Thanks a lot.
Do this change appears in lyx-1.3.1 ?
Now I know I have problem with table in minipages. So, I will find
another solution.
Yann COLLETTE
José Matos wrote:
On Thursday 13 March 2003 13:17, Yann COLLETTE wrote:
Hello,
I've got a huge file composed with lyx-1.1.6fix4 I
Title: ΪÁ˸üºÃµØ·þÎñÓÚÖйúÆóÒµ£¬±¾¹«Ë¾£¨½ðÖÇÉÌÒµÑо¿¹«Ë¾£©ÌØÍƳöÓн±µ÷²é»î¶¯
ΪÁ˸üºÃµØ·þÎñÓÚÖйúÆóÒµ£¬±¾¹«Ë¾£¨½ðÖÇÉÌÒµÑо¿¹«Ë¾£©ÌØÍƳöÓн±µ÷²é»î¶¯¡£Ï£ÍûÄúÄÜÔÚ°Ùæ֮Öгé³ö¼¸·ÖÖÓʱ¼ä£¬Ìîд¸½¼þÖеÄÎÊ¾í£¬²¢·¢»ØÎÒ¹«Ë¾£¬²»Ê¤¸Ð¼¤£¡ £¨¸½¼þÖеÄÒ»¸öwordÎļþÒѾŵ¶Üɱ¶¾£¬Çë·ÅÐÄ´ò¿ª£©
John Levon wrote:
> I'm not quite sure what behaviour has changed, though it might be the
> work Alfredo did with top_y possibly ? Can you explain again what
> behaviour changes you made for the graphics stuff ?
The change was pretty general (an safe): change all first_y as right value
with
88 matches
Mail list logo
