Is it a good thing the Travis-CI-build failed on Python 2.7? Afterall this is Python 3 code?

The failure is un-related (and you didn't change anything that falls under the test coverage anyway).

Can you make sure that this gets linked to from the documentation so that people can find it? Would it be worth writing some prose for the documentation?

@tacaswell - Sorry for the question: What format should the documentation have? In which folder should I place it? And where should I insert the link?

We use sphinx to generate the documentation website which uses restructured text. As to where in that folder, I am not sure. From http://matplotlib.org/examples/user_interfaces/mpl_with_glade.html it looks like this new file will get an auto-generated web-page, but the current example has no prose to go with it.

If you are feeling ambitious add a new page it doc/users, if not please build the docs and make sure a page gets generated.

@farzia can you take a look at this?

It will take me a few days to figure out how sphinx and rst files work, but I am intending to make a page in doc/users.

Can you do it in such a way that added prose about embedding in other frame works has an obvious place to go?

I started on the documentation under 'advanced guides'. Can somebody check if the structure checks out? I was thinking that the pages could be separated by framework and in the case of GTK also in the pure-GTK and the GTK-Glade approach (e.g. doc/users/ui_glade.rst). All these pages could have gradually evolving tutorials, from a simple window to a interface with some buttons, plot manipulation, and cursor tracking.

Would anybody like to do Qt, Wx, Tk or any of the other frameworks?
Also: Should we make separate pages for Python 2 bindings, or separate pages for older frameworks like GTK+2.x?

@tacaswell - I'm not sure what you mean. Is that another toolkit? I just included the toolkits that have an example in the example folder. There are a lot of toolkits (most of which I have never heard of). But which ones should we include? (https://en.wikipedia.org/wiki/List_of_widget_toolkits)

Look at the files in /backends for which gui frameworks we support (the front page claims 6, not sure if that is actually true anymore).

This looks like a good start to me. Hopefully this can make it in for 1.4.0, but I don't think that this issue is a blocker.

One of my priorities for 1.5 is to make this whole process simpler ( #2624 ).

I have a question about the backends. I don't have a good grasp on what all the different backends are. Shouldn't this section focus on gui-toolkits and make a separate page for web-toolkits and all those different backends-things?

About the first pictures: Currently I only have a few Ubuntu+GTK screenshots as placeholders. I will try to mix them up a bit. We should try to pool screenshots from different operating systems.

About the hardwrapping: What line length should I wrap to?

I actually think embedding in the web is kind of a natural fit for this section. I have a couple of questions go by related to serving images directly back from either django or gae.

The native osx backend is a first-class desktop gui. If the tools are there to make a figure window, the tools are there to embed plots in any gui window in that framework. I was mostly protesting to it's exclusion from your list of frame works supported.

While I wouldn't want to discourage improvement in the docs, or anything else in mpl, I'm afraid this is getting out of hand and out of proportion. Do we really want all this detail about a peripheral issue in the core mpl docs? Everything that goes into the mpl distribution should be maintained and updated as needed with each release. As it is, the really central docs are woefully incomplete, messy, and in some cases badly outdated. (At the moment I am trying to fix some such basic problems in the FAQ.)
I think this glade integration tutorial really belongs in a cookbook or wiki, not in the core mpl docs. Maybe this should be moved over to http://wiki.scipy.org/Cookbook/Matplotlib?

@tacaswell - I have nothing against including web-interfaces. Will the structure still work with web interfaces included: docs --> user guides --> advanced guide --> user interfaces --> (...)? Or will people be confused finding web-stuff under UI?

Can you make the macosx and django pages? I thought of doing wxWidgets or Qt next. But it will take me some time to learn how to use those toolkits.

@efiring - I agree that it might overload the documentation. Although the user interface examples that go without any text might be confusing to a lot of new programmes, such as myself.

Scipy seems to suffer under a lot of maintenance difficulties too (last update: 2013-08-17). Putting the tutorials there look fine, but I wonder if anyone will find them?

It means exactly what it says, although stash might not be the right action
here. Essentially, you have changes that have yet to be dealt with.
Stashing is one way to deal with it (see git stash --help for more
information). However, only you know what sort of changes are at issue here
(do a git status), and whether these are accidental changes that just need
to be reverted (don't do git revert, it won't do what you might have been
used to in subversion), or if they need to be committed to a branch, or is
a work-in-progress (in which git stash is the proper course of action).

Once you got the unstaged changes taken care of, then go ahead with the
squashing.

Cheers!
Ben Root

On Wed, Jun 25, 2014 at 11:45 AM, Tobias Schönberg <[email protected]

wrote:

@pelson https://github.com/pelson - I still have some trouble with git:

Cannot rebase: You have unstaged changes.
Bitte committen Sie die Änderungen oder benutzen Sie "stash".

Should I use stash instead?

—
Reply to this email directly or view it on GitHub
#3088 (comment)
.

@spiessbuerger - looks like you may have been merging upstream/master into your branch? Doing so messes up your git history (as you can see) and generally, if you need to update the branch point you should rebase.

Luckily in this case it is fairly easy to fix since you are only proposing the addition of two new files.

So, how to fix it? There are plenty of solutions to this, but I would be tempted to simply:

git checkout -b GTK3_example upstream/master

git checkout fd44b8a -- examples/user_interfaces/mpl_with_glade_316.glade examples/user_interfaces/mpl_with_glade_316.py

git add examples/user_interfaces/mpl_with_glade_316.glade examples/user_interfaces/mpl_with_glade_316.py

git commit -m "Added a Glade GTK3 integration example."

# You're using master as the source of the PR, so push this branch there. Alternatively, just open a new PR against this branch.
git push origin GTK3_example:master

@pelson - I think I am doing something very wrong with git. I don't think I will be able to resolve this, as I am also not really sure what is going wrong. Also attempts at getting help online have failed, probably because I can't really articulate the problem well.

Don't fret. Squashing isn't required. It just helps to keep everything nice
and neat. I think I'll try making a new PR containing only the needed
changes you have made.

My first experience with git was a bit of a learning curve, and I did have
to delete my local cloned repositories a few times out of frustration. Feel
free to do so yourself and start anew. It does become clearer how to use
git over time. Just leave your github branches alone for now.

On Fri, Jun 27, 2014 at 9:11 AM, Tobias Schönberg [email protected]
wrote:

@pelson https://github.com/pelson - I think I am doing something very
wrong with git. I don't think I will be able to resolve this, as I am also
not really sure what is going wrong. Also attempts at getting help online
have failed, probably because I can't really articulate the problem well.

—
Reply to this email directly or view it on GitHub
#3088 (comment)
.

Seconding @WeatherGod the git learning curve is an overhanging sheer wall, however once you get used to it it is very powerful.

Closing this in favor of #3160