I've added an option for Happy Eyeballs to the v2.0a branch.
Support Happy Eyeballs for BBS connections
Ticket moved from /p/syncterm/tickets/295/ Can't be converted: _output_type: Win32-GDI _found_in_version: 1.8
The problem with using Happy Eyeballs is that many/most BBS connections aren't idempotent... as soon as a TCP connection is established, a resource is locked or consumed. Further, many BBS systems will strictly limit connections from the same IP address as well. Finally, some retro BBS systems used embedded stacks to convert to a serial connection and those can take as long as a couple seconds to SYN+ACK, and they also only allow a single incoming connection at a time. In short, opening multiple...
Are you suggesting that after the sixty second timeout it try the next address? I doubt that would be useful to anyone.
Sentinel one detects 1.9 as a threat
I've never even heard of Sentinal one, so I don't know how to report it either.
While DNS does give an IPv6 address, there doesn't seem to be a telnet server on it.
DECRQSS `*r` reports speed 0 when emulation came from the BBS list entry
Codex thinks it's fixed.
Status Display Type 2 doesn't work correctly
Codex says it's fixed.
Correct, SyncTERM is not a VT emulator... however the terminfo entry does have a full ACS set that curses should use appropriately, so NetHack is fully playable. I have no idea what watching NetHack on public servers does or is though... If I do add this is will likely be quite far out (a year or two).
Output speed emulation paces bulk APC and DCS payloads
This is intentional. RIP and ZModem aren't so much carve-outs as things that were too hard to pace when pacing was added. It's likely they will be paced in a future release.
Unable to initialize the Wren main menu
Ah yes, you only need files there if you want to override the compiled-in ones... and compatibility can be a real issue as you've found. ;)
Status Display Type 2 doesn't work correctly
Hrm, all I can think of is making sure you don't have overriding scripts in ~/.local/share/syncterm/scripts
Allow use of scrollback after disconnect
Yeah, Alt+Z was layout-specific, so it was really Alt+<key to right of left shift> and it looks like Alt+Enter was just plain broken.
Yeah, Alt+Z was layout-specific, so it was really Alt+\<key to right of left shift> and it looks like Alt+Enter was just plain broken.
Yeah, Alt+Z was layout-specific, so it was really Alt+\<key to="" right="" of="" left="" shift=""> and it looks like Alt+Enter was just plain broken.</key>
Yeah, Alt+Z was layout-specific, so it was really Alt+<key to="" right="" of="" left="" shift=""> and it looks like Alt+Enter was just plain broken.</key>
From the dialing directory, press Alt+B.
Ticket moved from /p/syncterm/tickets/291/ Can't be converted: _milestone: 1.10
MacOS: CIOLIB initialization failed!
Closing
displaying ansi in door causes syncterm to drop carrier...
Closing, SyncTERM is not dropping carrier, the BBS side is.
frequent crashes on exit
All of these reported issues (except your desktop not supporting window decorations) should be fixed in tomorrows v1.10a nightly.
The no window decorations in Wayland are because your desktop of choice refuses to provide them (SyncTERM requests them), but there are keyboard shortcuts for everything except minimizing. I'll take a look at the "keyboard shortcuts don't work" issue and see if I can reproduce that. The XWayland backend should work properly. It's really too bad these two issues weren't reported until after the release, there's not likely to be another release for quite a while.
ALT-L in Prestel mode needs to send #
Fixed.
Ah, sorry, I had read this as being reported against v1.9 for some reason. Will do.
ALT-L in Prestel mode needs to send #
Did you try pressing the return key? Prestel terminals don't have an alt key, so I have no idea why you think ALT-L has any "correct" mapping.
Did you try pressing the return key? Prestel terminals don't have an alt key, so I have no idea why you think ALT-L has any "proper" mapping.
Try using the native output mode instead of SDL.
Yeah, it appears your door is calling close() on the socket.
Assuming this is shsbbs.net, the server is sending a RST and initiating the teardown, not SyncTERM, so it's something on your end. The same issue appears to happen with SSH connections as well.
It doesn't sound like Cursor fixed anything, it just assigned blame with no data, and since this was opened as anonymous, I can't connect to anything to verify who is actually closing the connection. Cursors rationale also sounds completely bogus... there's no telnet code to disconnect.
The following is the normal set: TLS_AES_256_GCM_SHA384 (0x1302) TLS_AES_128_GCM_SHA256 (0x1301) TLS_CHACHA20_POLY1305_SHA256 (0x1303) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) Some will put the Chacha20 above AES128.
I am unable to make a TCP connection to port 992 on shsbbs.net (currently 174.27.157.145). From your error, it sounds like you manage to make a connection, but never receive the initial handshake. Both of these issues would be stunnel issues.
TelnetS?
No, I'm getting: Error activating session: handshake recv: recv syscall error (errno=0)
I'll look into this further. I was getting an error.
Shsbbs.net:992 Marty I'm using 1.2 and 1.3. I'm not sure if the cipher or tls level is the issue.
That port is not accepting connections.
I would need to know the address of your stunnel to connect. Also, pressing F1 on disconnect should provide logs, and you can adjust the log level in the entry settings. That said, using a version of TLS before 1.2 isn't a great idea... but maybe you're not doing that?
Ticket moved from /p/syncterm/tickets/287/ Can't be converted: _milestone: 1.10
MacOS: CIOLIB initialization failed!
Possibly, but Quartz should be the default unless you've explicitly overridden it in Program Settings → Video Output Mode.
This is intentional, maybe an option to change the behaviour?
Ticket moved from /p/syncterm/tickets/285/ Can't be converted: _output_type: X11 _found_in_version: 1.10a
[Suggestion] When Capture is used and file exists, offer Overwrite, Append...
And now, for ASCII and Raw, you get to choose between overwrite, append, and cancel.
Mouse stops working under certain conditions
Closing
For v1.9, changed the menu option to indicate append.
Feel free to open a feature request though, and support would show up eventually I'm sure.
Yeah, the disconnect screen is a model dialog and I'm lazy.
Ticket moved from /p/syncterm/feature-requests/149/ Can't be converted: _priority: 8 _milestone: NextMajor
Use Alt+B at the menu to access the scrollback from the last session.
documentation error
documentation error
Done, thanks for the report. It should be updated with the nightly build tonight.
Looks like at least parts of it are. The corpus is not... I've attached it here. Some of these are actually RIPv3 and some appear to be a combination of the two.
Mouse focus event tracking (DECSET/DECRST 1004)
I have a whole test setup I used for the RIPterm 1.54 work that runs RIPterm in DOSBox and a specially modified SyncTERM where the EGA aspect ratio isn't corrected (small change to conio/vidmodes.c) under X11. It connects both to a server that sends them RIP then captures screenshots using xwd and compares them. If they differ, it bisects the RIP file to find the broken code. It was still a nightmare to track down all the corner cases in fonts, buttons, and all the special rules about what exactly...
If a door does not steal the mouse, the mouse is for the user to use. It's an i-beam so the user can select text. If you hide the mouse, that would make it very difficult for the user to do what they want. The idea if my mouse pointer disappearing because I move it across a SyncTERM window sounds like something I would hate.
You seem to be conflating the window losing focus with the mouse leaving the window and the mouse leaving the pixel area of the window. Outside of fullscreen mode (and usually even in full-screen mode) there's a large area outside of the pixel coordinate system... black bars on the edges and "the rest of the desktop" all fall into this nebulous zone. Further, I can't think of any compelling reason a BBS needs to know if a specific window on my desktop has focus or not.
Mouse wheel unusable in a door under 1.10a; works in 1.9rc4
SSH hangs at "Opening Channel" when SFTP subsystem opens but FXP_INIT never completes
Closing, assumed fixed.
Copy/paste non-function in Wren console
Fixed.
Fixed if I understand what you're saying (scroll wheel should not be tracked as "pressed" or "released").
Mouse wheel unusable in a door under 1.10a; works in 1.9rc4
Fixed if I understand what you're saying (scroll wheel should be tracked as "pressed" or "released").
Mouse stops working under certain conditions
Should be fixed in git now.
nonodes.txt
Fixed in git.
I'm convinced. The disconnect notice should replace the scrollbar (or scroll up one line if scrollbar is disabled) with a red-background notice, obscuring nothing.
Copy/paste non-function in Wren console
80x43 mode seems vertically shifted
Ticket moved from /p/syncterm/tickets/279/ Can't be converted: _milestone: 1.10
Correct, that is not an issue, that is how the corresponding modes on real hardware actually behave.
There are no pixels chopped off the top of the row. The 'M' and 'l' have the same pixels as ones lower. The "gap" is normal for EGA modes, which use a 350-row display with an 8×8 font. You can see this clearly using RIPterm or other EGA software in DOSbox or what have you. This is what the real 80×43 mode did on real hardware, and RIP at least makes use of that.
I don't see any pixels "chopped off" anywhere... and the ×43 modes use 8×8 fonts on a 350-row window leaving six rows that are not part of any character cell. For 80 column modes, this is standard EGA.
Ah, 1056×350 is a VESA mode available on Cirrus CL-GD5420/5422/5426.
I don't see any pixels "chopped off" anywhere... and the ×43 modes use 8×8 fonts on a 350-row window leaving six rows that are not part of any character cell. For 80
Build failure on Manjaro
To do a release build using cmake with most backends, you need to pass -DCMAKE_BUILD_TYPE=Release on the CMake configure command-line, ie: cmake -DCMAKE_BUILD_TYPE=Release .. and concurrent builds should work. Concurrent builds in the GMake system are a nightmare due to many untracked dependencies right now. Long-term, CMake will almost certainly become the only supported build style, but there's still a few nits I need to nail down first.
fingerprint warning when switching syncterm versions
Ticket moved from /p/syncterm/tickets/275/ Can't be converted: _milestone: 1.10
Slow to abort XMODEM upoload (appears to hang, but just really slow to respond)
custom screen size.