New port -- OS2GUI

[chasonr]

This port provides a windowed display on OS/2, similar to the one that WinGUI provides.

It provides limited support for Unicode, but no supplementary characters. Some of the algorithms that support Unicode might be useful on other ports, such as SDL1 and 2.

[GitMensch]

Thank you for the work you've put into that!
The Acknowledgements in the README seem to be not matching

Out of interest: can you please make a screenshot on ozdemo in the os2 and os2gui port and share those here?

[GitMensch]

@Bill-Gray: the Makefiles skip newtest for !WIN32 - is that reasonable?

[rexx-org]

Great work! I look forward to building THE with it.

[chasonr]

ozdemo screenshots:
OS/2 text:

OS/2 GUI:

[rexx-org]

Good start to THE porting:

[Bill-Gray]

Looks good to me. I can't really test it; once you and Mark give it the thumbs-up, I'll pull it. I think the most I can do is to cross-compile it on my Linux box using OpenWATCOM; I've no way of running an OS/2 program.

The one minor nit I can pick is that we'll have to add a PDC_PORT_OS2_GUI or similar in curses.h for the PDC_port enum, and then modify pdcutil.c to return that value instead of PDC_PORT_WINGUI. I'd have to call that a pretty minor nit.

@GitMensch , in re newtest being skipped : where are you seeing that? I would not be surprised if some makefiles for some ports are not completely au courant (in fact, I'd be a little surprised if they all were). Any makefile that includes watcom.mif or libobjs.mif should be complete... which would cover gcc, OpenWATCOM, and MSVC.

[chasonr]

OK, I've added a PDC_PORT_OS2GUI enum.

I've had no trouble building newtest in the OS2GUI port. I used it quite a lot to get the Unicode rendering right.

[Bill-Gray]

@GitMensch - nevermind, I see now; the Makefiles for OS/2, and therefore those for this port, haven't had the list of demos updated for a while. None of the demos are platform-specific (except for sdltest). So yes, we ought to modify things here so that newtest.exe, and several other more recent demos, get built.

[rexx-org]

I haven't done extensive testing, but I've tried to change the font and font size by setting the environment variable PDC_FONT. I've tried set PDC_FONT=Courier:8, set PDC_FONT=DejaVu Sans:8 but neither makes a difference to the resulting font face/size. BTW DejaVu Sans is a truetype font which displays fine in the Font Viewer.

On a related matter for which I'll do some more digging but there is inconsistency between platforms in how the font face and size are specified. On some there is PDC_FONT=face:size on other PDC_FONT=face, PDC_FONT_SIZE=size.

[GitMensch]

Cool. Can you please adjust the makefile (maybe also cmakelist) to have newest built (ideally also for OS2) and share a screenshot for comparison? Am 8. Februar 2024 03:38:54 MEZ schrieb chasonr ***@***.***>:

…

OK, I've added a `PDC_PORT_OS2GUI` enum. I've had no trouble building `newtest` in the OS2GUI port. I used it quite a lot to get the Unicode rendering right. -- Reply to this email directly or view it on GitHub: #315 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[GitMensch]

Bill, can you please share the necessary adjustments to have it cross-compiled in the CI? This way it can be included in the PR and be compile-tested automatically.

[rexx-org]

Some more observations/behaviour issues.

• I am running eCS in a VirtualBox VM on Linux
• I built tuidemo and THE and used them as comparisons below.
• I found the "Choose Font" option from the window menu. This works as expected. However it seems that there is a complete screen refresh each time the text cursor blinks, if you have the text cursor displayed. tuidemo which doesn't display the text cursor is much faster then THE which does display the text cursor. The screen refresh is much slower if a TrueType font is selected compared to Courier or Courier New.
• The GUI window that is created does not have any border; ie the curses text inside the window goes right to the edges of the window. At least it does in tuidemo. This is not a big issue except when the curses text background is the same colour as any underlying window. However in THE there is a black margin on the left side. See this snip of the bottom left corner of the THE window. It could be because THE is made of of multiple curses windows whereas I believe tuidemo is a single window horizontally (I think).
  
  There is a console window under the OS2GUI window running THE.
• The only way to bring an OS2GUI window to the front with a mouse click is if the click occurs on the window title bar. Clicking anywhere else in the window does not bring the window to the front. At least on my system clicking anywhere in a window will bring it to the front.
• If I drag the OS2GUI window with THE running, the re-display of text is offset a bit from the original. See the following image:
  
• Dragging tuidemo window around leaves "droppings" as in this image
  
• apart from these largely cosmetic issues it is still a greate piece of work!!

[chasonr]

• Developing on ArcaOS 5.1 under VirtualBox. I have some older OS/2s available, though not eCS.
• I can't replicate the droppings.
• The PDC_FONT issue seems straightforward enough. The OS2GUI port stores font settings and the window position in the user profile, much as the WinGUI port uses the registry. It seems to be using the profile settings in preference to PDC_FONT.
• Click to focus seems easy enough to fix.
• I don't know how we would get a full refresh on the blink of the cursor.
• Refresh isn't as fast as I would like. Unicode support on OS/2 has more bugs than the Okefenokee Swamp. I have to render one character at a time or strange things happen.

[Bill-Gray]

@chasonr - speaking from a basis of ignorance here, but... re "I have to render one character at a time or strange things happen" : I wonder if some splitting up of text would help? If the text 'Piñata' were sent to PDC_transform_line(), the OS/2 GUI code could output 'Pi', then 'ñ', then 'ata'. For the first and last "pure ASCII" runs, multiple characters could be emitted using non-Unicode functions. Anything outside U+32 to U+126 would be emitted as a single character. The call to PDC_transform_line() would be broken into three separate calls for this case, but would proceed at full tilt as long as it was fed only ASCII text.

(This occurs to me because I had to do something similar with fullwidth and combining characters, which are handled differently in the various forks of Windows. Internally, the PDC_transform_line_sliced() function ensures that PDC_transform_line() never "sees" anything after a fullwidth or combining character, so there's no risk of misalignment.)

[chasonr]

I've added support for PDC_FONT_SIZE, made PDC_FONT override the registry and made mouse clicks put focus on the window.

[GitMensch]

Shouldn't the environment variables be handled identical in WinGUI - or is that already the case? Note: I think that environment overrides should *not* be stored in the file system.

[rexx-org]

Have applied the PDC_FONT and click to front changes. The click to front works fine, but I have some more testing of the PDC_FONT behaviour.
An update on screen refresh on my system. The "screen refresh for each cursor blink" seems to be something that happens occasionally on my system. I have another program that redisplays the whole window each time a new line is added. Once I rebooted my system, both redisplay issues went away, so I would say that the issue I had with screen refresh is not related to OS2GUI port.

[rexx-org]

I do have one more request for a change before we merge. The support for the PDCursesMod program being able to trap the window close event should be made to OS2GUI the same as the WINGUI functionality. In fact I copied the code for the WM_CLOSE event from wingui/pdcscrn.c to os2gui/pdcscrn.c and THE could catch the window close event.

[chasonr]

WinGUI doesn't support PDC_FONT. Existing ports that support it are DOSVGA, FB, GL, SDL1 and SDL2.

PDC_FONT_SIZE is supported in GL, SDL1 and SDL2. In DOSVGA, the font format is PSF, which has but one font size per file and so PDC_FONT_SIZE is moot. Perhaps FB has that property also?

OS2GUI at its present state does not save the font settings if they came from PDC_FONT and PDC_FONT_SIZE.

[Bill-Gray]

The framebuffer/DRM port (basically the same port, except with different libraries used to push pixels to the screen) lets you specify a PSF or PSF2 or "plain" VGA font with PDC_FONT, but the font will have a fixed size. I do have some thoughts about scaling fonts, with the usual caveats that it's ugly unless you're scaling by an integer. (Being able to rotate fonts 90, 180, or 270 degrees may also be useful. I have two monitors, one in portrait mode. Others may have phones and need dynamic rotation. But I digress.)

The framebuffer/DRM port also allows you to specify more fonts as PDC_FONT2, PDC_FONT3, etc. You can cycle among them (and among the built-in 8x14 font) by hitting Ctrl-Minus. Some further details are in the README.md for the FB/DRM port.

The general idea that how fonts are specified ought to be similar across ports resonates with me. It does get to be difficult when some ports use PSF/PSF2/VGAfont formats, which provide only one size, and others are more scalable. (SDLn in non-WIDE mode uses an unusual bitmap format consisting of a Windows™ .BMP file, which resembles the PSF/PSF2/VGAfonts in only providing a single font size... I've long thought that it might be good to rip out the font-handling bits of FB/DRM, put them into common, and use them in the SDLs for non-WIDE builds. Actually, since PSFn supports Unicode, we could use them in WIDE SDLn builds as well.)

Anyway... at the very least, it seems to me that WinGUI ought to respond to PDC_FONT in some meaningful way that is somewhat consistent with other ports.

[chasonr]

Added code to respond to WM_CLOSE. It's just a direct crib from the WinGUI port.