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.

[GitMensch]

@Bill-Gray Without looking into the depths of this PR... Should this new port be merged? Is there something open?
What about the PDC_FONT part in WinGUI (sounds like there should be an issue outlining the problem)?

[Bill-Gray]

@GitMensch -- Thanks for the nudge on this, and my apologies to @chasonr; I really shouldn't have left this dangling since February.

As I mentioned originally, I don't have an OS/2 machine and can't vouch for it myself. (I can look at the parts outside the os2gui directory, a mere few lines, and say "looks good to me".) @chasonr, @rexx-org, if you both sign off on this, I'll pull it. Fortunately, "this branch has no conflicts with the base branch"; we can merge in mere seconds.

Two minor things not really required at present, but which we might do after merging :

• It appears that there's some code in here that is basically a wcwidth() implementation (determine if a given Unicode point is a combining character or fullwidth). At a quick look, I'm wondering if that's redundant. We already have a wcwidth() implementation in pdcurses/addch.c, exported as PDC_wcwidth().
• I mentioned above that we might get around some of OS/2's limitations in Unicode support by displaying (for example) "piñata" by showing the string pi, followed by ñ, followed by ata. And I also mentioned that slicing up text in this manner is already done, a little, in the PDC_transform_line_sliced() function in pdcurses/refresh.c.

The "slicing" there ensures that fullwidth and combining characters are broken apart, and to avoid sending excessively long lines to PDC_transform_line(). This is fine for other ports, but we might have an internal function, PDC_break_nonascii(), to adjust this. The OS/2 GUI port would call it to say : slice text if it includes a non-ASCII character, as described above for piñata.

The bit about PDC_FONT in WinGUI is definitely a separate problem. Truthfully, the idea that PDC_FONT would refer to a PSF file name on DOSVGA or the framebuffer or DRM ports, a Windows font name on WinGUI (and maybe WinCon), an OS/2 font name for this port, and maybe an X11 font name for that platform, strikes me as a recipe for confusion. Maybe PDC_OS2_FONT, PDC_WIN_FONT, PDC_X11_FONT, etc...

[Bill-Gray]

Should add : I've verified that everything (including demos and 'tests') compiles without errors on OpenWATCOM on Linux. I have no way to compile for OS/2 with gcc (far as I know, you can't cross-compile). And there was discussion above about the fact that Makefile didn't have more recent demo programs.

I have put a modified Makefile here that includes those demos :

https://www.projectpluto.com/temp/Makefile

The same Makefile should work for both plain old OS/2 and for this new OS/2 GUI port.

I'm not pushing it because (since I can't cross-compile) it is 100% untested. It should add the missing demos init_col, newtest, picsview, speed, test_pan, and widetest. The changes are of the sort that ought to be no-brainers, and could be pushed through in total confidence that of course they'll work. Except things never work out that way... I'll hold off until somebody who can actually build OS/2 code with this new Makefile tells me it works.

[rexx-org]

If only it was as simple as using the same Makefile for os2 port and os2gui port :-) I've built the demos using the Makefile linked above with changes, but only with a static library. Have not built the DLL yet. Will work on that next.

[rexx-org]

The console version of OS/2 Makefile also did not create the pdcurses.dll correctly. I have attached the modified os2/Makefile and os2gui/Makefile which enable building both static library and DLL in the one directory and all demos linked against static library or DLL import library.
I'm happy for these Makefiles to be added and this PR pushed.
pdc.zip

[Bill-Gray]

Hi Mark - thank you! Unless I'm missing something, this looks to be a zip-ball of all of PDCursesMod from 2023 Jun 1, with no os2gui directory. Probably not what you intended to send...

Send me the files in question, or make a PR for them, and I'll pull your fixes plus this PR. Nice to see this added...

[Bill-Gray]

I've added Mark's revisions to the OS/2 console Makefile (see commit b4e9adb). The revisions for the OS/2 GUI Makefile will take a bit more thought; they need to be merged by hand with the fixes @chasonr made.

Also, we'll need to update some of the documentation (main README.md, for example) to add OS/2 GUI to the list of supported platforms. And it'd be nice to add some automated builds. But we're about 99% done.

[rexx-org]

Not sure what changes that @chasonr has made that need to be merged with the os2gui/Makefile I sent. I'm happy to do the merge, but the os2gui/Makefile builds a static library and DLL and all demos so is complete AFAIAC.

[Bill-Gray]

Looking a bit more closely, it seems to me @chasonr based his os2gui/Makefile on the wingui/Makefile. Yours is based on os2/Makefile. So they're quite different.

Perhaps we should just replace the current os2gui/Makefile with your version? (Again, can't test it out on my end.)

[rexx-org]

Yes there is a lot of stuff in @chasonr os2gui/Makefile that is not needed for the os2gui port. A complete replacement was my intention.

[Bill-Gray]

Okay, that makes sense. I've pushed it as commit 267f92a.