'To do' list for PDCurses 4.2.0

[Bill-Gray]

This discussion began under issue #110 ('merging upstream improvements'), but wandered off-track to the point where it deserves its own issue.
Before we push the 'release' button, we should:

• Obviously, update version constants and date in curses.h and version.mif. I think we now have the latter file properly set up to indicate patches; open: see 42e4205 and its comment.
• resolve issue Attributes not working on... something #129 (attributes not rendering correctly).
• resolve Makefile confusion Makefile confusion #131
• cleanup for removed CHTYPE_16 cleanup CHTYPE_16 partially alive #132

...Anything else?

[GitMensch]

Possibly integrate upstream changes to HISTORY.md, see #128.
If possible: add x11 to travis and (at least) try to run the different ports once with the test programs to verify that they do work (it may be reasonable to publish a 4.2 release candidate for this).

[GitMensch]

I've changed the list to a checklist, but leave the "done" marker to you after rechecking.
I suggest to also get another static analyzer running, see #98, and inspect the results (I can do the upload and presenting the checks when invited to a registered project).

[GitMensch]

@Bill-Gray ping - I'd really like to see 4.2 out sooner than later but have no time to work on more preparation. Can you please see if something is possible for you? 4.1 was published over a year ago and misses a lot of upstream changes done here - and a lot of good stuff was happening here too...

[staalmannen]

I have set up a sourcehut mirror where I hope to set up automated build testing using 9front. It should be possible to export the build results as a graphical "success" badge. Need to figure out how all these things work first though.

https://git.sr.ht/~staalmannen/PDCursesMod

https://builds.sr.ht/

BTW : will 4.2 be released soon? I would also like to package PDCursesMod for 9front "ports"
https://code.9front.org/hg/ports

Right now an old version of pdcurses in there with all plan9-specific modifications in the ports tree.

[Bill-Gray]

In the past couple of days, I've gotten the makefile issues sorted (issue #128). I believe we now have everything in place, except for version constant changes (top item in the 'to do' list, and the last thing that should be done before hitting 'release'). I would appreciate "sanity checking", particularly of HISTORY.md.

If nobody objects in the next couple of days, I'll fix version constants and release 4.2.

[loblolly986]

I'd still like to get a couple more fixes/improvements to WinGUI in before a release, as I mentioned before. Admittedly, involvement with other projects and real life busyness distracted me from working on this as soon as I had intended, though I'll try to get some of it done and proposed here within a couple days. I'd also be willing to go through and do the needed updates to the readme/documentation, DLL version resources, etc., to reflect the name change to PDCursesMod.

Primarily, I'd like to get the handling of consoles and the endwin() and delscreen() functionality in WinGUI fixed up. The current state is utterly deficient for programs that expect to be able to return to an ordinary console environment after entering curses mode, and/or that need to be linked as console applications (e.g. to facilitate providing help when invoked from a console), and is inconsistent with the documented behavior of endwin() and delscreen(). I have a good idea of how to resolve this, and just need to get it implemented.

I also had some fixes to the mouse handling that I wanted to wrap up and bring up in another issue. Also, I had already done some initial work on making WinGUI's fallback font feature work on NT 4.0, although I consider this a lower priority than the preceding issues.

Finally, it seems my PR regarding the beep functionality in WinCon and WinGUI (#176) has slipped through the cracks. Was planning to get around to resolving the Watcom makefile issue while waiting for Bill's opinion on the matter. I don't really see why we should have to wait for a similar fix to be accepted in mainline PDCurses' WinCon port before implementing it here. Again, however, I consider this issue a lesser priority.

Given a key purpose of a "release" is to provide an ostensibly more "bug free" version than just grabbing the latest source code revision or a "beta", it seems sensible to me to at least have the more important of these fixes implemented before pushing out a release, although I acknowledge this isn't my project.

[Bill-Gray]

Understood about the power of distractions... you'll notice it took a few months for me to get around to sorting out the makefile issues.

Must confess that I'd not really looked into all the places that say 'PDCurses' that, at least in theory, ought to say 'PDCursesMod'. I wouldn't let that slow 4.2 down much, but there are cases where it would help to be precise about which version(s) we mean. We might say PDCurses for wmcbrine's version, PDCursesMod for our version, and PDCurses* for things common to both versions.

Proper handling of endwin() and delscreen() goes beyond WinGUI, I find. Particularly the former... I added some code to newtest so that hitting 'z' would cause the sequence

   endwin();
   getchar();
   refresh();

to be called. This should cause us to drop from Curses mode to see the "original" screen; hit Enter, and we return to Curses mode. I use exactly this sequence in some of my programs where I've got a hotkey to let me peek at what was on the screen before starting the program (and what ought to be on the screen when I exit it.)

It behaves as described when compiled with ncurses, and in the VT flavor. It didn't in the DOS flavor. Behavior in WinGUI, X11, and the SDLs is somewhat undefined, since there is not necessarily a "console" back to which we would go. I suppose the thing to do for such platforms would be to close the window (or at least minimize it) on endwin() and restore it on refresh().

When you say "get the handling of consoles and the endwin() and delscreen()` functionality in WinGUI fixed up", what do you mean? What would you want to see happen when those functions are called?

You are correct about your beep solution having slipped through the cracks. Looking at it, I see no barrier to pulling it... except that I wish I'd done so before rearranging makefiles; some small changes will now be required to account for the absence now of any Makefile.mngs. But they should, in fact, be small.

[Bill-Gray]

@loblolly986 - unless you think you'll have the proposed fixes shortly... I'm inclined to do the remaining task (update version constants to 4.2), call what we have a release, and add your fixes in when you've got them. You are, of course, right that a "release" should be as bug-free as possible, but I'd accept what we have as bug-free enough. What with one thing and another, we've kept 4.2 waiting an extra-special long time already.

Are you close enough that I should hold off a bit, or shall we do a release?

[GitMensch]

Just a note: The only thing I'd like to see in is automatic generation of pdcurses.h from pdcurses.in according to the makefile options used (removing the need to manually define the correct constants), but I won't do anything on that in the next weeks myself.

Other than that: it is definitely time for a release.

[Bill-Gray]

Pushed through changes to version constants to 4.2.0, and (stupidly) did a release right away, without waiting to see what would break in Travis-CI. Turns out CMake/Travis-CI had a whitespace issue with PDC_VER_CHANGE.

I deleted the release. If everything goes through properly this time, I'll re-release and close this issue.