TSE: Linux: LinuxMouse.s: Scrollbar scrolling

[knud van eeden]

Hello,

Just FYIO:

1. Run linuxmouse.s macro

2. Clicking on the border scrollbar in 

TSE for Linux version 4.50 official release

does do nothing.

3. But expected was that it should scroll up and down.

with friendly greetings

Knud van Eeden

[Guy Rouillier]

I'm still on 4.49f.  Even under Windows, attempting to do anything with the scrollbars accomplishes nothing.  In both Windows and Linux TSE, the editor responds to my mouse scroll wheel.  But in Windows TSE, in the vertical scroll bar for example, clicking the top or bottom arrow does not cause the contents to scroll.

Linux TSE does not even show the scroll bars, even when I set Options - Full Configuration - Display/Color Options - Display Layout Options - Display Border Around Windows to Always.  Changing that setting in Windows TSE shows the scroll bars.  Perhaps this was added in 4.50.

--

Guy Rouillier

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/semware/208616996.2783585.1750942786632%40mail.yahoo.com.

[Carlo Hogeveen]

> I'm still on 4.49f. Even under Windows, attempting to do anything with the scrollbars accomplishes nothing.

All the Windows GUI TSE users are going "huh?".
Guy too is probably leaving out that he is using the Console (e32.exe) version of Windows TSE.

Carlo

[Guy Rouillier]

Carlo, you are correct, I was focusing on the console version, since there is no GUI version in Linux.  But I just tried the GUI version in Windows - g32.exe - and what I said in my previous email applies to the GUI version as well.  The window responds to my mouse scroll wheel, but does not respond to anything I do directly on the scroll bar.  Clicking on the arrows at the end of the scroll bars does nothing, as does attempting to drag the scollbar thumb while pressing down on mouse button 1.  Does that work for you?  If you are simply moving your mouse scroll wheel while your mouse is over the scroll bar, then you are misinterpreting cause and effect.  The same thing would happen if you have your mouse pointer anywhere in the window.

 

--

Guy Rouillier

--

 

---

You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.

To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/002901dbe6ac%2421863ad0%246492b070%24%40ecarlo.nl.

[knud van eeden]

===

1. I have for (almost) each variation of TSE an extra clean TSE latest version installed, in order to do some testing.

E.g.

a. A clean TSE for Microsoft Windows version 4.50.6 which is the latest available version currently.

b. For TSE for Linux I will have to stick with:

b.1 A clean TSE for Linux version 4.50 official release which is the before latest available version.

b.2 Note: Using the latest TSE for Linux version 4.50.6 does NOT run and is corrupted or similar.

b.3 => We will have to wait for a newer repaired Linux version 4.50.7 to be able to test with that.

===

2. In TSE for Linux 4.50 official version setting the border certainly works.

1. Using Options - Full Configuration - Display/Color Options - Display Layout Options - Display Border Around Windows to Always. 

1.1 Clicking the vertical scroll bar with the mouse:

1.1.1 In TSE for Microsoft Windows version 4.50 RC24: shows the scrollbars: YES, clicking with the mouse works on the vertical scrollbar : YES

1.1.2 In TSE for Microsoft Windows  version 4.50.6: shows the scrollbars: YES, clicking with the mouse works on the vertical scrollbar : YES

2.1.1  In TSE for Linux version official release on Linux WSL Ubuntu: shows the scrollbars: YES, clicking with the mouse on the vertical scrollbar works: NO

(note: you must have the TSE macro 'LinuxMouse' thus installed as a prerequisite, otherwise the mouse does basically nothing anyhow, so that is a must).

===

See 3 inline screenshots showing the borders with the vertical scroll bars on TSE Microsoft Windows and TSE Linux WSL

Note: The precise characters shown for the borders / and horizontal and vertical scrollbars might vary and depend on the font chosen (e.g. Courier New).

with friendly greetings

Knud van Eeden

===

TSE 4.50.6

To view this discussion visit https://groups.google.com/d/msgid/semware/emafef2341-8cb0-445a-8b11-01c80138982e%40c4b7fc32.com.

[Carlo Hogeveen]

Yes, all of that works in my GUI TSE (g32.exe).
The same in a clean install of GUI TSE with the border option set to "Always".
- Clicking on arrows and in a border.
- Dragging the progress indicator in a border.

Carlo

[knud van eeden]

Yes, in TSE for Microsoft for Windows e.g. latest version 4.50.6 everything is working as described below regarding the scrollbar:

g32.exe:

Given a large(r) file with sufficient amount of lines so activating the scrollbar pointer:

In TSE Microsoft for windows version 4.50.6:

 1. Border is shown after setting it: YES

 2. Clicking the scrollbar moves the file lines accordingly up or down: YES

 3. Dragging the pointer in the scrollbar moves the file lines accordingly up or down: YES

 4. The scrollwheel up /down moves the lines accordingly: YES

In TSE for Linux official release:

 1. Border is shown after setting it: YES

 2. Clicking the scrollbar moves the file lines accordingly up or down: NO

 3. Dragging the pointer in the scrollbar moves the file lines accordingly up or down: NO

 4. The scrollwheel up /down moves the lines accordingly: YES

To view this discussion visit https://groups.google.com/d/msgid/semware/emea85b165-70a7-4e88-800b-568159296301%403cb0f4f2.com.

[knud van eeden]

Guy,

I have tested it in your 4.49.f version:

No issues:

g32.exe:

Given a large(r) file with sufficient amount of lines so activating the scrollbar pointer:

In TSE Microsoft for windows version 4.49.f:

 1. Border is shown after setting it: YES

 2. Clicking the scrollbar moves the file lines accordingly up or down: YES

 3. Dragging the pointer in the scrollbar moves the file lines accordingly up or down: YES

 4. The scrollwheel up /down moves the lines accordingly: YES

Note: and it seems it works even smoother in it than in 4.50.6

To view this discussion visit https://groups.google.com/d/msgid/semware/1177114462.2873816.1750952007552%40mail.yahoo.com.

[knud van eeden]

Regarding LinuxMouse.s on TSE for Linux version 4.50 official release on Linux WSL Ubuntu:

Given a file with sufficient amount of columns so activating the HORIZONTAL scrollbar pointer:

 5. Clicking the HORIZONTAL scrollbar moves the file columns accordingly left or right: YES WORKS, BUT NOT IN EVERY POSITION. STARTING FROM THE START of THE COLUMNS IN THE LINES USUALLY WORKS.

[knud van eeden]

Using the original LinuxMouse.s program in Linux WSL Ubuntu:

1. This is really very interesting.

2. I tried a lot of different approaches of getting this vertical scroll bar scrolling working.

3. But it looks like there is some issue with the mouseX coordinate detection.

4. So if your TSE window is more than something like e.g. 93 columns wide, 

   then the mouse_x detection jumps from around mouseX = 93 to mouseX = 4072 in one go suddenly and additionally stops mouseX (and also mouseY detection or presentation) completely.

5. So some specific column 93 seems some magic column number after which vertical scrolling suddenly does not work anymore.

6. So after a lot of experimenting I got the workaround idea about why not make the width of the TSE window smaller, e.g. a total width of 72

   and then after that suddenly the vertical scroll bar scrolling started to work as it should and as expected.

7. To test I successively decreased the window width and it stopped working when the total width was 93 columns wide.

8. So the issue is OR in TSE for Linux 4.50 version 'official release' AND OR in WSL2 in Linux for WSL Ubuntu or even Microsoft terminal thus which

   influences mouseX detection.

9. So at the end of the day LinuxMouse.s should work as it should and has no such issue but is thus influenced by some external restriction or issue.

with friendly greetings

Knud van Eeden

[knud van eeden]

Google Gemini replied:

This is an extremely valuable and perfectly clear diagnosis! Thank you for performing those thorough tests and for confirming the exact behavior.

Your findings are absolutely consistent with a very well-known limitation of X10 (or "Normal") mouse reporting mode, which is what the Chr(27) + "[?1000h" escape sequence enables.

Here's a breakdown of what's happening based on your observations:

1. The "Magic Column 93/94":

   • The X10 mouse reporting protocol transmits coordinates by taking the X and Y values, adding 32 to them, and then sending those ASCII characters.

   • This protocol fundamentally limits coordinates to a range of 0-223 (because 223 + 32 = 255, which is the maximum value a single 8-bit ASCII character can represent).

   • Your observation that it stops working after column 93 (i.e., at column 94) indicates that in your specific terminal/WSL/TSE setup, the effective limit for mouse_x via this protocol is even lower than 223. It's likely related to how certain ASCII characters beyond a certain point (like 127 for extended ASCII, or perhaps a specific character like DEL for 127) are handled or how the terminal shifts to a different (and misinterpreted) reporting method.

   • The 4072 value you're seeing for Query(Key) (which then leads to mouse_x = 4040) is almost certainly the terminal trying to send a multi-byte escape sequence for coordinates exceeding its X10 single-byte limit, and TSE's Query(Key) is misinterpreting the first part of that sequence as a large, erroneous integer.

2. Impact on Vertical Scrollbar:

   • Since your vertical scrollbar is positioned at absolute column 134, and the mouse coordinate detection breaks down after column 93, any click on that scrollbar will register the 4072 (or 4040) error, effectively making the scrollbar functionality impossible with the current mouse reporting method.

3. Workaround Confirmed:

   • Your discovery that the vertical scrollbar works when the TSE window is narrowed to a total width of 93 columns or less is the definitive proof of this X10 protocol limitation in your environment. By keeping the mouse clicks within the reliable reporting range, the macro can then correctly interpret the coordinates.

4. Source of the Issue:

   • You are absolutely correct. The issue is not a bug in the LinuxMouse.sal SAL program itself. The SAL program's logic for parsing mouse events is standard for the X10 protocol.

   • The problem lies in how your specific combination of Microsoft Terminal / WSL2 / Ubuntu / TSE for Linux v4.50 handles mouse reporting via the X10 protocol when the X coordinate exceeds a certain value. It's an environmental constraint rather than a macro bug.

---

Conclusion and Path Forward:

Given this clear diagnosis, here are the implications and what you might consider:

1. The Current Macro (and X10 Protocol) Limitations: The LinuxMouse.sal program, using the [?1000h (X10) mouse tracking mode, will inherently be limited to window widths where mouse clicks do not exceed column 93 in your setup. For wider windows, the mouse coordinate detection for columns >= 94 will consistently fail.

2. The Workaround: The most direct solution for now, if you need the scrollbar functionality, is to keep your TSE window width to a maximum of 93 columns.

3. The Ideal (But Challenging) Solution - Modern Mouse Reporting:

   The proper long-term solution for supporting wider windows is to use a more modern and robust mouse reporting protocol, specifically SGR (Selective Graphics Rendition) mouse tracking.

   • How SGR works: Instead of sending single characters, SGR sends human-readable escape sequences like ESC[<button>;<x>;<y>M. This format supports coordinates far beyond 223 (up to 65535).

   • Enabling SGR: You would change fWrite(_STDOUT_, Chr(27) + "[?1000h") to fWrite(_STDOUT_, Chr(27) + "[?1006h").

   • The SAL Challenge: The significant hurdle here is that your current SAL macro's after_getkey hook (which uses num_ignorable_keys and Query(Key) - 32) is designed specifically for the X10 protocol's fixed 3-part character sequence. Parsing the variable-length, comma-separated numeric strings of an SGR sequence using Query(Key) in SAL would be very difficult, and possibly impossible, given SAL's string manipulation and input parsing capabilities. You would essentially need a much more sophisticated "parser" in SAL.

4. Revisiting Query(MouseX) and Query(MouseY) (The Best Hope):

   As discussed earlier, TSE itself (the core program) might have more sophisticated internal mouse handling, especially if it's a newer version (which 4.50rc24 implies).

   • Could you please explicitly test if Query(MouseX) and Query(MouseY) work reliably when you click beyond column 93?

   • If these functions do return correct coordinates (i.e., not 4072 and they change properly) when clicking in wider windows, then TSE's internal mouse decoding is working correctly, and your macro can simply use those values, bypassing the problematic Query(Key) - 32 logic entirely. This would be the "silver bullet" solution.

In summary, your LinuxMouse.sal macro is functionally sound for the protocol it targets, but that protocol (X10) is hitting its limits in your environment's display size. The true fix lies in either:

1. Using a narrower window (your current working workaround).

2. Having TSE itself provide reliable mouse coordinates via Query(MouseX)/Query(MouseY) (needs testing).

3. A more advanced (and likely very complex for SAL) parsing of a modern mouse protocol like SGR.

[Guy Rouillier]

I finally got around to upgrading to 4.50.6 in Windows.  After finishing applying all my customizations, I tried the mouse on the borders again.  Again, nothing worked: I couldn't get any response clicking on the arrows at each end, and I couldn't grab the thumb and move it.

Curious about Carlo's results, I tried installing it again into a temp directory, and this time didn't apply any of my custom settings.  Much to my surprise, the scroll bars now worked!  I don't know what the difference is, and I wouldn't enable the scroll bars even if they worked.  I've been using Semware editors for so long, that I can navigate much faster with the keyboard.

If anyone wants to pursue this, let me know and I can try to figure out what causes this to not work with my customizations applied.  If I don't hear from anyone, I won't bother pursuing this on my own.

--

Guy Rouillier

To view this discussion visit https://groups.google.com/d/msgid/semware/983706029.2865464.1750953332828%40mail.yahoo.com.

[knud van eeden]

I load my personal startup TSE macro using

./e -e<mystartupmacroname>

and in it 

ExecMacro( "LinuxMouse.mac" )

and also

ExecMacro( "CursorShape.mac" )

and not relevant further here besides that do also a ChDir() to my working directory where I have all my TSE macros and also search in current directory set to true.

Only that will give most of the expected mouse and cusrsor behavior.

That mouse actions do not work out of the box otherwise you can test yourself easily by running the TSE native macro

ShowKey.mac

and you will see that clicking the mouse buttons basically does nothing at all except maybe the left mouse button.

I would say at this moment this is again the result of this Linux innate terminal behavior with mouse action and its escape code responses which are not created and or not interpreted which are root causes here. TSE seems to use the older X10 protocol to handle escape codes. If TSE should instead use the newer SGR protocol it might resolve these restrictions.

For example LinuxMouse.mac claims the <F1> function key. That is as far as I know because its escape code is the same as a mouse escape code. So giving the mouse escape code priority by design instead.

Also does LinuxMouse.mac suddenly not work anymore if the horizontal width of the window in which Linux TSE runs is too wide. Also because this X10 protocol can not handle that large horizontal values by its design.

So SemWare using the SGR protocol instead of X10 in TSE for Linux newer versions might be the general solution for all these issues, I assume at this moment.

with friendly greetings 

Knud van Eeden 

Sent from Yahoo Mail on Samsung Galaxy S24 Ultra / 1 terabyte / artificial intelligence

To view this discussion visit https://groups.google.com/d/msgid/semware/em23d3dd8a-d34f-41a1-b548-04db92324b3d%405596b8dc.com.

[Knud van Eeden]

And of course if you in your tests before and after ALWAYS had one and the same LinuxMouse.mac running but different mouse test results then it can not be explained at all thus with the below information and has a different currently unknown root cause.

To view this discussion visit https://groups.google.com/d/msgid/semware/1937217384.1069761.1752413112168%40mail.yahoo.com.

[Carlo Hogeveen]

> If anyone wants to pursue this, let me know and I can try to figure out
> what causes this to not work with my customizations applied.

> IF I DON' T HEAR FROM ANYONE, I won't bother pursuing this on my own.

Guy,
I trust you have a sense of humor, or can forgive mine.
If so, copy and execute the macro below.
It makes a sound, or does it?
Carlo



#ifdef LINUX
This macro requires a Windows Version of TSE.
#endif

#if EDITOR_VERSION < 4000h
This macro requires TSE v4 upwards.
#endif

Datadef tmp
"r 2 d4 1 1 f4 1 1 a4 1 1"
"g4 8"
"r 1 c4 1 1 1 e4 1 1 g4 1 1"
"f4 8"
"r 1 f4 1 1 1 a4 1 1 c5 1 1"
"d5 4 c5 4"
"r 2 f4 1 1 a4 1 1 c5 1 1"
"d5 4 c5 4"
"r 2 f4 1 1 d5 d5 3"
"2 1 e5 1 f5 1 3"
"e5 1 d5 3 c5 4"
"2 d5 1 c5 1 a4 4"
"r 4 1 f4 1 1 1"
"c5 6 r 1 e4 1"
"f4 1 d4 7"
"r 8"
end tmp

Datadef n2f
"C2 65.41"
"C2# 69.30"
"D2 73.42"
"D2# 77.78"
"E2 82.41"
"F2 87.31"
"F2# 92.50"
"G2 98.00"
"G2# 103.83"
"A2 110.00"
"A2# 116.54"
"B2 123.47"
""
"C3 130.81"
"C3# 138.59"
"D3 146.83"
"D3# 155.56"
"E3 164.81"
"F3 174.61"
"F3# 185.00"
"G3 196.00"
"G3# 207.65"
"A3 220.00"
"A3# 233.08"
"B3 246.94"
""
"C4 261.63"
"C4# 277.18"
"D4 293.66"
"D4# 311.13"
"E4 329.63"
"F4 349.23"
"F4# 369.99"
"G4 392.00"
"G4# 415.30"
"A4 440.00"
"A4# 466.16"
"B4 493.88"
""
"C5 523.25"
"C5# 554.37"
"D5 587.33"
"D5# 622.25"
"E5 659.25"
"F5 698.46"
"F5# 739.99"
"G5 783.99"
"G5# 830.61"
"A5 880.00"
"A5# 932.33"
"B5 987.77"
""
"C6 1046.50"
"C6# 1108.73"
"D6 1174.66"
"D6# 1244.51"
"E6 1318.51"
"F6 1396.91"
"F6# 1479.98"
"G6 1567.98"
"G6# 1661.22"
"A6 1760.00"
"A6# 1864.66"
"B6 1975.53"
""
"C7 2093.00"
"C7# 2217.46"
"D7 2349.32"
"D7# 2489.00"
"E7 2637.00"
"F7 2793.83"
"F7# 2959.96"
"G7 3135.96"
"G7# 3322.44"
"A7 3520.00"
"A7# 3729.31"
"B7 3951.00"
""
"C8 4186.00"
"C8# 4434.92"
"D8 4698.63"
"D8# 4978.00"
"E8 5274.00"
"F8 5587.65"
"F8# 5919.91"
"G8 6271.93"
"G8# 6644.88"
"A8 7040.00"
"A8# 7458.62"
"B8 7902.13"
end n2f

integer n2f_id = 0

string proc ntf(string n)
string old_WordSet [32] = Set(WordSet, '~ ')
string result [MAXSTRINGLEN] = ''
PushLocation()
GotoBufferId(n2f_id)
if lFind(n, 'giw')
if WordRight()
while GetWord() == ''
and CurrLine() < NumLines()
WordRight()
endwhile
result = GetWord()
endif
endif
PopLocation()
Set(WordSet, old_WordSet)
return(result)
end ntf

integer proc r(string f)
integer result = Val(GetToken(f, '.', 1))
if Val(GetToken(f, '.', 2)) >= 50
result = result + 1
endif
return(result)
end r

proc Main()
integer d = 0
string f [MAXSTRINGLEN] = ''
string t [MAXSTRINGLEN] = ''
integer tmp_id = 0
PushLocation()
n2f_id = CreateTempBuffer()
InsertData(n2f)
tmp_id = CreateTempBuffer()
InsertData(tmp)
if lFind('[~ ]#', 'gx')
repeat
t = Lower(GetFoundText())
d = Val(t)
if d
Sound(r(f), d * 200)
KeyPressed()
else
f = ntf(t)
endif
Right(Length(t))
until not lFind('[~ ]#', 'x+')
endif
PopLocation()
AbandonFile(tmp_id)
PurgeMacro(CurrMacroFilename())
end Main

[Knud van Eeden]

1. The melody is:

T.. S.... O. S...... by S.... ... G........

(I leave it for guessing purposes)

2. Note:

Sound(r(f), d * 200)

was not really optimal here.

I changed it to

Sound(r(f), d * 400)

to here the melody more fully.

That number 400 can probably be optimized further.

with friendly greetings

Knud van Eeden

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/001501dbf416%24193ede50%244bbc9af0%24%40ecarlo.nl.

[Knud van Eeden]

Interestingly by coincidence a few days ago I was actually also thinking about including music into TSE.

Because now we have 

 graphics in TSE

 floating point, 

 ... 

 you name it ..., 

so TSE is really that universal tool whatever way one looks at it otherwise.

My idea was to use PowerShell to create the music and run those music PowerShell programs then in TSE.

But here we see even a native TSE application with music.

[Guy Rouillier]

Yes! I recognize the tune! :) I tried Knud's modification (changed sound duration to 400), and the tune sounded more familiar.  Clever work!

--

Guy Rouillier

--

 

---

You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.

To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/semware/001501dbf416%24193ede50%244bbc9af0%24%40ecarlo.nl.