You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, FigureManagerBase defines {get,set}_window_title, which is overridden by the various gui-specific subclasses; FigureCanvasBase also defines {get,set}_window_title, which just forwards to the manager's method, but is a no-op otherwise. This has the consequence that one can call these methods on a canvas when embedding without using pyplot (#17716), but they will silently do nothing in that case, which... let's say qualifies as not nice behavior.
One option would be to just deprecate and remove the wrapper methods on canvas, and tell the user that they need to go through the manager (only possible if using pyplot) or gui-specific methods. Another option would be to instead move the main implementations to the canvas classes themselves (regardless of whether you're using pyplot or embedding, the notion of parent window for a FigureCanvasQt, for example, always makes sense, and one can always manipulate its title), and also move the gui-subclass-specific overrides to FigureCanvasFoo, and make the method on the manager just forward to the canvas. This would "always work", as a manager always has a canvas, but feels a bit dirty because we "sort of" want canvases to be only related to drawing and let the manager handle the windowing part.
(regardless of whether you're using pyplot or embedding, the notion of parent window for a FigureCanvasQt, for example, always makes sense, and one can always manipulate its title)
but the 1:1 mapping does not always make sense if users are doing their own thing (think many canvass in a TabLayout).
My instinct is to deprecate the canvas wrapper methods and promote manager to a more first-class concept (which is work @OceanWolf started a long time ago and we failed to follow through on).
Bug report
Bug summary
Currently, FigureManagerBase defines {get,set}_window_title, which is overridden by the various gui-specific subclasses; FigureCanvasBase also defines {get,set}_window_title, which just forwards to the manager's method, but is a no-op otherwise. This has the consequence that one can call these methods on a canvas when embedding without using pyplot (#17716), but they will silently do nothing in that case, which... let's say qualifies as not nice behavior.
One option would be to just deprecate and remove the wrapper methods on canvas, and tell the user that they need to go through the manager (only possible if using pyplot) or gui-specific methods. Another option would be to instead move the main implementations to the canvas classes themselves (regardless of whether you're using pyplot or embedding, the notion of parent window for a FigureCanvasQt, for example, always makes sense, and one can always manipulate its title), and also move the gui-subclass-specific overrides to FigureCanvasFoo, and make the method on the manager just forward to the canvas. This would "always work", as a manager always has a canvas, but feels a bit dirty because we "sort of" want canvases to be only related to drawing and let the manager handle the windowing part.
Matplotlib version
print(matplotlib.get_backend())
):The text was updated successfully, but these errors were encountered: