|
| 1 | +======================================== |
| 2 | + MEP23: Multiple Figures per GUI window |
| 3 | +======================================== |
| 4 | + |
| 5 | +.. contents:: |
| 6 | + :local: |
| 7 | + |
| 8 | + |
| 9 | + |
| 10 | +Status |
| 11 | +====== |
| 12 | + |
| 13 | +**Discussion** |
| 14 | + |
| 15 | +Branches and Pull requests |
| 16 | +========================== |
| 17 | + |
| 18 | +**Previous work** |
| 19 | +- https://github.com/matplotlib/matplotlib/pull/2465 **To-delete** |
| 20 | + |
| 21 | + |
| 22 | +Abstract |
| 23 | +======== |
| 24 | + |
| 25 | +Add the possibility to have multiple figures grouped under the same |
| 26 | +`FigureManager` |
| 27 | + |
| 28 | +Detailed description |
| 29 | +==================== |
| 30 | + |
| 31 | +Under the current structure, every canvas has its own window. |
| 32 | + |
| 33 | +This is and may continue to be the desired method of operation for |
| 34 | +most use cases. |
| 35 | + |
| 36 | +Sometimes when there are too many figures open at the same time, it is |
| 37 | +desirable to be able to group these under the same window |
| 38 | +[see](https://github.com/matplotlib/matplotlib/issues/2194). |
| 39 | + |
| 40 | +The proposed solution modifies `FigureManagerBase` to contain and |
| 41 | +manage more than one `canvas`. The settings parameter |
| 42 | +`rcParams['backend.multifigure']` control when the **MultiFigure** |
| 43 | +behaviour is desired. |
| 44 | + |
| 45 | +**Note** |
| 46 | + |
| 47 | +It is important to note, that the proposed solution, assumes that the |
| 48 | +[MEP22](https://github.com/matplotlib/matplotlib/wiki/Mep22) is |
| 49 | +already in place. This is simply because the actual implementation of |
| 50 | +the `Toolbar` makes it pretty hard to switch between canvases. |
| 51 | + |
| 52 | +Implementation |
| 53 | +============== |
| 54 | + |
| 55 | +The first implementation will be done in `GTK3` using a Notebook as |
| 56 | +canvas container. |
| 57 | + |
| 58 | +`FigureManagerBase` |
| 59 | +------------------- |
| 60 | + |
| 61 | +will add the following new methods |
| 62 | + |
| 63 | +* `add_canvas`: To add a canvas to an existing `FigureManager` object |
| 64 | +* `remove_canvas`: To remove a canvas from a `FigureManager` object, |
| 65 | + if it is the last one, it will be destroyed |
| 66 | +* `move_canvas`: To move a canvas from one `FigureManager` to another. |
| 67 | +* `set_canvas_title`: To change the title associated with a specific |
| 68 | + canvas container |
| 69 | +* `get_canvas_title`: To get the title associated with a specific |
| 70 | + canvas container |
| 71 | +* `get_active_canvas`: To get the canvas that is in the foreground and |
| 72 | + is subject to the gui events. There is no `set_active_canvas` |
| 73 | + because the active canvas, is defined when `show` is called on a |
| 74 | + `Canvas` object. |
| 75 | + |
| 76 | +`new_figure_manager` |
| 77 | +-------------------- |
| 78 | + |
| 79 | +To control which `FigureManager` will contain the new figures, an |
| 80 | +extra optional parameter `figuremanager` will be added, this parameter |
| 81 | +value will be passed to `new_figure_manager_given_figure` |
| 82 | + |
| 83 | +`new_figure_manager_given_figure` |
| 84 | +--------------------------------- |
| 85 | + |
| 86 | +* If `figuremanager` parameter is give, this `FigureManager` object |
| 87 | + will be used instead of creating a new one. |
| 88 | +* If `rcParams['backend.multifigure'] == True`: The last |
| 89 | + `FigureManager` object will be used instead of creating a new one. |
| 90 | + |
| 91 | +`NavigationBase` |
| 92 | +---------------- |
| 93 | + |
| 94 | +Modifies the `NavigationBase` to keep a list of canvases, directing |
| 95 | +the actions to the active one |
| 96 | + |
| 97 | +Backward compatibility |
| 98 | +====================== |
| 99 | + |
| 100 | +For the **MultiFigure** properties to be visible, the user has to |
| 101 | +activate them directly setting `rcParams['backend.multifigure'] = |
| 102 | +True` |
| 103 | + |
| 104 | +It should be backwards compatible for backends that adhere to the |
| 105 | +current `FigureManagerBase` structure even if they have not |
| 106 | +implemented the **MultiFigure** magic yet. |
| 107 | + |
| 108 | + |
| 109 | +Alternatives |
| 110 | +============ |
| 111 | + |
| 112 | +Insted of modifing the `FigureManagerBase` it could be possible to add |
| 113 | +a parallel class, that handles the cases where |
| 114 | +`rcParams['backend.multifigure'] = True`. This will warranty that |
| 115 | +there won't be any problems with custom made backends, but also makes |
| 116 | +bigger the code, and more things to mantain. |
0 commit comments