> I went ahead and implemented this yesterday on a long plane flight.
> The changed files (backend_bases.py, and widgets.py) are attached to
> the above tracker entry. Also I changed backend_wx.py to grab the
> mouse generally when you click on the graphs, so that panning and such
> continues to track even when you go outside the window. Similar
> changes should probably also be made to the other backends too.
This sounds like it could be a pretty stellar improvement to the WX
Just to be clear, the only thing that applies to wx specifically is
that I made the wx backend grab the system pointer on mouse down and
release it on mouse up. (Basically just a change of 4 lines of code
-- two CaptureMouse() calls and two ReleaseMouse() calls). The rest
is GUI independent and should benefit all GUI backends.
I should be at a work-related meeting on Tuesday with Matt Newville,
the WX backend maintainer. I'll try to get some time set aside to
get your changes merged on my laptop before them, so that we can
check them out properly afterward. My big concern is to investigate
how these changes may affect people who are embedding WxAgg figures
in wxPython applications. If you've done what I think you have, that
shouldn't be a problem.
Definitely more people should test it and review the code. It works
for me, but maybe there are some things I haven't thought of. Like
I've never tried embedding. But I don't think this should cause
problems there. On the other hand, the widget-level grabbing
infrastructure might have problems with a GUI back-end that doesn't do
system-level grabbing. For instance you start dragging on a Slider,
drag off the window, and let go. If you aren't doing system level
grabbing then you won't ever get the mouse up to tell you that you
should release the widget-level mouse grab.
> I also added get_value methods to the CheckButtons and RadioButtons,
> because it didn't seem like there was any good way to get that info.
You may want to submit this portion of the changes as a separate
patch. I've found that my patches get accepted faster when I only do
one thing per patch.
Ok. Such a pain though... Are whole files acceptable instead of
diffs? It's relatively easy to do a windiff or whatever to look over
the changes and accept or reject line by line. (In fact Robert
Osfield who quite ably runs the OpenSceneGraph project feels so
strongly about it that he *only* allows patches to be submitted as
complete files so he can easilly use a visual diff tool to merge
> Finally I don't really get what the deal is with the Slider's
> "closedmin"/"closedmax" options.
Sorry, I can't help you with this one.
> Please let me know if there's a better way/place to submit patches.
I've always done exactly what you're doing now: uploading it on SF
then emailing the developers' list.
On 7/31/06, Ken McIvor <mcivor@...227...> wrote:
On Jul 30, 2006, at 8:07 AM, Bill Baxter wrote: