One more thought along this line. Perhaps it's possible for
> matplotlib to inspect whether or not any of the supported
> gui's has already been imported and make that the
> default. It seems like a sensible rule to me. If none are
> found, then all the other mechanisms apply.
I've given a little thought to this and it is certainly possible. In
the backend selection code we can detect the case when the backend has
not been *explicity* set by either -d or matplotlib.use. In the case
that we are using the default from matplotlib rc, and the default is a
GUI, we could do two things to help prevent mistakes
* make sure no conflicting gui is loaded in sys.modules. If another
is, go with that (issue a warning)
* if no other is loaded, try and load the required GUI lib in a
try/except block. If the load fails, look for an alternative and
use that instead (issue a warning)
I don't see a major problem with this approach. I want to avoid the
microsoft approach of doing too much behind the scenes to try and
accommodate the careless user, since this often runs afoul of the
power user, and often leads to situations that are difficult to debug.
I think if we issue warnings we can at least make clear what is
happening which should satisfy both potential problems.
Any forseeable problems with this approach?
JDH
John Hunter writes:
> One more thought along this line. Perhaps it's possible for
> matplotlib to inspect whether or not any of the supported
> gui's has already been imported and make that the
> default. It seems like a sensible rule to me. If none are
> found, then all the other mechanisms apply.
I've given a little thought to this and it is certainly possible. In
the backend selection code we can detect the case when the backend has
not been *explicity* set by either -d or matplotlib.use. In the case
that we are using the default from matplotlib rc, and the default is a
GUI, we could do two things to help prevent mistakes
* make sure no conflicting gui is loaded in sys.modules. If another
is, go with that (issue a warning)
* if no other is loaded, try and load the required GUI lib in a
try/except block. If the load fails, look for an alternative and
use that instead (issue a warning)
I don't see a major problem with this approach. I want to avoid the
microsoft approach of doing too much behind the scenes to try and
accommodate the careless user, since this often runs afoul of the
power user, and often leads to situations that are difficult to debug.
I think if we issue warnings we can at least make clear what is
happening which should satisfy both potential problems.
Any forseeable problems with this approach?
It sounds like a good thing to try. As time goes on, perhaps
ways of making different gui's coexist may be found and implemented.
But that may take some time even if possible. This proposal
seems the best short term solution.
Perry
> * make sure no conflicting gui is loaded in sys.modules. If another
> is, go with that (issue a warning)
>
> * if no other is loaded, try and load the required GUI lib in a
> try/except block. If the load fails, look for an alternative and
> use that instead (issue a warning)
John, you are right, too much behind the scenes work is not justified, but the uninitiated user should have as easy an "entry" as is reasonable. So this seems like a good solution. If a shell wont play nice with the backend, a warning stating as much is better than a frozen window.