@keflavich - I've looked at doing something similar in the past, so I'm definitely in favour of this addition.
I wonder if you can come up with a testing strategy for this new Widget? Do you find that the keyboard shortcuts that MPL provides interferes with your ability to type contents into the text box?

I plan to have a good look through this PR in the coming weeks - but I'm hopeful we can squeeze this into v1.3.0.

Thanks for submitting!

@pelson - I'm sure I can come up with some tests.

Yes, MPL shortcuts directly interfere: the s key specifically brings up a save dialog, which would badly interfere with typing. The others, less so.

Yes, MPL shortcuts directly interfere: the s key specifically brings up a save dialog, which would badly interfere with typing. The others, less so.

@efiring - I know in the past we've talked about removing non-modified (by ctrl) shortcut keys. Is v1.3 the time to do it? @mdboom?

What about this as a middle option?

1. Add "Ctrl+" modifiers for all existing shortcut keys
2. When a text widget is added to a figure, disable all of the non-Ctrl-modified shortcut keys
3. Add a note in the docs that the non-Ctrl shortcut keys are going away in the future

I like that approach. How can this be accomplished? i.e., is there any way to know which connections in the callbacks registry correspond to non-Ctrl-modifier keys? I know how to blindly remove all KeyPress connections, or all connections whose numbers I've tracked, but I'm not sure where the cids are stored for the default mpl connections.

There is a single callback that handles all of the default keys in matplotlib in backend_bases.py:key_press_handler. I had forgotten that loads the keys it uses from the config file, which does somewhat throw a monkey wrench into what I suggested.

We could certainly add Ctrl+ versions of everything to the default rcParams (which live in rcsetup.py, but are duplicated for the user's benefit in matplotlibrc.template) easily enough, but if the user overrode any of those keys in their config file, it will be difficult to do so.

Then, when a TextWidget is added to the canvas, it could set a flag. In key_press_handler, at the top, one would have something like:

if canvas.has_text_widget and not event.key.startswith('ctrl+'):
    return

But all of that is off the top of my head -- we'd have to really try this out, I think, and run it by some users who build applications using these key press callbacks to make sure we're not breaking anything in the process.

On 2013/05/08 7:23 AM, Michael Droettboom wrote:

What about this as a middle option?

1. Add "Ctrl+" modifiers for all existing shortcut keys
2. When a text widget is added to a figure, disable all of the
   non-Ctrl-modified shortcut keys
3. Add a note in the docs that the non-Ctrl shortcut keys are going away
   in the future

That sounds reasonable to me.

This may be fixed in master, but this doesn't work with the macos backend on v1.2.0 due to the FigureCanvasMac not having a copy_from_bbox() method. It is also calling Text.get_window_extents() in init and failing with a RuntimeError "RuntimeError: Cannot get window extent w/o renderer"

Runs great with tkAgg backend, though.

Should the mac backend have a copy_from_bbox method, or is there a better way to achieve the same result? Sorry, I'm out of my depth on this.

This has been a long-running issue, related to blitting. With the way
Cocoa works, the event loop doesn't really allow us to have a copy from
bbox. I am not savvy on the details, and there may be changes in the
future to fix this, but in the immediate future, macosx backend has a bunch
of wontfix issues. While it would be nice if TextWidget not require
copy_from_bbox(), it may be sufficient to merely document that it doesn't
work with macosx backend.

https://gist.github.com/mrterry/5703912

I've done some surgery on your TextBox. I make no promise regarding the quality of my practice : )
https://gist.github.com/mrterry/5703912

This TextBox variant does a few things

• doesn't throw exceptions for macos (but doesn't work, yet)
• removes self.region
• uses a property to delay the creation of the cursor. You need a renderer to get a bbox, but the macos backend doesn't give you a renderer until you render the first frame. I delay creating the cursor until the first click. This makes macos happier.
• Renamed to FloatTextBox since it is only for floating point text.
• Inherits from AxesWidget rather than just Widget.
• Like other mpl.widgets, it uses self.active (via self.ignore(event)) to control whether callbacks are active
• Changed names to things i think are more descriptive.

There is something buggy in the callback twiddling section when using the macos backend. The callbacks seem to be twiddled correctly (it works for TkAgg). keypress() appears to be in the right dictionaries and can be manually executed, but key_press_events just don't trigger it. Any ideas on what the problem might be? It is very close to working.

@mterry want to submit that as a PR on this PR?

This also needs an entry in the CHANGELOG and in whats_new.rst.

I haven't forgotten about this. All the backends ought to accept backspace key_press_events before merging, so I've been banging on that. It should also support rotation.

Sooo this would be a really awesome feature to have...whats the status?

@mrterry What is the status of making sure everything will take backspace?

Note: Whilst we can't do too much integration testing on this, it'd be good to get some unit tests for the TextBox class.

@pelson - are there any unit tests for other widgets we could use as a template/starting point? I don't see any in the tests directory now.

are there any unit tests for other widgets we could use as a template/starting point? I don't see any in the tests directory now.

Afraid not. matplotlib was virtually test free just a few years ago 😒.

Hey, still not merged??? Damn!

Hey, still not merged??? Damn!

😄 - it just needs a few unit tests and an entry in the "what's new" documentation and it will make it into v1.4...

This has issues with unicode literals and py3k

@keflavich Are you going to have time to work on this in the near future?

Unlikely, sorry. I'll readily accept PRs on it, but you can take over
completely (even start a new PR?) if you prefer.

I am to punting this to 1.5 unless someone volunteers to take it over.

Replaced by #6988