gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Resize behaviour for the wxt terminal

[Petr M. <mi...@ph...>]

> I just committed a small peace of code to fill in gray the empty space 
> left aside or below a plot when you resize the wxt terminal window

That's the reason why the wxt terminals can not longer be compiled in on 
SUSE 10.0?

checking for wx-config... /usr/bin/wx-config
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for CAIRO... yes
checking for PANGO... configure: WARNING: Pango can't be found. The 
wxWidgets terminal will not be compiled.
checking for PANGOCAIRO... configure: WARNING: Cairo rendering support for 
Pango can't be found. The wxWidgets terminal will not be compiled.


But it worked until now, the version is:
$ rpm -qa | grep -i pango
pango-1.10.0-3
pango-doc-1.10.0-3
pango-devel-1.10.0-3

Aha, I see it in ChangeLog ... but then the configure message is wrong: it 
should say that a newer version of pango is required. Please fix this.

---
PM

Re: Resize behaviour for the wxt terminal

[Daniel J S. <dan...@ie...>]

Timoth=C3=A9e Lecomte wrote:
> Dear gnuplot developpers,
>=20
> I just committed a small peace of code to fill in gray the empty space=20
> left aside or below a plot when you resize the wxt terminal window=20
> without keeping its aspect ratio constant. This was the easiest way to=20
> make this behaviour a little more easy to understand visually. I also=20
> modified the help text a little bit to reflect that. I would like to=20
> know if it's ok for you now. I know that this behaviour was one of the=20
> few complaints about the wxt terminal. I am still reluctant to make it=20
> behave like the x11 terminal, since I don't like it at all. Moreover,=20
> I'm convinced it's not a critical point: at worse, after some time the=20
> user will realize he just has to type 'replot' or, more easily, to clic=
k=20
> on the 'replot' icon to have the plot be redrawn completely to fit in=20
> the window.

Timoth=C3=A9e, could you send or place a screen capture somewhere with th=
is gray area?  Another thing you could do is force an aspect ratio on the=
 window rather than display some area as a different color, i.e., an abil=
ity to resize by mouse, but not independently in both dimensions.

I like the X11 behavior, but it isn't critical that other window platform=
s behave the same way.  Maybe an alternative from X11 is good at this poi=
nt.

Dan

Resize behaviour for the wxt terminal

[<tim...@en...>]

Dear gnuplot developpers,

I just committed a small peace of code to fill in gray the empty space=20
left aside or below a plot when you resize the wxt terminal window=20
without keeping its aspect ratio constant. This was the easiest way to=20
make this behaviour a little more easy to understand visually. I also=20
modified the help text a little bit to reflect that. I would like to=20
know if it's ok for you now. I know that this behaviour was one of the=20
few complaints about the wxt terminal. I am still reluctant to make it=20
behave like the x11 terminal, since I don't like it at all. Moreover,=20
I'm convinced it's not a critical point: at worse, after some time the=20
user will realize he just has to type 'replot' or, more easily, to click=20
on the 'replot' icon to have the plot be redrawn completely to fit in=20
the window.

Besides that, what are we waiting for for the 4.2 release ? Is there=20
some work left ?

Best regards,

Timoth=C3=A9e Lecomte

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> On Wed, Sep 13, 2006 at 12:34:27PM +0200, Timoth=E9e Lecomte wrote:
>  =20
>> Richard Henwood wrote:
>>    =20
>>> On Wed, Sep 13, 2006 at 11:07:30AM +0200, Timoth=E9e Lecomte wrote:
>>> =20
>>>      =20
> <snip>
>  =20
>>> With 'antialiasing and oversampling':
>>> _set_termvar oversampling_scale =3D 20
>>>
>>> and for the record, both 'No antialiasing' and 'Antialiasing'
>>> _set_termvar oversampling_scale =3D 1
>>> =20
>>>      =20
>> Ok, so there's no problem here. I'm starting to wonder if there could =
be=20
>> a problem with your version of pango and/or cairo. Could you tell me=20
>> what they are ?
>>
>>    =20
>
> cairo: 1.0.2-25
> pango: 1.10.2-21
>
> wxGTK: 2.6.2.1-20
>
> r,
>  =20
Well, I finally figured out the problem (the scaling matrix not applied=20
to the fonts), told about it on #freedesktop, and the friendly=20
pango/cairo guys told me that it got fixed in pango 1.10.3 (and newer,=20
we are at 1.14.3 right now). I can indeed reproduce the problem with=20
pango 1.10.2.

Please update your pango copy if you can. Meanwhile, I'll bump the=20
needed version of pango to 1.10.3 in the gnuplot's configure script.

Thanks for your help in tracking down this bug (I'm glad it's not in my=20
code ;).

Best regards,

Timoth=E9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
> Richard Henwood wrote:
>  =20
>
>> With 'antialiasing and oversampling':
>> _set_termvar oversampling_scale =3D 20
>>
>> and for the record, both 'No antialiasing' and 'Antialiasing'
>> _set_termvar oversampling_scale =3D 1
>>  =20
>>    =20
Please also tell me the other lines (logical_rect.*).
> Timoth=C3=A9e
>
>  =20

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> On Wed, Sep 13, 2006 at 11:07:30AM +0200, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Richard Henwood wrote:
>>    =20
>>
>>> As you noted in other correspondence, the resizing 'bug' has been
>>> fixed
>>>      =20
>> Ok.
>>    =20
>>>  - although the text does not scale exactly with the drawings.
>>> =20
>>>      =20
>> I would need a screenshot or something to understand what you mean her=
e.
>>    =20
>
> ok, with 'Antialiasing'. - see attached
> For example, the characters fill the box in default size, only half
> fill in resize to ~half default and are 2x to big in 2x resize.
>  =20
Hmm, I never saw that. Thanks for reporting it.
> Resizing, closing and then replotting the fonts appear to be the
> same size as they are in default size.
>  =20
Yeas, that's how it is implemented.
> I prefer the x11 behaviour on resize - where the fonts stay the same
> size and I get more graph detail.
>  =20
Ok.
> Does zooming by defining a region with right-click work? It doesn't
> work on my version. I get 'function to plot' returned to the gnuplot
> terminal.
>  =20
It does not work with 'test'.
>
>> With 'antialiasing and oversampling', you should read '_set_termvar=20
>> oversampling_scale =3D 20'. Can you verify if it's the case ?
>>
>>    =20
>
> With 'antialiasing and oversampling':
> _set_termvar oversampling_scale =3D 20
>
> and for the record, both 'No antialiasing' and 'Antialiasing'
> _set_termvar oversampling_scale =3D 1
>  =20
Ok, so there's no problem here. I'm starting to wonder if there could be=20
a problem with your version of pango and/or cairo. Could you tell me=20
what they are ?

Thank you, best regards,

Timoth=C3=A9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
>
> The latest cvs and clear instructions and I'm getting the printf's.
> Don't know what I got wrong but at least this is working.
>  =20
Good.
> As you noted in other correspondence, the resizing 'bug' has been
> fixed
Ok.
>   - although the text does not scale exactly with the drawings.
>  =20
I would need a screenshot or something to understand what you mean here.
> The results, from 'test':
>
> ...
>         System: Linux 2.6.16.21-0.13-smp
>  =20
Are you using a multiprocessor system ? That's interesting, because the=20
wxt terminal uses two threads and on such a system they would really run=20
in parallel unlike what happens on other machines like mine.
>         Copyright (C) 1986 - 1993, 1998, 2004
>         Thomas Williams, Colin Kelley and many others
>
>         Type `help` to access the on-line reference manual.
>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
>
>         Send comments and help requests to
> <gnu...@li...>
>         Send bug reports and suggestions to
> <gnu...@li...>
>
>
> Terminal type set to 'wxt'
> gnuplot> test
> _set_termvar fontsize =3D 10.000000
> _set_termvar PANGO_SCALE =3D 1024
> _set_termvar oversampling_scale =3D 1
> _set_termvar logical_rect.height =3D 16384
> _set_termvar logical_rect.width =3D 77824
> gnuplot>
>
> The font still look tiny with 'antialiasing and oversampling'
>  =20
With 'antialiasing and oversampling', you should read '_set_termvar=20
oversampling_scale =3D 20'. Can you verify if it's the case ?

Best regards,

Timoth=E9e

Re: Strange results with gnuplot version 4 on windows

[Daniel J S. <dan...@ie...>]

Barker, Niall wrote:
> Hi,
>  
> I am seeing peculiar results with wgnuplot version 4 whereby if my time
> data covers between 12:00:00 to 12:59:59 then the output resembles a
> sine curve even though the plotted data would never produce this curve.
> If however I plotted from 01:00:00 onwards then I do not see the same
> problems.
> I have attached an incorrect and a correct example.
>  
> I am not sure if this problem has been reported before as I cannot see
> reported bugs/problems on the /www.gnuplot.info/ site.

Certainly looks strange and I can't recall any such bug.  (Time scales are a bit dodgy right now and won't get a thorough examination until after 4.0... doesn't rule out small bug fixes.)

Could you make this easier for other to reproduce by showing the plot command and perhaps pull just a few sample points from your file?  E.g.,

plot "-" with ...
12:00:00 5
12:29:29 10
12:59:59 5
end

(I'm not real familiar with the time syntax.)

Dan

Re: Strange results with gnuplot version 4 on windows

[<br...@ph...>]

Barker, Niall wrote:

> I have attached an incorrect and a correct example.

Sorry, but those are very nearly useless.  We need to see the inputs 
(commands and data files --- better still, try to reproduce the problem 
without the need for data files).

> I am not sure if this problem has been reported before as I cannot see 
> reported bugs/problems on the /www.gnuplot.info/ site.

That's because that's not the place to post or view bugs.  You should be 
looking at our SourceForge.net pages.

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> On Tue, Sep 12, 2006 at 12:05:44AM +0200, Timoth=E9e Lecomte wrote:
>
> <snip>
>
>  =20
>> To apply the patch, go to the cvs checkout directory, and then:
>>
>> cd src/wxterminal
>> patch -p1 < debug_richard.diff
>> cd ../..
>>
>>    =20
>
> hmmmmmm, I think i've made a bit of a pigs ear of this:
>
> src/wxterminal> patch -p1 < /tmp/debug_richard.diff
> patching file gp_cairo.c
> Reversed (or previously applied) patch detected!  Assume -R? [n] y
> Hunk #2 FAILED at 1602.
> Hunk #3 FAILED at 1611.
> 2 out of 3 hunks FAILED -- saving rejects to file gp_cairo.c.rej
> src/wxterminal>
>
> I answered y, maybe that should have been a 'N'?
>  =20
That's my fault, I forgot to remove the CVS id at the beginning of the=20
diff file, and the 'patch' command probably got confused. Answering 'n'=20
should have been ok.
>  =20
>> Finally recompile with make; make install
>>
>> Once you've done that, try with your favorite plot command ('test' is=20
>> fine) and please send me the output messages you obtain with and witho=
ut=20
>> oversampling.
>>
>>    =20
>
> Ok, in the end I cut an pasted the diffd lines into gp_cairo.c and
> make' worked. Can I just run ./src/gnuplot - avoiding to need to
> make install?
>  =20
Sure.
> I don't get any printf output with test.
>  =20
Really ?? That's _very_ strange : if you placed this this serie of =20
printf at the right place,  the output _must_ appear at least once per pl=
ot.
> So, apologies for my clumsiness, but:
>  can you advise if I should start with a new
> checkout from CVS and if I should press y/n to the 'Assume -R?'
> query from patch.
>  =20
If you cut and paste manually, that should be enough. Use the attached=20
patch with a fresh cvs checkout if you prefer.

Could you put your gnuplot source directory and send it to me ? I wonder=20
if you don't have some problem with the source itself, and with a little=20
case I could even try to run your executable on my machine. (however,=20
don't send it to the whole list to avoid loading others' mailboxes)

Best regards, and thanks again for your help to debug this,

Timoth=E9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> On Tue, Sep 12, 2006 at 09:59:23AM +0200, Timoth=C3=A9e Lecomte wrote:
>  =20
>> Richard Henwood wrote:
>>    =20
>>> see attached screenshot.
>>>      =20
>> Looks like I'm not the only one to forget to attach things... ;)
>>
>>    =20
>
> Indeed!
>
> second time lucky:
>  =20
Ok, so the enhanced text mode suffer from the same problem. Thanks.

Timoth=C3=A9e
> r,
>  =20
>
> -----------------------------------------------------------------------=
-
>

Re: tiny fonts with wxt term

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
>
> Richard, could you please apply the=20
> attached patch to your gnuplot checkout ?
Oops, forgot to attach the patch, as usual. Sorry about that.

Timoth=C3=A9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
> Richard Henwood a =C3=A9crit :
>  =20
>> Timoth=C3=A9e Lecomte wrote:
>>  =20
>>    =20
>>> So, the bug only appears when the rendering method is set to
>>> 'Antialiasing and oversampling', right ?
>>>    =20
>>>      =20
>> correct.
>>
>>  =20
>>    =20
>>> Can you tell me if a font of size 200 with 'Antialiasing and
>>> oversampling' looks exactly the same as a size of 10 without
>>> 'oversampling' ?
>>>    =20
>>>      =20
>> It does not look _exactly_ the same. The font appears to be the same s=
ize
>> but on switching there is some slight movement in exact positions of t=
ext.
>> It is very slight an I can only notice it because I watch it switch.
>>  =20
>>    =20
> Ok, I was interested in the size in particular. So it seems the=20
> oversampling scale is somehow not applied to the text on your setup.=20
> That's strange...
> Could you please try the demo 'enhancedtext.dem' and tell me if it show=
s=20
> the same issue ? (the text goes through a slightly different code path=20
> for the enhanced text mode).
>
> Another question, most likely unrelated : what's your screen dpi ?=20
> (dots-per-inch, this info is given by 'xdpyinfo' for example)
I hope I am not asking too much... Richard, could you please apply the=20
attached patch to your gnuplot checkout ? It will add a couple of=20
debugging messages that would help me greatly.

To apply the patch, go to the cvs checkout directory, and then:

cd src/wxterminal
patch -p1 < debug_richard.diff
cd ../..

Finally recompile with make; make install

Once you've done that, try with your favorite plot command ('test' is=20
fine) and please send me the output messages you obtain with and without=20
oversampling.

(we could also meet on irc, #gnuplot on freenode)

Thank you very much.

Best regards,

Timoth=C3=A9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood a =C3=A9crit :
> Timoth=C3=A9e Lecomte wrote:
>  =20
>> So, the bug only appears when the rendering method is set to
>> 'Antialiasing and oversampling', right ?
>>    =20
>
> correct.
>
>  =20
>> Can you tell me if a font of size 200 with 'Antialiasing and
>> oversampling' looks exactly the same as a size of 10 without
>> 'oversampling' ?
>>    =20
>
> It does not look _exactly_ the same. The font appears to be the same si=
ze
> but on switching there is some slight movement in exact positions of te=
xt.
> It is very slight an I can only notice it because I watch it switch.
>  =20
Ok, I was interested in the size in particular. So it seems the=20
oversampling scale is somehow not applied to the text on your setup.=20
That's strange...
Could you please try the demo 'enhancedtext.dem' and tell me if it shows=20
the same issue ? (the text goes through a slightly different code path=20
for the enhanced text mode).

Another question, most likely unrelated : what's your screen dpi ?=20
(dots-per-inch, this info is given by 'xdpyinfo' for example)

>>
>>    =20
>>> If I make the changes to the rendering method and then resize, withou=
t
>>> closing/reopening the result is unpredictable, including: huge fonts,
>>> only some text displayed, graphics become pixelated, even a lockup.
>>>  =20
>>>      =20
>> Indeed. For this to work as expected, I would have not to change the
>> internal variables immediately, but schedule the change for the time o=
f
>> the next plot. Maybe I should do that before the release...
>>    =20
>
> it would be desirable from my point of view.
>  =20
This is committed.

Best regards,

Timoth=C3=A9e

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Timothée Lecomte wrote:

> Richard Henwood wrote:
>> Timothée Lecomte wrote:

<snips'>

>>   
> Typically you change the rendering method, click 'Ok' or 'Apply', and
> type 'replot' in the command line. Closing the terminal should not be
> needed (all the more since it only hides the window but does not do
> anything else actually), exiting gnuplot should not be needed too.
> 
> So, the bug only appears when the rendering method is set to
> 'Antialiasing and oversampling', right ?

correct.

> Can you tell me if a font of size 200 with 'Antialiasing and
> oversampling' looks exactly the same as a size of 10 without
> 'oversampling' ?

It does not look _exactly_ the same. The font appears to be the same size
but on switching there is some slight movement in exact positions of text.
It is very slight an I can only notice it because I watch it switch.

> (the oversampling precisely involves a scaling of 20)
> 
>> If I make the changes to the rendering method and then resize, without
>> closing/reopening the result is unpredictable, including: huge fonts,
>> only some text displayed, graphics become pixelated, even a lockup.
>>   
> Indeed. For this to work as expected, I would have not to change the
> internal variables immediately, but schedule the change for the time of
> the next plot. Maybe I should do that before the release...

it would be desirable from my point of view.

r,

Re: tiny fonts with wxt term

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
> Richard Henwood wrote:
>
>  =20
>> If I make the changes to the rendering method and then resize, without
>> closing/reopening the result is unpredictable, including: huge fonts, =
only
>> some text displayed, graphics become pixelated, even a lockup.
>>  =20
>>    =20
> Indeed. For this to work as expected, I would have not to change the=20
> internal variables immediately, but schedule the change for the time of=
=20
> the next plot. Maybe I should do that before the release...
I just commited a change to do that, so that particular misbehaviour on=20
window resize right after a change of the rendering settings is fixed.=20
Unfortunately, I still have not found the source of your first problem.

Best regards,

Timoth=C3=A9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Timoth=C3=A9e Lecomte wrote:
> ...
> So, the bug only appears when the rendering method is set to=20
> 'Antialiasing and oversampling', right ?
> Can you tell me if a font of size 200 with 'Antialiasing and=20
> oversampling' looks exactly the same as a size of 10 without=20
> 'oversampling' ?
> (the oversampling precisely involves a scaling of 20)
>
>  =20

And please note that the two fixes that I have just committed are=20
unfortunately unrelated to your problem...

Timoth=C3=A9e

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> Timoth=C3=A9e Lecomte wrote:
>
>  =20
>> Richard Henwood wrote:
>>    =20
>>> Timoth=C3=A9e Lecomte wrote:
>>>
>>> <snip previous conversation>
>>>      =20
>> <snip again>
>>
>> Richard, can you also try without oversampling ? ("Rendering method =3D
>> antialiasing" or "no antialiasing")
>>
>>    =20
>
> After switching to "without oversampling on both 'antialiasing' or 'no
> antialiasing'" the fonts look fine. However I need to close wxt term an=
d
> reopen in order to get this working predictably.
>  =20
Typically you change the rendering method, click 'Ok' or 'Apply', and=20
type 'replot' in the command line. Closing the terminal should not be=20
needed (all the more since it only hides the window but does not do=20
anything else actually), exiting gnuplot should not be needed too.

So, the bug only appears when the rendering method is set to=20
'Antialiasing and oversampling', right ?
Can you tell me if a font of size 200 with 'Antialiasing and=20
oversampling' looks exactly the same as a size of 10 without=20
'oversampling' ?
(the oversampling precisely involves a scaling of 20)

> If I make the changes to the rendering method and then resize, without
> closing/reopening the result is unpredictable, including: huge fonts, o=
nly
> some text displayed, graphics become pixelated, even a lockup.
>  =20
Indeed. For this to work as expected, I would have not to change the=20
internal variables immediately, but schedule the change for the time of=20
the next plot. Maybe I should do that before the release...
> HTH
> r,
>  =20

Best regards,

TImoth=C3=A9e

Re: Freeze and gnuplot 4.2 beta 1?

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:

>>Ethan put together a patch to clean up gplt_x11.c.  I propose that go in 
>>before the beta version.  It looked to me to cause no potential problems.
> 
> 
> Is it already in?

No.  But, it is listed on the patch site.  It could be moved in.  Or we could take the approach of moving it in immediately after the release.  There are about six patches from a month or two ago I put together that I think are in that category, i.e., are ready to add at any time.


> Section "help new-features" seems to be OK, please have look at faq.tex to 
> update the respective sections. There are some sections discussing some 
> patches which are already in 4.2.
> 
> I propose release of 4.2 this month.

I second that.

Dan

Re: Freeze and gnuplot 4.2 beta 1?

[Petr M. <mi...@ph...>]

> Yes.  But I think it should right to 4.2 patchlevel 0

Fine with me.

> Ethan put together a patch to clean up gplt_x11.c.  I propose that go in 
> before the beta version.  It looked to me to cause no potential problems.

Is it already in?


Section "help new-features" seems to be OK, please have look at faq.tex to 
update the respective sections. There are some sections discussing some 
patches which are already in 4.2.

I propose release of 4.2 this month.


---
PM

Re: tiny fonts with wxt term

[Richard H. <r.h...@rl...>]

Timothée Lecomte wrote:

> Richard Henwood wrote:
>> Timothée Lecomte wrote:
>>
>> <snip previous conversation>
> <snip again>
> 
> Richard, can you also try without oversampling ? ("Rendering method =
> antialiasing" or "no antialiasing")
> 

After switching to "without oversampling on both 'antialiasing' or 'no
antialiasing'" the fonts look fine. However I need to close wxt term and
reopen in order to get this working predictably.

If I make the changes to the rendering method and then resize, without
closing/reopening the result is unpredictable, including: huge fonts, only
some text displayed, graphics become pixelated, even a lockup.

HTH
r,

Re: tiny fonts with wxt term

[<tim...@en...>]

Richard Henwood wrote:
> Timoth=C3=A9e Lecomte wrote:
>
> <snip previous conversation>
<snip again>

Richard, can you also try without oversampling ? ("Rendering method =3D=20
antialiasing" or "no antialiasing")

Thank you.

Best regards,

Timoth=C3=A9e

Re: fill pattern

[Dhiman B. <dh...@ca...>]

Hi,
  I realize that more than 8 patterns can not be discerned 
by human eye at the same time. But, how difficult it would 
be to have patterns which are combinations of bar and points
(start, square etc) ?

Thanks,
Dhiman

Re: default: x11 or wxt?

[Daniel J S. <dan...@ie...>]

Timoth=E9e Lecomte wrote:
>>BTW, in the wxt "config" dialog, I propose to write "(-persist)" instea=
d
>>of
>>"(persist)", etc.
>=20
>=20
> I guess you are thinking of the command line option. Please note that y=
ou
> can also use 'set term wxt persist', so the '-' would be misleading in
> that case.
>=20
> Best regards,
>=20
> Timoth=E9e

If you are talking command line options and multiple terminal types for l=
inux/unix, I just want to note there is this in plot.c.

	} else if (!strcmp(argv[i], "-h") || !strcmp(argv[i], "--help")) {
	    printf( "Usage: gnuplot [OPTION]... [FILE]\n"
#ifdef X11
		    "for X11 options see 'help X11->command-line-options'\n"
#endif
		    "  -V, --version\n"
		    "  -h, --help\n"

which is probably good if gnuplot is set up to have just wxt and not x11.=
  But if there are both wxt and x11 present in the same build, and there =
is to be wxt options, then listing the wxt options as well may be the log=
ical choice.

Dan

Re: default: x11 or wxt?

[Richard H. <r.h...@rl...>]

Timothée Lecomte wrote:

>> On SUSE 10.0, I can see the following problem with wxt: the mouse cursor
>> is
>> white. Thus you don't see the pointer on white graph background. We tried
>> to
>> debug it with Timothee some time ago, and it turned out to be due to a
>> combination of the wx (2.6.1) et al libraries, which is obviously fixed
>> in newer wx. Does somebody else see this problem?
> 
> Strange problem, indeed. It would help to have other reports.
> 

I haven't had this problem on my setup, the cursor appears as a small black
cross over the graph.
wx version: 2.6.2.1-20

r,