Repository navigation
All included backends should work or be removed #1961
Description
For the 1.3 release, I think we should endeavor to have all backends working or removed. My definition of "working" here is a pretty low bar: I mean essentially importing and producing a usable result. I'm not talking about having all the fonts exactly match etc. such as with the known issues with (non-Agg) Wx and Gtk.
Here are the backends that I think are on the short list for removal:
- emf (requires pyemf, which is not currently available on PyPI)
- CocoaAgg -- reportedly doesn't import, but I haven't confirmed on a Mac
- fltk -- pyfltk doesn't have packages for my system (Fedora 18) and there are errors compiling it from source
And one additional suggestion -- it's working, but could be considered obsolete:
- Qt3Agg -- so much of the world has moved on to Qt4 and beyond, maybe it's time to retire these?
I know the Wx and Gtk backends are probably also low on the popularity list at this time, but they fill a unique niche for by providing better performance over remote X11 connections.
Activity
WeatherGod commented on Apr 29, 2013
Backends are an interesting beast. While we have done a fantastic job of
making most users completely unaware of the fact that backends even exist,
we still provide full access to particular backends for a wide variety of
uses. Therefore, if one chooses to use a particular backend, it is
generally going to be for a particular reason related to that backend
(e.g., embedding in an application and such). So, I would propose that any
deprecation of a backend takes two release cycles rather than the normal
one release.
I would probably suggest deprecating Qt3Agg at the next release. There
really isn't a maintenance burden yet, I don't think, and there are still
plenty of systems out there on LTS using Qt3 (particularly the RHEL
systems). I could be convinced otherwise to start the deprecation now,
though.
As for the emf format, it is an odd duck, but for those who do still have
pyemf, it works. I have never gotten fltk working for me (not that I
really tried, though).
efiring commented on Apr 29, 2013
From the present backend_qt.py:
warnings.warn("QT3-based backends are deprecated and will be removed after" " the v1.2.x release. Use the equivalent QT4 backend instead.", mplDeprecation)@WeatherGod, you put that in 7 months ago, so I think we should go ahead and remove backend_qt.py in 1.3. The people on old RHEL systems can continue using an older mpl, or they can use a different backend if they update their mpl.
There is a real maintenance burden with all code clutter. I felt it with fltk around the mpl 1.0 release. The last news item on http://pyfltk.sourceforge.net/ is dated August, 2009, so it looks like it has completely stalled. I think we should put in a deprecation warning for 1.3 and remove it in 1.4. If pyfltk somehow springs back to life, there is nothing to prevent us (or rather, some suitably motivated person) from updating backend_fltkagg and restoring it to mpl.
The last pyemf release appears to date back to 2006. It's time to drop backend_emf. Deprecate now, remove in 1.4.
CocoaAgg requires PyObjC; when I try to "pip install pyobjc", it fails. I don't know why. Unlike pyfltk, pyobjc is a live project. CocoaAgg, however, is not a live project, and it is not at all clear that it has ever been used as an alternative backend. From the docstring:
Notes: - Requires PyObjC (currently testing v1.3.7) - The Tk backend works nicely on OSX. This code primarily serves as an example of embedding a matplotlib rendering context into a cocoa app using a NSImageView.So it sounds to me like if it actually works, it should be migrated out to a cookbook wiki, or an example. ASAP.
I think mpl is at a stage of maturity where it is important to actively trim out clutter and bloat; removing these backends is one part of that process.
ddale commented on Apr 29, 2013
Completely agree with Eric's comments about removing the Qt3 backend.
WeatherGod commented on Apr 29, 2013
On Mon, Apr 29, 2013 at 2:30 PM, Eric Firing notifications@github.comwrote:
mdboom commented on Apr 29, 2013
Ah -- I should have actually looked at the Qt3 backend first ;) So I think we're in agreement on removing it for 1.3, then.
I think I see the argument for making CocoaAgg an example rather than a real backend.
Maybe for EMF and fltk we poll the users list and if no responses, remove them?
EDIT: I meant for EMF and fltk, deprecate.
Tillsten commented on Apr 29, 2013
I tried the emf backend recently, but the result was not really useable. Irc, there was no text visible after import into publisher, also the linewidths were not right. I think dropping emf should be ok, it did no seem very useable.
embray commented on Apr 30, 2013
Problem with deprecation warnings such as the one about QT3 is that people ignore them and go about their business as if things will never change. I recently removed some interfaces from the master branch on pyfits that have been screaming "deprecated" for nearly two years, and sure enough as soon as I removed them lots of code broke.
I think that before removing any deprecated backends it's good to scream about it in release notes, etc. for at least one more release. People will still ignore it but at that point you can really say "Well we gave you fair warning."
toddrjen commented on May 1, 2013
At the very least the Qt3 backend should be removed before a Qt5 one is added.
pelson commented on May 2, 2013
I installed PyObjC last night and the CocoaAgg backend functions. PyObjC looks like it might have had a bit of a revival (there was talk of it being able to create iPad/iPhone apps, which I think gave it a boost of impetus).
CocoaAgg is not a fully fledged backend (there are no icons nor interactivity) so I would agree that, unless we can find somebody willing to put in a bit of effort to bring the GUI up to TkAgg/Gtk3Agg/Qt4Agg/WxAgg/MacOs quality, we move the code into an example in examples/user_interfaces.
I propose we do that for v1.4 putting in a strongly worded CocoaAgg backend deprecation warning (which encourages contributors to bring the CocoaAgg backend up to standards) for v1.3. I see no reason, since it is functional has not had a development burden recently, for us to remove it for v1.3. Thoughts?
efiring commented on May 2, 2013
@pelson, your proposal is OK with me.
mdboom commented on May 21, 2013
Closed by #2026.