New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Win32a changes submitted #6

Open
wants to merge 352 commits into
base: master
from

Conversation

@Bill-Gray
Contributor

Bill-Gray commented Jan 13, 2016

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

This comment has been minimized.

Show comment
Hide comment
@TheGentzy

TheGentzy Mar 23, 2016

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.

TheGentzy commented Mar 23, 2016

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 comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Mar 23, 2016

Contributor

This needs to be rebased to solve conflicts.

Contributor

techtonik commented Mar 23, 2016

This needs to be rebased to solve conflicts.

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Mar 23, 2016

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

luke-jr commented Mar 23, 2016

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

#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 */

This comment has been minimized.

@luke-jr

luke-jr Mar 23, 2016

What if CHTYPE_16 is defined?

@luke-jr

luke-jr Mar 23, 2016

What if CHTYPE_16 is defined?

This comment has been minimized.

@Bill-Gray

Bill-Gray Mar 23, 2016

Contributor

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

@Bill-Gray

Bill-Gray Mar 23, 2016

Contributor

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

Show outdated Hide outdated curses.h
@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Mar 23, 2016

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)?

luke-jr commented Mar 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Mar 23, 2016

Contributor

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.

Contributor

techtonik commented Mar 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Mar 23, 2016

Contributor

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.

Contributor

techtonik commented Mar 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Bill-Gray

Bill-Gray Mar 23, 2016

Contributor

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)

Contributor

Bill-Gray commented Mar 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Bill-Gray

Bill-Gray Mar 23, 2016

Contributor

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)

Contributor

Bill-Gray commented Mar 23, 2016

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

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Mar 23, 2016

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

luke-jr commented Mar 23, 2016

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

@techtonik

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Aug 11, 2016

Contributor

@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.

Contributor

techtonik commented Aug 11, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@Bill-Gray

Bill-Gray Aug 11, 2016

Contributor

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.

Contributor

Bill-Gray commented Aug 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@techtonik

techtonik Oct 24, 2016

Contributor

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. =)

Contributor

techtonik commented Oct 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@Bill-Gray

Bill-Gray Oct 25, 2016

Contributor

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

Contributor

Bill-Gray commented Oct 25, 2016

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

Bill-Gray and others added some commits Oct 26, 2016

'color test' now shows only the features available with a certain
configuration,  instead of trying to show a few that may not work
with shorter chtypes or in non-wide or wide modes.
Create new SDL2 port based on Laura Michaels' patch
The patch was originally intended to be applied to the existing
SDL port. However, as SDL2 is arguably a separate platform, altering
the existing SDL port is disallowed by the Implementor's Guide.
Fix SDL2 rendering
The pdc_render and pdc_texture globals are no longer needed.
Implement proper text input through the SDL2 TextInput API
Input using SDL_KEYDOWN was limited to characters with a dedicated
US-layout keyboard key (e.g. shift-2 produced 2 instead of @).
Textual input is now handled through the SDL_TEXTINPUT event, giving
the proper character for the current keyboard layout. This includes
Unicode input support for WIDE builds.

Bill-Gray and others added some commits Jul 16, 2018

In testcurs 'input' test, you can hit Ctrl-A if you just want to do t…
…he first test (which is all I usually am interested in)
Revised resize_term() documentation to reflect new platforms and the …
…ability (in this fork) to set the initial size of the terminal on four platforms.
Fixed pre-initscr() use of resize_screen() on the VT platform. Also f…
…ixed potential (likely) issues with not waiting for both row _and_ column sizes to be set.
Cursor left off by one column upon exit (forgot coords are zero-based…
…, not one-based). Also added a line feed at the end to put output just below what we've just created.
Update README.md
fixed wincon link, added some explanation
Merge pull request #75 from tkchia/wcc-stuff
Patch to unify 16-bit and 32-bit Watcom C/C++ makefiles
Simplified screen updating logic for palette changes and color pair c…
…hanges. When those happen, we should redraw any text with matching attributes. Also set up for similar redrawing of blinking (and/or bold or italic) text; see following commit.
See preceding commit: when we switch from 'really blinking' text to '…
…blinking text is just highlighted', then all A_BLINK text has to be redrawn. And now, we can do that.
Current xterm and QTerminal will set COLORTERM=truecolor if they do, …
…in fact, support true color. So if that's set, we can draw RGB text (see pdcdisp.c.)
Update Makefile.mng
fixed old demo name that got in back with d052f0f
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment