Added a GTK3 implementation of the SubplotTool window. #1035

Closed
wants to merge 1 commit into
from

Projects

None yet

4 participants

@jrjohansson
Contributor

This pull request contains a GTK3 implementation of the SubplotTool window in the GTK3 backend. Currently, when selecting the GTK3 backend (GTK3Cairo or GTK3Agg) and clicking on the subplot configuration menu button, a non-GTK based GUI window appears. For consistency I think that this configuration window should follow the GTK look-and-feel if the GTK3 backend is selected. Tested on python2.7 and python3.2.

@efiring
Member
efiring commented Jul 24, 2012

I appreciate the work that went into this, but after testing it, I cannot support merging the PR. The Gtk3 Tool adds code that needs to be maintained, and provides no functional advantage. On the contrary, it lacks the red lines in the mpl generic tool which provide a nice reference point, and it is strangely sluggish and unresponsive. (As a side note, I think the qt4-specific tool is also less functional than the mpl generic one, and should be removed.)

@jrjohansson
Contributor

OK, fair enough.

But I think your logic goes against the purpose of having toolkit specific backends in the first place.

In my opinion it is a great advantage of having a consistent GUI experience in for example the Qt and GTK backends. This is especially important when embedding a matplotlib figure in external applications. Then you really don't want configuration GUIs that appear to pop out of the 90s when clicking on the some of the toolbar buttons. So I think you'd do yourself a big disservice by removing the Qt specific improvements and discourage improvements in the GTK backend.

Also, I think the red line in the generic GUI that marks the old settings is nice, but quite marginal to the function of the subplot configuration window, and its function is in some sense duplicated by the reset button.

As for the sluggishness, I have not noticed that it is any more sluggish than the generic configuration window on my system, but this could probably be improved on.

@efiring
Member
efiring commented Jul 25, 2012

On 2012/07/24 3:15 PM, Robert Johansson wrote:

OK, fair enough.

But I think your logic goes against the purpose of having toolkit
specific backends in the first place.

In my opinion it is a great advantage of having a consistent GUI
experience in for example the Qt and GTK backends. This is especially
important when embedding a matplotlib figure in external
applications. Then you really don't want configuration GUIs that
appear to pop out of the 90s when clicking on the some of the toolbar
buttons. So I think you'd do yourself a big disservice by removing
the Qt specific improvements and discourage improvements in the GTK
backend.

First, I don't see any improvement in the Qt4 tool; it is less
functional, not more functional. But that is a topic for another
venue.(Apart from the rather baffling sluggishness on my system, your
gtk3 tool is almost as functional as the standard one.)

Second, for me the main advantage of having multiple backends is to
ensure that there is at least one that actually works on any given
system. The secondary advantage is that it enables people to customize
and embed mpl in a gui system of their choice. Again, though, I put a
premium on actual functionality over consistency of experience.

I would like to see greater ease of customization; ideally, it would be
extremely easy for you to substitute your own set of buttons and widgets
in the toolbar, using the same code for any backend. I would prefer to
see an absolute minimum of divergence among the backends, with as much
as possible always factored out into a common base.

I don't mean to discourage improvements in the backends; the question is
one of what constitutes an improvement. I expect a range of opinions,
and mine may be out on one end of the distribution.

Also, I think the red line in the generic GUI that marks the old
settings is nice, but quite marginal to the function of the subplot
configuration window, and its function is in some sense duplicated by
the reset button.

Not at all. There is a difference between having reference points when
making an adjustment, and being able to (or having to) reset everything
to an initial state. I had nothing to do with the present design, but I
think it is a good one.

As for the sluggishness, I have not noticed that it is any more
sluggish than the generic configuration window on my system, but this
could probably be improved on.

The sluggishness is very pronounced on my system, which at the present
is Ubuntu 12.04 running under Vmware on a new Macbook. I don't know what
weird interaction could be making the responsiveness of your gtk3 tool
so poor on this system; I certainly was not expecting it, and haven't
seen anything like it in other gui tools and operations. It is as if
only a few events per second are being processed, and the rest are being
dropped. It is not a general feature of the gtk3 backend on my system.

@WeatherGod
Member

Just as a data point, I met with the OP author at the scipy sprints and discussed with him his idea. Personally, I had never used the QT4Agg backend enough to have noticed that there was a different subplot adjust tool for that backend. That tool has a bunch of additional features that are interesting (including a color-picker) and allows for modifying various other plot properties. In this way, it is more feature-ful than the default tool. Furthermore, the default tool is -- face it -- butt ugly.

That being said, I did point out a few things that were missing in the QT4Agg's tool that was in the basic tool, plus we noticed a few bugs with QT4Agg's tool. There were a few other things I didn't quite like about it and preferred in the default tool.

I commend the effort to bring gtk3 features to the gtk3agg backend, but I think the effort would be better placed in refactoring QT4Agg's tool to bring more of its features over to the default tool in a GUI-agnostic manner so that all backends can have its features. In addition, efforts can be made to create more base widgets that the user would create, but then the specific backend would substitute their native widget, much like how we do right now with Figure and Canvas objects.

@jrjohansson
Contributor

Rather than putting development effort in having matplotlib roll it's own widget set, I think it would be wiser to create some design guidelines for the GUI features and then using the proven and well established GUI toolkits to implement it. With the matplotlibs own widget toolkit there is only so much you can do, and to extend this cross-platform widget collection seems outside the scope of matplotlib (especially since there already is an abundance of good GUI toolkits).

If you only want to keep the GUI features in the matplotlib's figure window to a bare minumum, taking a least common denominator approach, then it might make sense to stick with matplotlib's own widget sets (althougth this will result in an old-fashioned looking GUI). But on the other hand, if you are interested developing the GUI features in the figure window to something more useful in the future (such as the line-property editing window in the Qt backend), then allowing some extended features in the backends using full-featured widget sets sounds like a better idea to me. This would not minimize the divergence across the backends but could lead to better a matplotlib GUI experience.

@mdboom
Member
mdboom commented Aug 3, 2012

Using something like the approach in Enthought's pyface comes to mind.

http://code.enthought.com/projects/traits_ui/

It allows writing GUI's in a non-toolkit-specific way. Being complete with something like that is a lot of work, but if we can limit it to a particular set of the most important widgets and simple layouts it may be a feasible approach.

As an aside, I have long thought that the toolbar code in the backends could be refactored so that the set of buttons is defined in a single place each backend uses that list to build the toolbar dynamically using native GUI calls.

EDIT: Of course, @pelson addressed this toolbar issue recently.

@jrjohansson
Contributor

I'm closing this pull request since there seems to be very little interest in changes directly to the gtk3 backend. But thanks a lot for the feedback all of you.

@jrjohansson jrjohansson closed this Aug 8, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment