[snip]
There are a couple of issues with the wx backend that I've noticed on
my redhat linux 9 box with wxpython compiled from the src package
wxPythonSrc-2.4.2.4. All of these are problems I was having with the
*last* version of wx you checked in. I'm at home and can't test the
latest code since I don't have wx installed here yet.1) ylabel (vertical) text is not rendered properly
This works for me on both Windows and GTK ports of wxPython (actually, the
Linux font handling is better than Windows, to my surprise). I believe that
my Debian port is linked against GTK 1.x rather than GTK 2.x, which may make
a difference. If you are using wxMotif, some of the font support is weaker
than the GTK port, which may be the issue. Hard for me to tell.
2) initial figure window placement is still partially off screen
I can fix this with a default window position parameter, but wx is supposed to
guess this 'intelligently' by default (and does so for me). I'll try a
default position parameter and see how we go. If you want to see if this
helps, pass a pos=wxPosition(x,y) default parameter to the call to
wxFrame.__init__() frame (in FigureFrameWx constructor)
I'll try to get something into the next CVS check-in.
3) With a window resize, the figure doesn't seem to resize in
correct proportions. This is something I've experimented only
briefly so am not sure.
Haven't noticed this problem (apart from text - I'll look at this when I have
a moment) - but I'll try a few experiments.
4) I've also noticed some pixel rounding error -- eg on the
histogram demo. I have similar problems with the GTK backend and
am not sure how to best resolve them. This tends to not be a
problem on high res outputs where a single dot off is less
noticeable.
5) Do your dashes scale with DPI? On the GTK, GD and PS backends, I
specify dashes with points so the appearance scales with figure
resolution. The whole issue of how things scale with DPI will
probably arise when you get the save to hardcopy functionality
implemented. In the eearly release of the GTK backend I did not
handle these issues, but they inevitably become important.
I believe that dashes scale, but until I have a higher resolution output I
won't be sure. In fact, wxPython does have the capability to generate
user-defined dashes, but I never managed to make it work, and it's very
poorly documented. I suspect that I may come back to this one later.
6) The toolbar is at the top rather than then bottom of the figure.
This was a bug in one particular CVS check-in. I believe that it has gone now,
although I am having some trouble making a button which responds to
mousewheel events in a cross platform way - this is curretnly the main
toolbar issue.
Overall things are looking very good. I may spend some time reading
up on the WX API to see if I can lend a hand on any of these lingering
issues since I have achieved most of my goals on the frontend side for
0.40. I would like to have the wx backend in a refined state because
I suspect a lot of wx users will check out the package when we
announce to the wx mailing list.
I'm pretty busy with other things this week, but I'll try to get preliminary
graphics export support in place, and a couple of bugfixes (especially the
toolbar mousewheel problem, which is important).
Regards
Jeremy
···
On Saturday 22 November 2003 3:48 pm, you wrote: