Skip to content

FigureCanvasWx/Agg fixed size #10153

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

DietmarSchwertberger
Copy link
Contributor

@DietmarSchwertberger DietmarSchwertberger commented Jan 3, 2018

PR Summary

(sorry, it seems that I should have checked out master before creating the new branch; now the two commits from PR #10145 are visible as well)

The embedded FigureCanvasWx currently can't be set to a fixed size.
When it is added to a sizer with proportion=0 and wx.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 with proportion=0 and without EXPAND:

self.figure = Figure(figsize=(5, 4), dpi=100)
...
self.canvas = FigureCanvas(self, -1, self.figure)
self.sizer = wx.BoxSizer(wx.VERTICAL)
#self.sizer.Add(self.canvas, 1, wx.TOP | wx.LEFT | wx.EXPAND)
self.sizer.Add(self.canvas, 0, wx.TOP | wx.LEFT)

embedding_in_wx4_fixed.py.txt

I could commit the example file, but that's probably not worth it.

If there is consensus to change the behaviour, then I would ask Robin to review the implementation to check whether this is the best way to check for fixed size.

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 a EVT_PAINT handler. I don't think that this is required, as the plot is static.

PR Checklist

  • Has Pytest style unit tests
  • Code is PEP 8 compliant
  • New features are documented, with examples if plot related
  • Documentation is sphinx and numpydoc compliant
  • Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
  • Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

@DietmarSchwertberger
Copy link
Contributor Author

Somehow re-basing to get rid of the unwanted commits failed; will re-do...

@DietmarSchwertberger DietmarSchwertberger deleted the BACKENDWX_FIXEDSIZE branch February 3, 2018 17:08
@tacaswell
Copy link
Member

@DietmarSchwertberger in general you can force-push to branches to update PR and discard commits you don't want (github PRs track a branch on your repo, not a particular commit).

@DietmarSchwertberger
Copy link
Contributor Author

Thanks. I'm still struggling with git and the available frontends (I'm a GUI guy and just switching from Hg). Google did not give me a good answer. But I will check the documentation for force-push and try again tomorrow.

@jklymak
Copy link
Member

jklymak commented Feb 3, 2018

Worst-case scenario:

  • you have your work saved (in a backup branch, other backup) before you attempt a rebase
  • your rebase messes up
  • you delete the PR branch and rename/copy the backup branch to the same name as the PR branch
  • you force push the PR

https://matplotlib.org/devdocs/devel/gitwash/index.html

@tacaswell
Copy link
Member

I have heard good things about the github application (but have not used it). I do most of my git work through emacs + magit (which is effectively an awesome git GUI, but I recognize the issue with saying "use emacs!").

If you are on windows, everything I have heard about visualstudio + python + git has been positive.

@DietmarSchwertberger
Copy link
Contributor Author

Unfortunately, it's not possible to re-open a PR after re-creating the tracked branch (isaacs/github#361)
So I had to re-create it as #10377

@jklymak: Thanks for the link. It's a better starting point than other documents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants