Win32a changes submitted

[Bill-Gray]

With this, "mainstream" PDCurses should be updated to include the new Win32a flavor. Other flavors are not greatly affected, except as described at http://projectpluto.com/win32a.htm#2015may31 and in the commit comments. So I think this will be straightforward, even though it's a fair bit of code.

[TheGentzy]

I've been using this recently and its been running smoothly. I did have a few issues getting it to work along the way, but I believe those were my mistakes. I really do hope this gets merged with the main repo.

[techtonik]

This needs to be rebased to solve conflicts.

[luke-jr]

Merged, not rebased. Rebasing is considered a bad practice.

[luke-jr]

What if CHTYPE_16 is defined?

[Bill-Gray]

Hi Luke,

On 2016-03-23 00:26, Luke-Jr wrote:

In curses.h #6 (comment):

@@ -34,11 +34,16 @@ PDCurses portable platform definitions list:
#define XOPEN 1 /* X/Open Curses routines /
#define SYSVcurses 1 / System V Curses routines /
#define BSDcurses 1 / BSD Curses routines /
-#define CHTYPE_LONG 1 / size of chtype; long */
+#if defined( CHTYPE_32)

• #define CHTYPE_LONG 1 /* chtypes will be 32 bits */
  +#elif !defined( CHTYPE_16)
• #define CHTYPE_LONG 2 /* chtypes will be (default) 64 bits */

What if CHTYPE_16 is defined?

In that case, CHTYPE_LONG is left undefined.

There's some discussion of this in curses.h (search for "Originally,
PDCurses used a short" and read from there.) Until Win32a came along,
your options were to leave CHTYPE_LONG undefined, in which case you
got 16-bit chtypes and some limited attributes and colors; or you
could #define CHTYPE_LONG 1 and get 32-bit chtypes, basic Unicode
support (i.e., up to U+FFFF), and plenty of colors and attributes.

Since this was a binary decision, it made sense to have the options
be "either CHTYPE_LONG is defined, or it isn't." Making it a ternary
choice, with 64-bit chtypes as an option, threw a spanner into the
works. For backward compatibility, I just set things up so that
option was enabled with #define CHTYPE_LONG 2.

-- Bill

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
https://github.com/wmcbrine/PDCurses/pull/6/files/c1ab1e40dc35a905edd65e5263ce9d7029d5e452#r57108353

[luke-jr]

BTW, is it possible to build this such that the console vs GDI decision can be made at runtime (eg, via a command-line option)?

[techtonik]

Merged, not rebased. Rebasing is considered a bad practice.

I'd say that merges and huge commits are hard to review, so rebasing and splitting changes into small independent PRs is often the only way forward. Depends on reviewer, though.

[techtonik]

BTW, is it possible to build this such that the console vs GDI decision can be made at runtime (eg, via a command-line option)?

Technically it is possible, but I am not sure that it is a good fit for this PR.

[Bill-Gray]

Hi Luke,

On 2016-03-23 00:31, Luke-Jr wrote:

BTW, is it possible to build this such that the console vs GDI decision can be made at
runtime (eg, via a command-line option)?

I suppose it could be done, with a great deal of revision. (A lot
of revision.) There's also not a lot of duplicate code involved, so
whichever flavor you chose, you'd be loading in a lot of code for the
other flavor without using it. I guess I'd have to ask "why would you
want to do this?"

Note that SDL would also be a choice, so you could load up all
three sets of code and make a runtime decision amongst them. (There
is actually apt to be more overlap between SDL, GDI, and X11 than
between any of them and Win32 console. All three flavors will use
similar logic for blinking, determining background/foreground
colors, and a few other items. All three could support user and
programmatic resizing, under/over/left/right/strikeout lining,
"real" blinking, and dimmed, italic, and bold text. Win32
console can't support most of these, and has little code overlap
with those three flavors.)

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#6 (comment)

[Bill-Gray]

On 2016-03-23 04:54, anatoly techtonik wrote:

Merged, not rebased. Rebasing is considered a bad practice.

I'd say that merges and huge commits are hard to review, so rebasing and splitting
changes into small independent PRs is often the only way forward. Depends on reviewer,
though.

You're both getting beyond my very limited knowledge of git (only
started to use it recently, though I'm now quite enthusiastic about it).
A search on "git merge vs. rebase" is helping to lessen my ignorance.

The "Golden Rule of Rebasing", described here,

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview

suggests some possible problems (I think) with rebasing.

Dunno if this would help, but... since the time I forked from
wmcbrine/PDCurses/master, that branch has had three commits. Two
("warning suppression" and "Parameters not given here", on 7 Feb)
are now incorporated in Bill-Gray/PDCurses/master. The remaining
commit, pulling in Laura Michaels' TTF/Unicode SDL changes, would
be easy enough for me to add in.

If I do that, wmcbrine/PDCurses/master could be rolled back
to where it was when I forked it, and the merger/rebasing would be
done on the basis of "here are some changes from Bill-Gray/PDCurses/master,
and there has been no activity on wmcbrine/PDCurses/master since this
version was forked."

Seems to me this ought to simplify the problem, but as a Git
newbie, I may be overlooking something.

-- Bill

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#6 (comment)

[luke-jr]

The purpose of runtime selection would be to avoid opening a separate window when invoked from a command prompt.

[techtonik]

@Bill-Gray I would try to split it into several small logical changes using:

git branch smallchange   # create new branch from where you are
git checkout smallchange # switch to new branch
git rebase -i HEAD~50     # edit last 50 commits on new branch, remove extra, squash

If you fork smallchange branch from you current master, all removed commits will still be available from your `master.

[Bill-Gray]

Hi Anatoly,

There are several problems here. Some of them may seem troublesome
to me only due to my lack of Git knowledge, I hope. The most basic
problem is uncertainty as to whether these changes are welcome in
wmcbrine/PDCurses in the first place.

I know that William has some reservations about the proposed changes
in Win32a. I'm not entirely sure what they are. It may well be that
we will stay forked, or that William would like some of the changes
but not others. I'd prefer to combine our efforts, but should make
it clear that I'm okay with it if these changes are rejected. I've
drawn on updates submitted to wmcbrine/PDCurses, such as Laura Michaels'
improvements for SDL and Mark Hessling's X11 improvements, and expect
to continue to do so.

I'm not very interested in splitting things up until I know which,
if any, of the Win32a modifications might actually make it into the
"official" PDCurses. With that out of the way :

The changes I've submitted begin with a huge dose of changes made
from March 2010 to January 2016 that predate the move to GitHub. These
are only documented on my page at

http://www.projectpluto.com/win32a.htm

which is nearly useless for GitHub purposes. Ideally, I'd have been
using GitHub back then, and all the various changes tracked on that page
would be much more readily tracked via GitHub. But I didn't do that.
Those changes appear as a massive blob of a commit on 2016 January 13,
"initial Win32a version added". It would be hard to break those up,
after the fact, into a series of commits (lovely though that would be).
Following the move to GitHub, though, the commits are a series of
small logical changes. (I actually was able to separate out some of the
2010 to 2016 work as smaller commits, though not as much as one would
ideally wish.)

Since I submitted this pull request back in January, by the way, I've
made several dozen commits to Bill-Gray/PDCurses. If there is actually
some desire to incorporate my changes into wmcbrine/PDCurses, I'd
be submitting a new pull request that is somewhat more up to date
than the original one.

-- Bill

On 2016-08-11 05:58, anatoly techtonik wrote:

@Bill-Gray https://github.com/Bill-Gray I would try to split it into several small
logical changes using:

|git branch smallchange # create new branch from where you are git checkout smallchange #
switch to new branch git rebase -i HEAD~50 # edit last 50 commits on new branch, remove
extra split |

If you fork |smallchange| branch from you current master, all removed commits will still
be available from your `master.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#6 (comment), or mute the thread
https://github.com/notifications/unsubscribe-auth/AP6BrkJ4DmLDVLXi2FQTT4DR-z3LqRE7ks5qevJMgaJpZM4HEZFA.

[techtonik]

Hi @Bill-Gray. This will never be merged unless somebody helps you to split this huge piece of work into separate small pull requests - one feature per request. It is very hard to review big pieces of code when people have only got about 15 minutes of free time on their side project such as PDCurses during the day (or even week). I spent 5 from 15 already by answering. =)

[Bill-Gray]

On 2016-10-24 04:32, anatoly techtonik wrote:

Hi @Bill-Gray https://github.com/Bill-Gray. This will never be merged
unless somebody helps you to split this huge piece of work into separate
small pull requests - one feature per request. It is very hard to review
big pieces of code when people have only got about 15 minutes of free
time on their side project such as PDCurses during the day (or even week).
I spent 5 from 15 already by answering. =)

I'm pretty much proceeding under the assumption that it won't get
merged, and that the fork is a permanent one.

I also don't see this as a big problem. We will effectively have
"classic" PDCurses at wmcbrine/PDCurses, which doesn't change much except
for occasional bug fixes. And we'll have "new and improved" PDCurses at
Bill-Gray/PDCurses, with the Windows GDI flavor and assorted changes.

I perhaps should have pushed harder for a merge back in March 2010
when this fork was in its infancy. Had I done that, and/or if I'd been
using Git so that there would be a series of small commits rather than
the massive blob of a commit dropped on William last January, then a
merge might be more likely. (Or, at least, a merge of some of the
features of this fork.)

But at this point, breaking up the changes between March 2010 (when
Win32a started) and January 2016 (when I moved to GitHub) would be a huge
project and might not get pulled in anyway. (Or only certain bits and
pieces would get pulled, and we'd have two versions anyway.)

Unless I hear objections, I'll withdraw this pull request and the
two forks can go their separate ways in peace.

-- Bill

[wmcbrine]

Although I've taken many of the other changes here into my tree, I have yet to include the actual "Win32a" port, because I would've had to dumb it down to fit it into the intentionally limited framework of 3.5 (in particular, no 64-bit chtype, nor anything that depends on it), only to build it up again later. But I do plan to include it in a future version (soon), that more radically revamps PDCurses.

[Bill-Gray]

Glad to hear this is apt to happen, and I agree with your strategy of getting other bits, such as 64-bit chtypes, in place first (and you've been getting some pieces of the puzzle into place: bold/italic fonts, real blinking, etc.)

As best I can tell, the main obstacle to merging the Win32a port and associated changes is that it's a significant pain in the anatomy. Nothing that's rocket surgery, but it's a lot of changes. I don't think there are major philosophical differences to be bridged (and I'm quite flexible on minor philosophical differences).

If you see changes I could make in my fork that would simplify the process, please let me know. (One that I've started on is applying some of your changes, where possible/appropriate, to my fork, thereby making them at least slightly less "different". There's quite a bit more that I can do there, though.)

[GitMensch]

@Bill-Gray Can you please give a short update about "back-merging changes of this repo to your fork"? I think it would be good to do so (and provide a new release in the other repo to verify that all the changes work before more approaches are done to merge the two repos).

@wmcbrine Can you please give a short update/details about 64bit chtype addition and other changes you see necessary before '(fully) merging the Bill-Gray fork (especially win32a)?

[Bill-Gray]

@GitMensch : not entirely sure what you mean by this...

I've been pleased to see a lot of interesting things in @wmcbrine's updates in the last few months, and have gotten around to putting some of his fixes and improvements into my fork. I was rather impressed that William found a way to get blinking text and 256 colors in the Win32 console. I'd be grabbing still more of his improvements, but I've some contract work that has been taking most of my time for a while now. I'm also just glad to see that "official" PDCurses has some life to it.

Unfortunately, we've now diverged a lot. Previously, I'd kept up with William's changes, so that my fork was essentially "official" PDCurses plus changes. A merger now would be painful, though not impossible, if William is so inclined. It would probably start with adding 64-bit chtypes. Doing that would not really be very difficult. I think that at that point, the Win32a code could simply be slurped in. Since "official" PDCurses doesn't have Win32a at all, there would be no issue with conflicts with existing code.

After that, we could put dimmed, overlined, blinking, struck-out, RGB, full Unicode, etc. capabilities into other platforms that can support them (basically X11 and SDL1 and 2). That would take some more serious effort, but shouldn't be rocket surgery, especially since all of it does already work in the forked version. But again, I've no idea if William is interested in this, and this is his repo.

[Bill-Gray]

I'm assuming this is essentially a fossil pull request, and am closing it.