[PATCHv3,1/2] Initial TUI mouse support

Message ID 20210603151453.15248-1-ssbssa@yahoo.de
State New
Headers show
Series
  • [PATCHv3,1/2] Initial TUI mouse support
Related show

Commit Message

Philippe Waroquiers via Gdb-patches June 3, 2021, 3:14 p.m.
Implements an overridable tui_win_info::click method whose arguments
are the mouse coordinates inside the specific window, and the mouse
button clicked.

And if the curses implementation supports 5 buttons, the 4th and 5th
buttons are used for scrolling.

2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

	* ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.
	* tui/tui-data.h (struct tui_win_info): Add click function.
	* tui/tui-io.c (tui_prep_terminal): Enable mouse events.
	(tui_deprep_terminal): Disable mouse events.
	(tui_dispatch_ctrl_char): Handle KEY_MOUSE.
	* tui/tui.c (tui_disable): Disable mouse events.
---
v2:
- Added ChangeLog.
v3:
- Use NCURSES_MOUSE_VERSION to check if mouse functions are available.
- Mention possible mouse_button values in click function.
- Remove useless #include "tui/tui-source.h"
- Fix code style issues.
---
 gdb/ser-mingw.c    |  5 +++++
 gdb/tui/tui-data.h |  7 +++++++
 gdb/tui/tui-io.c   | 37 +++++++++++++++++++++++++++++++++++++
 gdb/tui/tui.c      |  4 ++++
 4 files changed, 53 insertions(+)

-- 
2.31.1

Comments

Tom Tromey June 4, 2021, 1:51 p.m. | #1
>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:


Hannes> Implements an overridable tui_win_info::click method whose arguments
Hannes> are the mouse coordinates inside the specific window, and the mouse
Hannes> button clicked.

Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th
Hannes> buttons are used for scrolling.

Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

Hannes> 	* ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.
Hannes> 	* tui/tui-data.h (struct tui_win_info): Add click function.
Hannes> 	* tui/tui-io.c (tui_prep_terminal): Enable mouse events.
Hannes> 	(tui_deprep_terminal): Disable mouse events.
Hannes> 	(tui_dispatch_ctrl_char): Handle KEY_MOUSE.
Hannes> 	* tui/tui.c (tui_disable): Disable mouse events.

Looks good.  Thank you again.

Tom
Philippe Waroquiers via Gdb-patches June 4, 2021, 2:21 p.m. | #2
Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

>

> Hannes> Implements an overridable tui_win_info::click method whose arguments

> Hannes> are the mouse coordinates inside the specific window, and the mouse

> Hannes> button clicked.

>

> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

> Hannes> buttons are used for scrolling.

>

> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

>

> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

> Hannes>     (tui_deprep_terminal): Disable mouse events.

> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

>

> Looks good.  Thank you again.


Pushed both, thanks.


Hannes
Pedro Alves June 4, 2021, 3:20 p.m. | #3
On 2021-06-04 3:21 p.m., Hannes Domani via Gdb-patches wrote:
>  Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> 

>>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

>>

>> Hannes> Implements an overridable tui_win_info::click method whose arguments

>> Hannes> are the mouse coordinates inside the specific window, and the mouse

>> Hannes> button clicked.

>>

>> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

>> Hannes> buttons are used for scrolling.

>>

>> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

>>

>> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

>> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

>> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

>> Hannes>     (tui_deprep_terminal): Disable mouse events.

>> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

>> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

>>

>> Looks good.  Thank you again.

> 

> Pushed both, thanks.

> 


Yay, mouse support finally.  Thank you!

Don't we need a NEWS entry, though?

Pedro Alves
Philippe Waroquiers via Gdb-patches June 4, 2021, 4:06 p.m. | #4
Am Freitag, 4. Juni 2021, 17:20:44 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-04 3:21 p.m., Hannes Domani via Gdb-patches wrote:

>

> >  Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >

> >>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

> >>

> >> Hannes> Implements an overridable tui_win_info::click method whose arguments

> >> Hannes> are the mouse coordinates inside the specific window, and the mouse

> >> Hannes> button clicked.

> >>

> >> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

> >> Hannes> buttons are used for scrolling.

> >>

> >> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

> >>

> >> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

> >> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

> >> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

> >> Hannes>     (tui_deprep_terminal): Disable mouse events.

> >> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

> >> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

> >>

> >> Looks good.  Thank you again.

> >

> > Pushed both, thanks.

>

> >

>

> Yay, mouse support finally.  Thank you!

>

> Don't we need a NEWS entry, though?


I never think of NEWS.

See at the end what I came up with, maybe the phrasing could need some
improvement.


Hannes


From 95c7890b45cbfb80682451962f5e57f3eef95a03 Mon Sep 17 00:00:00 2001
From: Hannes Domani <ssbssa@yahoo.de>

Date: Fri, 4 Jun 2021 17:58:15 +0200
Subject: [PATCH] Mention mouse support in NEWS

gdb/ChangeLog:

2021-06-04  Hannes Domani  <ssbssa@yahoo.de>

    * NEWS: Mention mouse support.
---
 gdb/NEWS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gdb/NEWS b/gdb/NEWS
index ab678acec8b..8c876e71e63 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -75,6 +75,9 @@
   and "-eiex" that allow options (that would normally appear in a
   gdbearlyinit file) to be passed on the command line.
 
+* TUI windows now support mouse actions.  The mouse wheel scrolls the
+  appropriate window, and Python TUI windows can receive mouse click events.
+
 * New commands
 
 set debug event-loop
--
2.15.1.windows.2
Pedro Alves June 4, 2021, 4:23 p.m. | #5
On 2021-06-04 5:06 p.m., Hannes Domani wrote:
>  Am Freitag, 4. Juni 2021, 17:20:44 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:


>>

>> Don't we need a NEWS entry, though?

> 

> I never think of NEWS.

> 

> See at the end what I came up with, maybe the phrasing could need some

> improvement.

> 


> 

> From 95c7890b45cbfb80682451962f5e57f3eef95a03 Mon Sep 17 00:00:00 2001

> From: Hannes Domani <ssbssa@yahoo.de>

> Date: Fri, 4 Jun 2021 17:58:15 +0200

> Subject: [PATCH] Mention mouse support in NEWS

> 

> gdb/ChangeLog:

> 

> 2021-06-04  Hannes Domani  <ssbssa@yahoo.de>

> 

>     * NEWS: Mention mouse support.

> ---

>  gdb/NEWS | 3 +++

>  1 file changed, 3 insertions(+)

> 

> diff --git a/gdb/NEWS b/gdb/NEWS

> index ab678acec8b..8c876e71e63 100644

> --- a/gdb/NEWS

> +++ b/gdb/NEWS

> @@ -75,6 +75,9 @@

>    and "-eiex" that allow options (that would normally appear in a

>    gdbearlyinit file) to be passed on the command line.

>  

> +* TUI windows now support mouse actions.  The mouse wheel scrolls the

> +  appropriate window, and Python TUI windows can receive mouse click events.

> +


I think you should (also or in alternative) mention the Python bits in the "Python API" section.

It would be nice if we had a section in the manual for the TUI mouse too.  I suspect we'll end up
with some settings/knobs to configure mouse support, and that'd be the place to add them.

We can start small, IMO.  How about this?

From: Pedro Alves <pedro@palves.net>

Date: 2021-06-04 17:12:41 +0100

Document TUI mouse support in the manual

gdb/doc/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

	* gdb.texinfo (TUI): <TUI Mouse Support>: New node/section.

---

 gdb/doc/gdb.texinfo |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 90d827a50e7..486df2ec5f4 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -28372,6 +28372,7 @@ enable} or @kbd{C-x C-a}.  @xref{TUI Commands, ,TUI Commands}, and
 * TUI Overview::                TUI overview
 * TUI Keys::                    TUI key bindings
 * TUI Single Key Mode::         TUI single key mode
+* TUI Mouse Support::           TUI mouse support
 * TUI Commands::                TUI-specific commands
 * TUI Configuration::           TUI configuration variables
 @end menu
@@ -28661,6 +28662,13 @@ If @value{GDBN} was built with Readline 8.0 or later, the TUI
 SingleKey keymap will be named @samp{SingleKey}.  This can be used in
 @file{.inputrc} to add additional bindings to this keymap.
 
+@node TUI Mouse Support
+@section TUI Mouse Support
+@cindex TUI mouse support
+
+The TUI supports mouse actions.  You can click on TUI windows to
+select them, and the mouse wheel scrolls the appropriate window.
+
 @node TUI Commands
 @section TUI-specific Commands
 @cindex TUI commands
Pedro Alves June 4, 2021, 4:29 p.m. | #6
On 2021-06-04 4:20 p.m., Pedro Alves wrote:
> On 2021-06-04 3:21 p.m., Hannes Domani via Gdb-patches wrote:

>>  Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

>>

>>>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

>>>

>>> Hannes> Implements an overridable tui_win_info::click method whose arguments

>>> Hannes> are the mouse coordinates inside the specific window, and the mouse

>>> Hannes> button clicked.

>>>

>>> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

>>> Hannes> buttons are used for scrolling.

>>>

>>> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

>>>

>>> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

>>> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

>>> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

>>> Hannes>     (tui_deprep_terminal): Disable mouse events.

>>> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

>>> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

>>>

>>> Looks good.  Thank you again.

>>

>> Pushed both, thanks.

>>

> 

> Yay, mouse support finally.  Thank you!


Unfortunately, now that I try it, it's broken for me.  And it's broken in a very bad way -- I think
this should block the release or be disabled until we figure out what's wrong.  It definitely
makes GDB unusable for me.

The trouble is that now pressing anywhere on the screen with the mouse just results in
weird characters being printed on the command line window (probably uninterpreted control
sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do
that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but
that still leaves the mouse messed up.  See this screenshot:

  https://i.imgur.com/bO7FKDO.png

This was on Ubuntu 20.04.

Pedro Alves
Philippe Waroquiers via Gdb-patches June 4, 2021, 4:48 p.m. | #7
Am Freitag, 4. Juni 2021, 18:29:52 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-04 4:20 p.m., Pedro Alves wrote:

> > On 2021-06-04 3:21 p.m., Hannes Domani via Gdb-patches wrote:

> >>  Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >>

> >>>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

> >>>

> >>> Hannes> Implements an overridable tui_win_info::click method whose arguments

> >>> Hannes> are the mouse coordinates inside the specific window, and the mouse

> >>> Hannes> button clicked.

> >>>

> >>> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

> >>> Hannes> buttons are used for scrolling.

> >>>

> >>> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

> >>>

> >>> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

> >>> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

> >>> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

> >>> Hannes>     (tui_deprep_terminal): Disable mouse events.

> >>> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

> >>> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

> >>>

> >>> Looks good.  Thank you again.

> >>

> >> Pushed both, thanks.

> >>

> >

> > Yay, mouse support finally.  Thank you!

>

> Unfortunately, now that I try it, it's broken for me.  And it's broken in a very bad way -- I think

> this should block the release or be disabled until we figure out what's wrong.  It definitely

> makes GDB unusable for me.

>

> The trouble is that now pressing anywhere on the screen with the mouse just results in

> weird characters being printed on the command line window (probably uninterpreted control

> sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

> that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

> that still leaves the mouse messed up.  See this screenshot:

>

>   https://i.imgur.com/bO7FKDO.png

>

> This was on Ubuntu 20.04.


OK, that's bad.
What's the procedure for this sort or problem? Reverting?

I didn't expect this kind of problem, it works fine for me on a remote Linux
via putty.


Hannes
Joel Brobecker June 4, 2021, 6:05 p.m. | #8
Hi Pedro and Hannes,

Thanks Pedro for having reported this regression. I agree we can't
branch with this sort of issue!

On Fri, Jun 04, 2021 at 04:48:14PM +0000, Hannes Domani wrote:
>  Am Freitag, 4. Juni 2021, 18:29:52 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> 

> > On 2021-06-04 4:20 p.m., Pedro Alves wrote:

> > > On 2021-06-04 3:21 p.m., Hannes Domani via Gdb-patches wrote:

> > >>  Am Freitag, 4. Juni 2021, 15:51:27 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> > >>

> > >>>>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

> > >>>

> > >>> Hannes> Implements an overridable tui_win_info::click method whose arguments

> > >>> Hannes> are the mouse coordinates inside the specific window, and the mouse

> > >>> Hannes> button clicked.

> > >>>

> > >>> Hannes> And if the curses implementation supports 5 buttons, the 4th and 5th

> > >>> Hannes> buttons are used for scrolling.

> > >>>

> > >>> Hannes> 2021-06-03  Hannes Domani  <ssbssa@yahoo.de>

> > >>>

> > >>> Hannes>     * ser-mingw.c (console_select_thread): Handle MOUSE_EVENT.

> > >>> Hannes>     * tui/tui-data.h (struct tui_win_info): Add click function.

> > >>> Hannes>     * tui/tui-io.c (tui_prep_terminal): Enable mouse events.

> > >>> Hannes>     (tui_deprep_terminal): Disable mouse events.

> > >>> Hannes>     (tui_dispatch_ctrl_char): Handle KEY_MOUSE.

> > >>> Hannes>     * tui/tui.c (tui_disable): Disable mouse events.

> > >>>

> > >>> Looks good.  Thank you again.

> > >>

> > >> Pushed both, thanks.

> > >>

> > >

> > > Yay, mouse support finally.  Thank you!

> >

> > Unfortunately, now that I try it, it's broken for me.  And it's broken in a very bad way -- I think

> > this should block the release or be disabled until we figure out what's wrong.  It definitely

> > makes GDB unusable for me.

> >

> > The trouble is that now pressing anywhere on the screen with the mouse just results in

> > weird characters being printed on the command line window (probably uninterpreted control

> > sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

> > that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

> > that still leaves the mouse messed up.  See this screenshot:

> >

> >   https://i.imgur.com/bO7FKDO.png

> >

> > This was on Ubuntu 20.04.

> 

> OK, that's bad.

> What's the procedure for this sort or problem? Reverting?

> 

> I didn't expect this kind of problem, it works fine for me on a remote Linux

> via putty.


If you can reproduce, understand, and fix quickly, we can go with that.
Otherwise, for an issue with this kind of effect, we indeed usually start
by reverting, or at least disabling the code entirely when that's easily
done.

-- 
Joel
Philippe Waroquiers via Gdb-patches June 4, 2021, 6:13 p.m. | #9
On 2021-06-04 12:29 p.m., Pedro Alves wrote:
> The trouble is that now pressing anywhere on the screen with the mouse just results in

> weird characters being printed on the command line window (probably uninterpreted control

> sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

> that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

> that still leaves the mouse messed up.  See this screenshot:

> 

>   https://i.imgur.com/bO7FKDO.png

> 

> This was on Ubuntu 20.04.


Obviously the printing random characters is bad.  But it's possible that
the not being able to select text is normal, as the application (GDB)
now supports mouse events.  In some terminal emulators, you can press
shift while you click to say "I really want to select the display
characters, not send mouse events to the program".

It's the same with other TUI apps for me:

 - tmux (with "set -g mouse on" in ~/.tmux.conf)
 - tig (I don't remember if anything is needed to enable mouse support)
 - weechat (I don't remember if anything is needed to enable mouse
   support)

In some of these programs, mouse support is disabled by default and you
have to use some setting to enable it.  So by default, standard
selection would work.  But if you enable mouse suport, then you have to
use shift+click to select.

Simon
Joel Brobecker June 4, 2021, 6:39 p.m. | #10
> Obviously the printing random characters is bad.  But it's possible that

> the not being able to select text is normal, as the application (GDB)

> now supports mouse events.  In some terminal emulators, you can press

> shift while you click to say "I really want to select the display

> characters, not send mouse events to the program".

> 

> It's the same with other TUI apps for me:

> 

>  - tmux (with "set -g mouse on" in ~/.tmux.conf)

>  - tig (I don't remember if anything is needed to enable mouse support)

>  - weechat (I don't remember if anything is needed to enable mouse

>    support)


FWIW, "vim" behaves like that too.

That being said, if we go that route, we should probably have that
mentioned in the manual and in the NEWS file.

-- 
Joel
Tom Tromey June 4, 2021, 6:46 p.m. | #11
Pedro> The trouble is that now pressing anywhere on the screen with the
Pedro> mouse just results in weird characters being printed on the
Pedro> command line window (probably uninterpreted control sequences).

I tried it here, and it worked fine for me.

I couldn't select text, but I didn't see any control characters.

Pedro> This was on Ubuntu 20.04.

I'm on Fedora 32.

I wonder if there's something weird about the Ubuntu build of ncurses.
Or the Fedora one.

Tom
Philippe Waroquiers via Gdb-patches June 4, 2021, 6:57 p.m. | #12
> Date: Fri, 4 Jun 2021 16:06:03 +0000 (UTC)

> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>

> 

> diff --git a/gdb/NEWS b/gdb/NEWS

> index ab678acec8b..8c876e71e63 100644

> --- a/gdb/NEWS

> +++ b/gdb/NEWS

> @@ -75,6 +75,9 @@

>    and "-eiex" that allow options (that would normally appear in a

>    gdbearlyinit file) to be passed on the command line.

>  

> +* TUI windows now support mouse actions.  The mouse wheel scrolls the

> +  appropriate window, and Python TUI windows can receive mouse click events.

> +


Thanks.  The text is okay, but maybe we should qualify it by saying
something like "if the curses library supports the mouse".
Philippe Waroquiers via Gdb-patches June 4, 2021, 6:59 p.m. | #13
> From: Pedro Alves <pedro@palves.net>

> Date: Fri, 4 Jun 2021 17:23:50 +0100

> 

> +@node TUI Mouse Support

> +@section TUI Mouse Support

> +@cindex TUI mouse support

> +

> +The TUI supports mouse actions.  You can click on TUI windows to

> +select them, and the mouse wheel scrolls the appropriate window.


Thanks.  Like in NEWS, I think this should be qualified by mouse
support availability in the curses library in use.
Pedro Alves June 4, 2021, 8:31 p.m. | #14
On 2021-06-04 7:13 p.m., Simon Marchi wrote:
> On 2021-06-04 12:29 p.m., Pedro Alves wrote:

>> The trouble is that now pressing anywhere on the screen with the mouse just results in

>> weird characters being printed on the command line window (probably uninterpreted control

>> sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

>> that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

>> that still leaves the mouse messed up.  See this screenshot:

>>

>>   https://i.imgur.com/bO7FKDO.png

>>

>> This was on Ubuntu 20.04.

> 

> Obviously the printing random characters is bad.  But it's possible that

> the not being able to select text is normal, as the application (GDB)

> now supports mouse events.  In some terminal emulators, you can press

> shift while you click to say "I really want to select the display

> characters, not send mouse events to the program".


I'm on my Fedora 32 laptop currently, and here it works fine.

You can select text without having press any key.  It basically works
as before.  I suppose we could teach GDB to be smarter about text selection -- like,
if you select several lines of source code in the TUI source window, ideally
we'd select just the source code, instead of the source code plus the window
borders, etc.  Then we would have an "escape" key to be able to disable special
mouse mode so you can select text in the whole terminal using regular text
terminal selection, and I suppose that that's what "shift" does in those programs
you mention.

I'm surprised to find that clicking a window doesn't set focus on it, though.
Is that supposed to work?

Pedro Alves

> 

> It's the same with other TUI apps for me:

> 

>  - tmux (with "set -g mouse on" in ~/.tmux.conf)

>  - tig (I don't remember if anything is needed to enable mouse support)

>  - weechat (I don't remember if anything is needed to enable mouse

>    support)

> 

> In some of these programs, mouse support is disabled by default and you

> have to use some setting to enable it.  So by default, standard

> selection would work.  But if you enable mouse suport, then you have to

> use shift+click to select.

> 

> Simon

>
Pedro Alves June 4, 2021, 8:43 p.m. | #15
On 2021-06-04 9:31 p.m., Pedro Alves wrote:
> On 2021-06-04 7:13 p.m., Simon Marchi wrote:

>> On 2021-06-04 12:29 p.m., Pedro Alves wrote:

>>> The trouble is that now pressing anywhere on the screen with the mouse just results in

>>> weird characters being printed on the command line window (probably uninterpreted control

>>> sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

>>> that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

>>> that still leaves the mouse messed up.  See this screenshot:

>>>

>>>   https://i.imgur.com/bO7FKDO.png

>>>

>>> This was on Ubuntu 20.04.

>>

>> Obviously the printing random characters is bad.  But it's possible that

>> the not being able to select text is normal, as the application (GDB)

>> now supports mouse events.  In some terminal emulators, you can press

>> shift while you click to say "I really want to select the display

>> characters, not send mouse events to the program".

> 

> I'm on my Fedora 32 laptop currently, and here it works fine.

> 

> You can select text without having press any key.  It basically works

> as before.  


Huh, now that I pull+rebuild GDB, I need to press shift to select.  And now I'm not
sure what I tested anymore.  I could definitely scroll the TUI windows before
this latest rebuild.  Mistyfying...

Pedro Alves

> I suppose we could teach GDB to be smarter about text selection -- like,

> if you select several lines of source code in the TUI source window, ideally

> we'd select just the source code, instead of the source code plus the window

> borders, etc.  Then we would have an "escape" key to be able to disable special

> mouse mode so you can select text in the whole terminal using regular text

> terminal selection, and I suppose that that's what "shift" does in those programs

> you mention.

> 

> I'm surprised to find that clicking a window doesn't set focus on it, though.

> Is that supposed to work?

> 

> Pedro Alves

> 

>>

>> It's the same with other TUI apps for me:

>>

>>  - tmux (with "set -g mouse on" in ~/.tmux.conf)

>>  - tig (I don't remember if anything is needed to enable mouse support)

>>  - weechat (I don't remember if anything is needed to enable mouse

>>    support)

>>

>> In some of these programs, mouse support is disabled by default and you

>> have to use some setting to enable it.  So by default, standard

>> selection would work.  But if you enable mouse suport, then you have to

>> use shift+click to select.

>>

>> Simon

>>

>
Pedro Alves June 4, 2021, 8:54 p.m. | #16
On 2021-06-04 7:46 p.m., Tom Tromey wrote:
> Pedro> The trouble is that now pressing anywhere on the screen with the

> Pedro> mouse just results in weird characters being printed on the

> Pedro> command line window (probably uninterpreted control sequences).

> 

> I tried it here, and it worked fine for me.

> 

> I couldn't select text, but I didn't see any control characters.

> 

> Pedro> This was on Ubuntu 20.04.

> 

> I'm on Fedora 32.


I'm currently on Fedora 32 too, and while it works here too, I just found a way to reproduce a similar
problem that I'm seeing on the Ubuntu machine (which I currently don't have access to).  (Though
on Ubuntu it was worse.)

Try this:

$ ./gdb ./gdb
...
(gdb) start
c-x a
scroll up and down with mouse to check that it works ok.
c-x o # select command window
scroll up and down with mouse, and see escape codes being printed on the command window

If I "c-x o" again to select the source window, then scrolling works correctly again.

If I "c-x o" again to select the command window, then scrolling and clicking with the mouse 
prints more bad characters.  Like these:

(top-gdb) 64;40;21M64;40;21M65;40;21M65;40;21M64;40;21M64;40;21M64;40;21M65;40;21M0;67;32M0;67;32m0;64;18M0;64;18m0;64;18M0;64;18m2;64;18M2;64;18m0;64;18M0;64;18M0;64;18M0
;64;18m1;64;18M1;64;18m64;64;18M64;64;18M1;64;19M1;64;19m1;64;19M1;64;19m2;64;19M2;64;19m0;64;19M0;64;19m0;51;13M0;51;13m0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0
;1;27M0;1;27M0;1;27m

Pedro Alves

> 

> I wonder if there's something weird about the Ubuntu build of ncurses.

> Or the Fedora one.

> 

> Tom

>
Philippe Waroquiers via Gdb-patches June 4, 2021, 9:15 p.m. | #17
Am Freitag, 4. Juni 2021, 22:31:31 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-04 7:13 p.m., Simon Marchi wrote:

> > On 2021-06-04 12:29 p.m., Pedro Alves wrote:

> >> The trouble is that now pressing anywhere on the screen with the mouse just results in

> >> weird characters being printed on the command line window (probably uninterpreted control

> >> sequences).  That even prevents me from selecting text (something I do often) -- I wanted to do

> >> that to paste the results here.  I even tried suspending GDB with ^Z to then copy the text, but

> >> that still leaves the mouse messed up.  See this screenshot:

> >>

> >>  https://i.imgur.com/bO7FKDO.png

> >>

> >> This was on Ubuntu 20.04.

> >

> > Obviously the printing random characters is bad.  But it's possible that

> > the not being able to select text is normal, as the application (GDB)

> > now supports mouse events.  In some terminal emulators, you can press

> > shift while you click to say "I really want to select the display

> > characters, not send mouse events to the program".

>

> I'm on my Fedora 32 laptop currently, and here it works fine.

>

> You can select text without having press any key.  It basically works

> as before.  I suppose we could teach GDB to be smarter about text selection -- like,

> if you select several lines of source code in the TUI source window, ideally

> we'd select just the source code, instead of the source code plus the window

> borders, etc.  Then we would have an "escape" key to be able to disable special

> mouse mode so you can select text in the whole terminal using regular text

> terminal selection, and I suppose that that's what "shift" does in those programs

> you mention.

>

> I'm surprised to find that clicking a window doesn't set focus on it, though.

> Is that supposed to work?


No, that's not implemented.
I was thinking about it, but wasn't sure what people prefer.
So I just kept the simpler variant.


Hannes
Pedro Alves June 4, 2021, 10:19 p.m. | #18
On 2021-06-04 10:15 p.m., Hannes Domani wrote:
>  Am Freitag, 4. Juni 2021, 22:31:31 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:


>> I'm surprised to find that clicking a window doesn't set focus on it, though.

>> Is that supposed to work?

> 

> No, that's not implemented.

> I was thinking about it, but wasn't sure what people prefer.

> So I just kept the simpler variant.


I would prefer being able to click to select.  Clicking things and nothing happening
seems like a waste of actions.  :-)  If different people prefer different things,
that calls for a setting/option.  Maybe some people might prefer focus-follow-mouse?  (not me.)

Pedro Alves
Pedro Alves June 4, 2021, 11:48 p.m. | #19
On 2021-06-04 9:54 p.m., Pedro Alves wrote:
> On 2021-06-04 7:46 p.m., Tom Tromey wrote:

>> Pedro> The trouble is that now pressing anywhere on the screen with the

>> Pedro> mouse just results in weird characters being printed on the

>> Pedro> command line window (probably uninterpreted control sequences).

>>

>> I tried it here, and it worked fine for me.

>>

>> I couldn't select text, but I didn't see any control characters.

>>

>> Pedro> This was on Ubuntu 20.04.

>>

>> I'm on Fedora 32.

> 

> I'm currently on Fedora 32 too, and while it works here too, I just found a way to reproduce a similar

> problem that I'm seeing on the Ubuntu machine (which I currently don't have access to).  (Though

> on Ubuntu it was worse.)

> 

> Try this:

> 

> $ ./gdb ./gdb

> ...

> (gdb) start

> c-x a

> scroll up and down with mouse to check that it works ok.

> c-x o # select command window

> scroll up and down with mouse, and see escape codes being printed on the command window

> 

> If I "c-x o" again to select the source window, then scrolling works correctly again.

> 

> If I "c-x o" again to select the command window, then scrolling and clicking with the mouse 

> prints more bad characters.  Like these:

> 

> (top-gdb) 64;40;21M64;40;21M65;40;21M65;40;21M64;40;21M64;40;21M64;40;21M65;40;21M0;67;32M0;67;32m0;64;18M0;64;18m0;64;18M0;64;18m2;64;18M2;64;18m0;64;18M0;64;18M0;64;18M0

> ;64;18m1;64;18M1;64;18m64;64;18M64;64;18M1;64;19M1;64;19m1;64;19M1;64;19m2;64;19M2;64;19m0;64;19M0;64;19m0;51;13M0;51;13m0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0

> ;1;27M0;1;27M0;1;27m


I have access to the Ubuntu machine again now.  The symptom I see now the same as on Fedora -- I can scroll
the source window, when when I focus on the command window, I start seeing all the badness.  I don't think
I focused on the command window earlier when I first reported it, maybe there's some other way to trigger
it, but can't say for sure.  So it is looking like this isn't OS specific afterall.

Sorry for the spotty reporting.  Hopefully the reproducer helps identifying the issue.

Pedro Alves
Philippe Waroquiers via Gdb-patches June 5, 2021, 2:40 p.m. | #20
Am Samstag, 5. Juni 2021, 01:48:38 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> On 2021-06-04 9:54 p.m., Pedro Alves wrote:

> > On 2021-06-04 7:46 p.m., Tom Tromey wrote:

> >> Pedro> The trouble is that now pressing anywhere on the screen with the

> >> Pedro> mouse just results in weird characters being printed on the

> >> Pedro> command line window (probably uninterpreted control sequences).

> >>

> >> I tried it here, and it worked fine for me.

> >>

> >> I couldn't select text, but I didn't see any control characters.

> >>

> >> Pedro> This was on Ubuntu 20.04.

> >>

> >> I'm on Fedora 32.

> >

> > I'm currently on Fedora 32 too, and while it works here too, I just found a way to reproduce a similar

> > problem that I'm seeing on the Ubuntu machine (which I currently don't have access to).  (Though

> > on Ubuntu it was worse.)

> >

> > Try this:

> >

> > $ ./gdb ./gdb

> > ...

> > (gdb) start

> > c-x a

> > scroll up and down with mouse to check that it works ok.

> > c-x o # select command window

> > scroll up and down with mouse, and see escape codes being printed on the command window

> >

> > If I "c-x o" again to select the source window, then scrolling works correctly again.

> >

> > If I "c-x o" again to select the command window, then scrolling and clicking with the mouse

> > prints more bad characters.  Like these:

> >

> > (top-gdb) 64;40;21M64;40;21M65;40;21M65;40;21M64;40;21M64;40;21M64;40;21M65;40;21M0;67;32M0;67;32m0;64;18M0;64;18m0;64;18M0;64;18m2;64;18M2;64;18m0;64;18M0;64;18M0;64;18M0

> > ;64;18m1;64;18M1;64;18m64;64;18M64;64;18M1;64;19M1;64;19m1;64;19M1;64;19m2;64;19M2;64;19m0;64;19M0;64;19m0;51;13M0;51;13m0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0;1;27M0

> > ;1;27M0;1;27M0;1;27m

>

> I have access to the Ubuntu machine again now.  The symptom I see now the same as on Fedora -- I can scroll

> the source window, when when I focus on the command window, I start seeing all the badness.  I don't think

> I focused on the command window earlier when I first reported it, maybe there's some other way to trigger

> it, but can't say for sure.  So it is looking like this isn't OS specific afterall.

>

> Sorry for the spotty reporting.  Hopefully the reproducer helps identifying the issue.


On Windows I can mostly reproduce this, when the command window has focus,
mouse scrolling just doesn't work.
I don't see any escape sequences, because the Windows console works different.
I probably wouldn't have noticed this for a long time, because I never set
the focus to the command window (I always wondered why this is possible at all).

Anyways, I think this happens because when the command window gets focus,
we disable the curses keypad.
As the docu says:

  The keypad option enables the keypad of the user's terminal. If enabled
  (bf is TRUE), the user can press a function key (such as an arrow key) and
  wgetch returns a single value representing the function key, as in KEY_LEFT.
  If disabled (bf is FALSE), curses does not treat function keys specially
  and the program has to interpret the escape sequences itself.

I imagine the same is true for mouse escape sequences.
So I would just disable the mouse when the command window has focus, but
what do you think?


Hannes
Philippe Waroquiers via Gdb-patches June 6, 2021, 5:46 a.m. | #21
> Date: Sat, 5 Jun 2021 14:40:17 +0000 (UTC)

> From: Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>

> Cc: Joel Brobecker <brobecker@adacore.com>,

>  Hannes Domani via Gdb-patches <gdb-patches@sourceware.org>

> 

> So I would just disable the mouse when the command window has focus, but

> what do you think?


If we end up doing that (and I have no objections, FWIW), let's
reflect that in the manual.

Thanks.
Tom Tromey June 10, 2021, 6:44 p.m. | #22
>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:


Pedro> I suppose we could teach GDB to be smarter about text selection -- like,
Pedro> if you select several lines of source code in the TUI source window, ideally
Pedro> we'd select just the source code, instead of the source code plus the window
Pedro> borders, etc.

Is it possible to implement this?  I looked a little but didn't see a
way to set the selection.  Hopefully I'm just looking for the wrong
keywords...

Tom
Tom Tromey June 10, 2021, 6:46 p.m. | #23
>>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:


Hannes> I imagine the same is true for mouse escape sequences.
Hannes> So I would just disable the mouse when the command window has focus, but
Hannes> what do you think?

I think this is a good fallback to have, but it would be better if we
could make it really work somehow.  The problem with doing this is that
if the command window has focus, then things like clicking in the source
to set a breakpoint will not work.

Tom
Philippe Waroquiers via Gdb-patches June 11, 2021, 11:02 a.m. | #24
Am Donnerstag, 10. Juni 2021, 20:47:01 MESZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:

>

> Hannes> I imagine the same is true for mouse escape sequences.

> Hannes> So I would just disable the mouse when the command window has focus, but

> Hannes> what do you think?

>

> I think this is a good fallback to have, but it would be better if we

> could make it really work somehow.  The problem with doing this is that

> if the command window has focus, then things like clicking in the source

> to set a breakpoint will not work.


That would probably mean that keypad also has to be enabled when the
command window has focus.
I did a short test where I tried this, but then gdb crashed somewhere in
readline, and I stopped there, because I didn't want to debug readline code.


Hannes
Pedro Alves June 13, 2021, 5:26 p.m. | #25
On 2021-06-10 7:44 p.m., Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

> 

> Pedro> I suppose we could teach GDB to be smarter about text selection -- like,

> Pedro> if you select several lines of source code in the TUI source window, ideally

> Pedro> we'd select just the source code, instead of the source code plus the window

> Pedro> borders, etc.

> 

> Is it possible to implement this?  I looked a little but didn't see a

> way to set the selection.  Hopefully I'm just looking for the wrong

> keywords...


Sorry, I just assumed it was possible, but I don't really know.

Pedro Alves
Tom Tromey June 18, 2021, 3:01 p.m. | #26
>> Is it possible to implement this?  I looked a little but didn't see a

>> way to set the selection.  Hopefully I'm just looking for the wrong

>> keywords...


Pedro> Sorry, I just assumed it was possible, but I don't really know.

By coincidence I learned that this is indeed possible.
It's called "OSC 52":

https://www.reddit.com/r/vim/comments/k1ydpn/a_guide_on_how_to_copy_text_from_anywhere/

And if you search for "emacs" here, there's some information as well:

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

Tom
Pedro Alves June 18, 2021, 5:42 p.m. | #27
On 2021-06-18 4:01 p.m., Tom Tromey wrote:
>>> Is it possible to implement this?  I looked a little but didn't see a

>>> way to set the selection.  Hopefully I'm just looking for the wrong

>>> keywords...

> 

> Pedro> Sorry, I just assumed it was possible, but I don't really know.

> 

> By coincidence I learned that this is indeed possible.

> It's called "OSC 52":

> 

> https://www.reddit.com/r/vim/comments/k1ydpn/a_guide_on_how_to_copy_text_from_anywhere/

> 

> And if you search for "emacs" here, there's some information as well:

> 

> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

> 


That's awesome!  Great find.

Patch

diff --git a/gdb/ser-mingw.c b/gdb/ser-mingw.c
index 043bb50b577..2bad51310f6 100644
--- a/gdb/ser-mingw.c
+++ b/gdb/ser-mingw.c
@@ -599,6 +599,11 @@  console_select_thread (void *arg)
 		  break;
 		}
 	    }
+	  else if (record.EventType == MOUSE_EVENT)
+	    {
+	      SetEvent (state->read_event);
+	      break;
+	    }
 
 	  /* Otherwise discard it and wait again.  */
 	  ReadConsoleInput (h, &record, 1, &n_records);
diff --git a/gdb/tui/tui-data.h b/gdb/tui/tui-data.h
index b4d788dd0a4..9fa39fa58f3 100644
--- a/gdb/tui/tui-data.h
+++ b/gdb/tui/tui-data.h
@@ -137,6 +137,13 @@  struct tui_win_info
     return true;
   }
 
+  /* Called for each mouse click inside this window.  Coordinates MOUSE_X
+     and MOUSE_Y are 0-based relative to the window, and MOUSE_BUTTON can
+     be 1 (left), 2 (middle), or 3 (right).  */
+  virtual void click (int mouse_x, int mouse_y, int mouse_button)
+  {
+  }
+
   void check_and_display_highlight_if_needed ();
 
   /* Window handle.  */
diff --git a/gdb/tui/tui-io.c b/gdb/tui/tui-io.c
index a2be4d4353e..7df0e2f1bd3 100644
--- a/gdb/tui/tui-io.c
+++ b/gdb/tui/tui-io.c
@@ -639,6 +639,9 @@  tui_redisplay_readline (void)
 static void
 tui_prep_terminal (int notused1)
 {
+#ifdef NCURSES_MOUSE_VERSION
+  mousemask (ALL_MOUSE_EVENTS, NULL);
+#endif
 }
 
 /* Readline callback to restore the terminal.  It is called once each
@@ -646,6 +649,9 @@  tui_prep_terminal (int notused1)
 static void
 tui_deprep_terminal (void)
 {
+#ifdef NCURSES_MOUSE_VERSION
+  mousemask (0, NULL);
+#endif
 }
 
 #ifdef TUI_USE_PIPE_FOR_READLINE
@@ -978,6 +984,37 @@  tui_dispatch_ctrl_char (unsigned int ch)
     case KEY_LEFT:
       win_info->right_scroll (1);
       break;
+#ifdef NCURSES_MOUSE_VERSION
+    case KEY_MOUSE:
+	{
+	  MEVENT mev;
+	  if (getmouse (&mev) != OK)
+	    break;
+
+	  for (tui_win_info *wi : all_tui_windows ())
+	    if (mev.x > wi->x && mev.x < wi->x + wi->width - 1
+		&& mev.y > wi->y && mev.y < wi->y + wi->height - 1)
+	      {
+		if ((mev.bstate & BUTTON1_CLICKED) != 0
+		    || (mev.bstate & BUTTON2_CLICKED) != 0
+		    || (mev.bstate & BUTTON3_CLICKED) != 0)
+		  {
+		    int button = (mev.bstate & BUTTON1_CLICKED) != 0 ? 1
+		      :         ((mev.bstate & BUTTON2_CLICKED) != 0 ? 2
+				 : 3);
+		    wi->click (mev.x - wi->x - 1, mev.y - wi->y - 1, button);
+		  }
+#ifdef BUTTON5_PRESSED
+		else if ((mev.bstate & BUTTON4_PRESSED) != 0)
+		  wi->backward_scroll (3);
+		else if ((mev.bstate & BUTTON5_PRESSED) != 0)
+		  wi->forward_scroll (3);
+#endif
+		break;
+	      }
+	}
+      break;
+#endif
     case '\f':
       break;
     default:
diff --git a/gdb/tui/tui.c b/gdb/tui/tui.c
index af92b2a8042..529fc62c9ac 100644
--- a/gdb/tui/tui.c
+++ b/gdb/tui/tui.c
@@ -508,6 +508,10 @@  tui_disable (void)
   rl_startup_hook = 0;
   rl_already_prompted = 0;
 
+#ifdef NCURSES_MOUSE_VERSION
+  mousemask (0, NULL);
+#endif
+
   /* Leave curses and restore previous gdb terminal setting.  */
   endwin ();