pudb
pudb copied to clipboard
inducer
Mouse support
This is based on https://github.com/inducer/pudb/pull/15. I removed commits that were unrelated to mouse support.
This still has some TODOs, so don't merge yet, but feel free to test.
One main TODO here: This has supposed double click support, but it is based on the urwid main loop object. It doesn't work with the PuDB loop, because it doesn't keep track of that many keys. If you have a suggestion on how to make it work, that would be great. Otherwise, I'm going to delete it.
Second main TODO: I'm not married to any of the keybindings used here (most were taken from @livibetter's PR). I personally can't even type Ctrl-mouse or Meta-mouse in my terminal, and right-click only works if I disable the context menu in my terminal (which I don't particularly want to do). So suggestions on keybindings are very welcome.
I think I can live without double click support for now.
I wonder if we should add "Add"/"Delete" buttons in a couple places to provide more things to click on.
I also wonder if "press" or "release" is the correct event to respond to. Buttons typically respond to "release". Many UI toolkits also emit a separate "click" event.
Yeah, I'll remove the double click.
I didn't think about click vs. release. The selection (which is built into urwid) does the right thing in that when you click on a line and move the mouse, it moves with the mouse until you release. The mouse 2 items should definitely work on release, though.
Just checked and the trivial thing, replacing, for instance
self.bp_list.listen_mouse_event("mouse press", 3, enable_disable_breakpoint)
with
self.bp_list.listen_mouse_event("mouse release", 3, enable_disable_breakpoint)
doesn't work. http://urwid.org/manual/userinput.html#mouse-release-events says that mouse release events often don't have button information. I haven't dug into this any further yet.
So it doesn't seem that binding to release events is wise, realistically speaking. Fine by me--in that case we'll have to live with "press" events. Although that does explain why using a mouse in a terminal has always felt a bit weird. :)
Judging by the non-working double click handler that was added by @livibetter, this is something that could likely be done in a not too difficult way if we used the urwid event loop, as it (apparently) keeps track of a history of mouse events. It might be possible to mock up something here as well, by keeping track of mouse events (but I'm unclear how difficult it would be). I may also contact the urwid guys to see if they have any suggestions here.
I'm not certain that would be robust in the face of bizarreness, such as PRESS 1, PRESS 2, RELEASE ...