As far as I know, the non-agg gtk backend gets little or no maintenance, lacks capabilities that the other backends have (this is a dim recollection--I haven't looked into specifics), and is rarely tested or used. Shouldn't we deprecate it? If so, on what schedule for removal?
+1 on deprecating cocoaAgg. I thought it already was.
Also, aren't all of the agg-based backends simply subclasses of their
respective "pure" backends (with exception of macosx and tkagg, of course)?
So how would deprecation actually work? Would we simply disallow calling
matplotlib.use('gtk')? Would we be merging the classes together? Make the
base class private?
Yes you are right about the cocoaAgg backend. I think we can just remove it now.
We don't have to decide how to remove the GDK and WX backend before deprecating them we just have to find a way to trigger the deprecation warning in one and not the other. Anyway we also have both a backend_qt4.py and backend_qt4agg.py but we have no qt4 backend that doesn't use Agg as far as I know so this would presumably be similar
In the case of gtk, backend_gtk.py invokes the gdk renderer by default. backend_gtkagg.py overrides that to use the agg renderer. Therefore we would remove backend_gdk.py, and change the invocation of its renderer to NotImplementedError. Also, there are a few places where gtk would be removed from lists of backends. All of this is for complete removal. For deprecation, the warning could be put in matplotlib.use, but I haven't tried to figure out all of the possible routes to backend selection so as to find the best place or places for the warning.
In the case of gtk, backend_gtk.py invokes the gdk renderer by default.
backend_gtkagg.py overrides that to use the agg renderer. Therefore we
would remove backend_gdk.py, and change the invocation of its renderer to
NotImplementedError. Also, there are a few places where gtk would be
removed from lists of backends. All of this is for complete removal. For
deprecation, the warning could be put in matplotlib.use, but I haven't
tried to figure out all of the possible routes to backend selection so as
to find the best place or places for the warning.
Activity
jenshnielsen commented on Jun 6, 2016
I agree. I would suggest deprecating it for 2.0 and removing it in 2.2 or perhaps 2.3
I also think we should consider to deprecate the WX (not WXAgg ) backend and the cocoaAgg backed in the same instance.
That leaves us with backends based on:
along with our internal
backends.
tacaswell commented on Jun 6, 2016
👍 on all accounts.
efiring commented on Jun 6, 2016
On 2016/06/05 10:24 PM, Jens Hedegaard Nielsen wrote:
Agreed.
WeatherGod commented on Jun 7, 2016
+1 on deprecating cocoaAgg. I thought it already was.
Also, aren't all of the agg-based backends simply subclasses of their
respective "pure" backends (with exception of macosx and tkagg, of course)?
So how would deprecation actually work? Would we simply disallow calling
matplotlib.use('gtk')? Would we be merging the classes together? Make the
base class private?
On Mon, Jun 6, 2016 at 1:07 PM, Eric Firing notifications@github.com
wrote:
jenshnielsen commented on Jun 7, 2016
Yes you are right about the cocoaAgg backend. I think we can just remove it now.
We don't have to decide how to remove the GDK and WX backend before deprecating them we just have to find a way to trigger the deprecation warning in one and not the other. Anyway we also have both a backend_qt4.py and backend_qt4agg.py but we have no qt4 backend that doesn't use Agg as far as I know so this would presumably be similar
efiring commented on Jun 7, 2016
In the case of gtk, backend_gtk.py invokes the gdk renderer by default. backend_gtkagg.py overrides that to use the agg renderer. Therefore we would remove backend_gdk.py, and change the invocation of its renderer to NotImplementedError. Also, there are a few places where gtk would be removed from lists of backends. All of this is for complete removal. For deprecation, the warning could be put in matplotlib.use, but I haven't tried to figure out all of the possible routes to backend selection so as to find the best place or places for the warning.
tacaswell commented on Jun 7, 2016
I would put the warning in the gdk renderer
On Tue, Jun 7, 2016, 14:05 Eric Firing notifications@github.com wrote: