Can we hold off on doing WX?@DietmarSchwertberger is interested in keeping it up.

WX or WXAgg (which was not deprecated before)?

OK, I restoredbackend_wx.py for now as it's imported inbackend_wxagg.py, so we still need it at least partially. I'll leave it to@DietmarSchwertberger to determine whether to remove anything from there.

There's one examplelineprops_dialog_gtk_sgskip.py which usesDialogLineprops from the GTK2 backend, but this is not implemented in GTK3. I'm not sure whether this dialog should be implemented for GTK3 as well or the example deleted?

Thanks. I would be fine with a deprecation message for 3.0 for backend_wx..
By then, things should be decided.

The WX renderer was alreadydeprecated in 2.0, but not WXAgg's. However,backend_wxagg.py usesbackend_wx.py. It doesn't look like the renderer is imported, so maybe only the renderer needs to be removed?

Removing just the WX renderer would makebackend_wx.py unusable on it's own, even though it could be imported.
Before 3.0 I would like to try whether the WX renderer can be used for rendering to wx.MetaFileDCs for creating EMF/WMF files. If that's not possible, it should be removed then. No matter what the outcome is, the WX backends will need restructuring for 3.0.
I would suggest not to do it for 2.2 as the risk for bugs is quite significant due to the tight schedule. (There are currently unmerged bugfix PRs.)

This PRis about 3.0, but the wx changes are reverted in any case.

Sorry, did not see this. I just had in mind that the Wx backend was deprecated for rev. 2 already.
I will take care for restructuring / clean up in time for 3.0.

Fixed comments.

Rebased due to conflicts.

Rebased due to conflicts.

It looks like we want to resolve the conflict by going with the master version, correct?

Partly, we can still drop thisToolbar class that was deprecated (and now removed) in all backends.

Rebased due to conflicts.