bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: read mouse position beyond column 256 ?


From: Patrick
Subject: Re: read mouse position beyond column 256 ?
Date: Thu, 02 Oct 2014 08:06:27 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

Hi Egmont

This is really helpful.

So then it's not about ncurses data structures, it's about the protocols it's defaulting to read....

I will need to do a lot of reading to be helpful here.

Could anyone help me put a reading list together? gpm might be one topic but what is the newer protocol?

I assume that reading up on termcap and terminfo would be good.

The more I think about this, the more I want to do this. However I don't want to make promises I can't keep, I do have two disabled and 1 sick people to attend to, I have very limited time, it could take months.

-Pat





On 14-10-02 04:27 AM, Egmont Koblinger wrote:
On Thu, Oct 2, 2014 at 4:51 AM, Patrick <address@hidden> wrote:

I was thinking that if it was not too hard I could to modify ncurses to read beyond row-col 223. Is this code in lib_mouse ? I don't understand the code but it's just over 1500 lines, so it's in the range of possibility for me. Is the ncurses codebase very intertwined or is it fairly easy to understand files like this without understanding the whole codebase?

I don't know the answer to this, sorry, I haven't looked at ncurses's mouse handling.

For graphical terminal emulators: Look for a piece of code where \e[M is recognized and this is followed by reading 3 bytes, and from two of those bytes 32 or 33 is subtracted.

For Linux console + gpm: I don't know.

Would this pretty much be a case of changing a short to an int and than compensating for the change elsewhere ?

Definitely no.

struct MEVENT already has 'int' for the buttons.  So the API/ABI between ncurses and an ncurses-based app already supports practically any coordinates, you shouldn't touch this.

The limitation is not here, the limitation is in the legacy mouse protocol, i.e. in the communication between the terminal emulator and the application (not necessarily an ncurses-based application).

For graphical emulators: You need to make sure that wherever mouse is enabled (\e[?9h or \e[?1000h - \e[?1003h is printed) ncurses also prints \e[?1006h to enable the extension (and correspondingly disables it when disables mouse).  This will switch your graphical terminal to the new protocol.  You can verify this manually:

cat
click with mouse -> nothing
^C
echo -ne '\e[?1002h'
cat
click with mouse -> certain kind of characters emitted, like ^[[M #"^[[M##" -- this format can only encode values up to 223
^C
echo -ne '\e[?1006h'
cat
click with mouse -> another totally different format is emitted, like ^[[<0;3;2M^[[<0;3;2m -- this new format can encode arbitrarily large numbers
^C

Then wherever \e[M is recognized by ncurses, you should also look for \e[< and if you encounter this input, instead of reading three bytes you need to read three decimal integers, delimited by semicolon, terminated by M or m. As opposed to the legacy format, you no longer should subtract 32 from the three values (or probably you need to subtract 1 instead of 33), and if the trailing character is a lowercase 'm' then the first value should be OR-ed by 3 (to fall back to the legacy way of encoding a mouse release).

For Linux console + gpm: I don't know how it works or is supposed to work.

I've already fixed many non-ncurses apps to support this extension, ncurses is yet to come.  Quite some apps (e.g. console web browsers, htop etc.) would benefit from such patch if it would become mainstream, your work would be greatly appreciated!


cheers,
egmont



reply via email to

[Prev in Thread] Current Thread [Next in Thread]