-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mouse support #186
base: main
Are you sure you want to change the base?
Mouse support #186
Conversation
The mouse events can still be considered a "key", and this makes the API easier to understand.
The default is enabled.
This makes, for instance, right clicking on a line set the break point on that line, not the currently selected line.
Except ones that don't "scroll", like the var stringifier cycling.
Double click doesn't actually work (it will likely be removed, as it requires a real event loop). There's no reason to select a stack frame without entering it, since no other actions exist on stack frames.
Unfortunately, there's no UI for this yet, unless you examine the breakpoint.
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 ... |
This is based on #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.