Describe FigureManager #14106
Describe FigureManager #14106
Conversation
lib/matplotlib/backend_bases.py
Outdated
|
|
||
| **Key and mouse button press handling** | ||
|
|
||
| The manager allows to process matplotlib `.Event`\s. |
There was a problem hiding this comment.
The thing the FigureManagerBase does in relation to key events is to hook up the default key_press_handler to the Canvas (which is what handles the bridge from the GUI event system to our internal system).
There was a problem hiding this comment.
Thanks. Is that something a user would in any way interact with (like set_window_title()) or is that just a technical aspect that is not relevant to the user. In particular, will the user call key_press() under any circumstances?
There was a problem hiding this comment.
Maybe for testing or in some edge-cases, but I would not expect it in normal course of operation.
I suspect the reason key_press is a method is so that sub-classes could over-ride exactly what it did without having to handle the mpl_connect call and bookkeeping (but we don't actually do that internally).
d33e884 to
f5512a2
Compare
| Subclasses will have additional attributes and functions to access | ||
| additional functionality. This is of course backend-specific. For example, | ||
| most GUI backends have ``window`` and ``toolbar`` attributes that give | ||
| access to the native GUI widgets of the respective framework. |
There was a problem hiding this comment.
I think we should either standardize or deprecate these attributes...
There was a problem hiding this comment.
TL;DR I prefer to just document the current state within this PR. Any API changes should be discussed separately.
Can we standardize of deprecate either way? I think they are the only (easy) way to access the window and toolbar; so deprecating is not an option. OTOH, not all backends have these, e.g. FigureManagerMac does not have a window - well we could set them to None if not available.
Since the manager is actually a slightly broader concept, I'm not sure if this functionality should be in the base class - Well it's sort of already past that point having FigureManagerBase.set_window_title. One possibility would be to introduce a FigureWindowManager in between, that introduces this functionality. Also, when changing the API, I would like to think about how support a tabbed window #2194 within this framework.
There was a problem hiding this comment.
Sorry, that was intended as a side discussion, not to block this PR.
|
@dstansby Thanks. Comments applied. |
|
ping @dstansby |
0af9c23 to
6d571b1
Compare
6d571b1 to
c1e3fd4
Compare
PR Summary
Describe the
FigureManagerBaseclass. While I think "manager" really a bad term here, we're stuck with it. So at least describe what it's about.Note: Im quite unclear on the role of the FigureManager concerning the event stuff, therefore I've kept that part really vague. If somebody has a better description commits are welcome. Otherwise, this is at least a lot better than the current documentation.