FigureCanvasWx/Agg fixed size #10377
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Summary
(replacement for PR #10153)
The embedded FigureCanvasWx currently can't be set to a fixed size.
When it is added to a sizer with
proportion=0
andwx.EXPAND
not set, then it will not expand over it's defined size, as expected. But when the visible area is reduced below the defined size, it will re-scale itself to fit the visible area because 'self.GetClientSize()' is used to read the size.This could happen if the window size is reduced or a splitter is used.
When placed on a scrolled window, the problem does not occur, as then the VirtualSize will not change, even when the widget is not 100% visible.
This is not a big issue as the behaviour can easily be modified in a derived class. It would be nice though, to have the correct behaviour by default.
See attached file
embedding_in_wx4_fixed.py
for an example. With the modification from the pull request the size will stay fixed.The only change is the
sizer.Add
call withproportion=0
and withoutEXPAND
:embedding_in_wx4_fixed.py.txt
I could commit the example file, but that's probably not worth it.
If the canvas is directly used as single child of a frame (i.e. instead of a panel), the behaviour is not modified by the pull request. This could be changed, but I don't see a use case for this.
Btw.: I just noticed that the
embedding_in_wx4.py
example includes anEVT_PAINT
handler. I don't think that this is required, as the plot is static. Instead, it causes unnecessary renderings.Also, the structure of
fourier_demo_wx.py
is a bit unusual. The usual hierarchy would beFrame->Panel->Sizer->Canvas
. Actually it's nowFrame->Sizer->Window->Canvas
where theWindow
does not have any function and the sliders are drawn on the plain frame background.I could submit a PR to update the demos, if desired.
PR Checklist