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).

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.

Completely agree with Eric's comments about removing the Qt3 backend.

On Mon, Apr 29, 2013 at 2:30 PM, Eric Firing [email protected]:

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 https://github.com/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.

Well, I did say that I could be convinced otherwise. Apparently, I was
convinced at some point and completely forgot about it. Go figure...

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.

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.

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."

At the very least the Qt3 backend should be removed before a Qt5 one is added.

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.

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?

@pelson, your proposal is OK with me.

Closed by #2026.