Marco van de Voort wrote:
(Rather OT, but ...)
Not really. Maybe there is something in the GPC code base that has the same problems ;-)
Our CRT unit has a few non-portable routines (which don't even have a curses interface), but AFAIK all of them are known and documented in the unit. In particular, they are Sound/NoSound, TextMode, GetShiftState. The former is quite unimportant IMHO (only there for BP compatibility), so is the second mostly (most people set their text mode via SVGATextMode or run in a GUI window, and don't want their usual programs to mess with the size.
Pretty much the same here. The IDE implements some extra things to obtain a better look and feel, with a default for other cases (telnet/xterm).
Things like working alt-keys (kind of X mode, requires ctrl-alt to switch terms), the cursor stuff.
So the only thing I really miss is GetShiftState which we do via ioctl on Linux and other means on DJGPP and MS-Windows. I wish there were escape sequences for it ... perhaps someone will implement them in the future ... ;-)
I still have to do the keyboard. I did video first because that way I could visually check the working of the IDE better.
First tests indicate that I can get raw scan codes on FreeBSD via ioctl, but don't like that approach. (renders the keyboard unusuable if your handler hangs, and/or the exit is not graceful)
I don't think ncurses supports calling special functions to set the cursor shape, and there's another problem with those: They won't work across telnet/ssh etc. (because they would go to the remote system where they'd at best fail, rather than to the local system where the terminal is).
That wouldn't be a problem. The curs_set function returns -1 when not supported. So it could return a valid value on the console and -1 over telnet.
In theory perhaps. In practice I guess most programmers would just test it on their local system and not bother to check the return value ...
The IDE is an end user app, and I would fix that :_)
P.s. I also had some strange problems with writing to the last character on the screen. I found an old PR for that, that seems to imply that it is a known bug since 1999 (sigh)
The issue in general is known for a long time, but most terminals have solutions for it (including the Linux console and xterms, so I've never had a problem with it; actually I'd be surprised if FreeBSD had a problem with it). What's PR, BTW?
PR (IIRC patch-request) is a kind of bug submission to the FreeBSD core.
The odd part is that all code works fine on telnet/linux/in xterm, and only fails on FreeBSD console.