[PDCurses] Update to Win32a flavor posted
Hello all,
I have posted yet another update to the Win32a ("real Windows GUI") flavor
of PDCurses, at
http://www.projectpluto.com/win32a.htm
Please let me know if you run into any issues.
Specifically, this version fixes a problem with Windows 7 that resulted
in very strange-looking windows; and there is a font selection dialog
available so that one can select fonts other than the default Courier New.
(Some restrictions apply. Some fonts lack extended characters required for
boxes and alternate character set symbols. Many will work Just Fine, but
don't have characters beyond ASCII 255... not a problem for some, though,
and if you've been using SDL, you've had that limitation all along anyway.)
I've had several comments to the effect that having this just hosted on
my Web site is not ideal. Next step will be to either get Win32a merged in
with "official" PDCurses, or failing that, put it on GitHub or SourceForge
as a fork.
-- Bill
[PDCurses] Win32a update posted
Hello all, Mark Hessling provided a fix to a rather serious bug in the Win32a (graphical) flavor of PDCurses. It turns out that the way Win32a stored font and screen size preferences in the Windows registry required administrative privileges in Vista and Win7 (and, at least in some cases, XP). If you weren't an administrator, ran a Win32a app, and changed the font or screen size or menu display, you'd find that the next time you ran that app, all of your settings would be lost. See http://www.projectpluto.com/win32a.htm for the current version. (Which includes a few other small fixes, to SLK handling and to allow 64-bit chtypes on the Win32 console flavor of PDCurses. -- Bill
[PDCurses] Update to Win32a flavor of PDCurses posted
Hello all, I've posted an update, described at and downloadable from http://www.projectpluto.com/win32a.htm This contains several bug fixes, most notably a patch supplied by Florian Große-Coosmann to get around a problem with the handling of wide input. Depending on when you last downloaded the code, you may see still more changes; I've made improvements/fixes without mentioning them on this list. Comments/bug fixes are, as always, welcome. -- Bill
Re: [PDCurses] PDCurses and SDL2
Hi Laura, For Win32a, I added the options of 64-bit chtypes, allowing 21 bits for the character, which covers all of Unicode. (As well as providing the additional bits needed to support attributes such as A_DIM, A_ITALIC, A_OVERLINE, etc. that don't fit in 32-bit chtypes.) I think if you borrowed curses.h, you'd have a decent start on getting full Unicode in your SDL2 version. Win32a also allows for entry of hex or decimal Unicode via the keypad (though this was only posted about five days ago!), but borrowing from Win32a might be a little more difficult here. Still probably worth checking, though. BTW, I have to agree with you on Wine overhead. Wine is a lovely solution, in the sense that it's enabled me to take a lot of my old Windows code and, with only minor tweaks, get it to run at full speed flawlessly in Linux. But it's a bit large. Understandably so, given what it has to do, but I'm still hoping this SDL2 solution pans out. -- Bill On 01/27/2015 07:23 AM, LM wrote: I compared the demos using SDL1 and SDL2 with SDL2_TTF support. Results are very similar. Ran the clipboard test in testcurs and it works very nicely with SDL2 clipboard support. The biggest design issue I see is Unicode support. Looking through the code, chtype is set by default to handle 16 bits for the attributes and 16 bits for the character. On Windows systems, wchar_t is also limited to 16 bits. The testcurs ACS test shows some internationalized characters when PDC_WIDE is set true. However, I don't see any code to handle anything beyond the first 16 bits of a Unicode character set. So, for full Unicode support, one would at least need to modify the size of chtype and deal with wchar_t representing UCS-2, UTF-16 or UTF-32, etc. depending on the platform. Also, on Windows (Win32), one can input non-standard characters via the keyboard using Alt and the keypad keys. It would be nice to have a similar mechanism that works with SDL. It's difficult to determine when a user hits Alt and 0 on the keypad whether they want back the keypad character on the key down event or whether they want what the next series of key-presses converts to in a Unicode representation. That makes it difficult to code a solution to inputting Unicode characters that suits every case. Sincerely, Laura
Re: [PDCurses] Mirror on bitbucket, SDL2
Some quick comments... I've been meaning to look into the bitbucket mirror. As you may know, I've "managed" Win32a by doing development on my machine and uploading a .zip file every now and then. This works, but it's conceivable that putting it on bitbucket might draw in some development effort. For example, I was trying to compare the win32a code, which seems to have come from a fork of CVS prior to the the 2014 changes. Last I checked, I'd incorporated the CVS changes. (Which was easy enough to do; they were minor bug fixes. Not much going on there these days.) I'd love to see a full-featured SDL2 port with all the goodies in the win32a port. I'd be interested in this too, but only if it supports Unicode. 8-bit character sets are _so_ Second Millennium... Such support is quite possible. SDL currently handles fonts as very simple bitmaps; one could just make those bitmaps larger. Really quite a bit larger if one wants most/all of Unicode, but it shouldn't be a big deal to do it. Do you have a table with comparison of win32a port goodies with everything else? That is probably something I should put together. Most of the differences are described at http://www.projectpluto.com/win32a.htm . I _think_ combining this with the other flavors (SDL, OS/2, DOS, console Win32, etc.) will just be a matter of recompiling -- backward compatibility has been a top priority -- but must admit it's been a while since I tried doing that. Just doing that gets you some of the Win32a features, such as better SLK support, and leaves you well-positioned to add things such as overlined, dimmed, italic, bold, and struck-out text. Coincidentally, I just posted an update to Win32a at the above URL. The main change is that fullwidth characters are now supported (should be very useful to the Chinese/Japanese/Korean crowd; they have a lot of glyphs that are supposed to consume two columns, but which are restricted to one on all current PDCurses) and combining characters are supported. -- Bill
Re: [PDCurses] key mappings
Hi Laura, As you found, there's no real consistency among implementations as to the exact values. Try to write something that works with both PDCurses and ncurses, for example, and you'll have some code that looks like #ifdef KEY_EXIT if( key == KEY_EXIT) do_stuff( ); #endif #ifdef KEY_B3 if( key == KEY_B3) do_b3_stuff( ); #endif I see I have an '#ifdef ALT_0' in one bit of code, so even that cannot be uniformly relied upon. Now, in terms of what we _should_ do... I guess I'd rather like the idea that we minimize the number of keys. Rather than have an 'A' and an 'Alt-A', you'd have an A with the Alt modifier set. I say that despite having added a hundred or so key codes to the Win32a flavor of 'curses.h' (look in that file for the section starting with CTL_SEMICOLON). I figure that if we have all these keys (I have a keyboard with 'browser back/forward', 'refresh', 'search', etc. keys), we ought to be able to access them. But I do have KEY_VOLUME_DOWN, KEY_SVOLUME_DOWN, KEY_CVOLUME_DOWN, and KEY_AVOLUME_DOWN as four separate key codes. Incidentally, you'll also see that in the Win32a version of 'curses.h', the return values are relative to KEY_OFFSET. The reason for this is that PDCurses' "usual" values assume a non-wide version, and they start at 0x100. Try making a Unicode build, and there will be collisions: if you get, say, 0x16B, did your user hit KEY_MESSAGE, or an 's with acute accent'? Further details at http://projectpluto.com/win32a.htm#2014mar1 , but essentially, we put the KEY_ values into Unicode's Private Use Area, where it cannot collide with any actual key value somebody using an Absurdistani keyboard layout might generate. -- Bill On 04/08/2015 03:35 PM, LM wrote: I'm trying to double-check that the keys are mapping properly for SDL. The only documentation on keys that I could turn up was at: http://pubs.opengroup.org/onlinepubs/7908799/xcurses/curses.h.html Does anyone have a list of what key values should be returned for what key combinations. curses.h has some values defined such as ALT_0 - ALT_9 and ALT_A - ALT_Z. A curses application like hexedit uses CONTROL_A - CONTROL_Z and CONTROL_SLASH which aren't even documented by pdcurses. Checking the various back-ends of pdcurses, even its key translations don't seem to agree with each other. Some pdcurses back-ends return ALT_BSLASH and some return the backslash with alt modifier set. Does anyone know where to find documentation on what should be valid key return values or does anyone have recommendations on how they'd like to see this consistently handled? It would be nice to have better compatibility with what ncurses does if possible. Thanks.
Re: [PDCurses] key mappings
Thank you. I see what you mean: the get_wch() method looks as if it's applicable to ncurses and all PDCurses... in other words, pretty much everything. The SP->key_code method, and the method Florian and I used in Win32a, will only work in PDCurses. (Unless we persuaded the ncurses people to change their ways. And even then, you'd have the old libraries out there. So get_wch() wins.) I don't see much need to revise my code, but I'll add a note to the effect that "while this works, you're better off using get_wch() and checking the return value." -- Bill On 04/08/2015 06:28 PM, William McBrine wrote: On Wed, Apr 8, 2015 at 5:17 PM, Bill Gray wrote: Incidentally, you'll also see that in the Win32a version of 'curses.h', the return values are relative to KEY_OFFSET. The reason for this is that PDCurses' "usual" values assume a non-wide version, and they start at 0x100. Try making a Unicode build, and there will be collisions: if you get, say, 0x16B, did your user hit KEY_MESSAGE, or an 's with acute accent'? Florian Große-Coosmann wrote to me about this a while back. Here's what I said then: It's not necessary to relocate the key definitions in order to distinguish the control keys from regular Unicode input. One must simply use get_wch() instead of getch(), and check the return value (KEY_CODE_YES or OK), as well as the character result (which is placed at the location given by the parameter). Alternatively, if you don't care about using standard curses wide-character functions, you can continue using getch(), but check the PDCurses-specific SP->key_code to determine whether or not the result is a "special" key. However, I recommend get_wch(). These capabilities date to 2006, BTW.
[PDCurses] Update to Win32a posted: trying to "re-unify" PDCurses
Hello all, I've just posted an update at http://www.projectpluto.com/win32a.htm This has a few bug fixes in it, and adds a makefile for the Intel(R) compiler. But the big change is that I'm trying to get things such that the Win32a changes can be merged back into "mainstream" PDCurses, and at least some of its improvements conveyed to other flavors. (There is, as best I can tell, no real reason for forking here.) Current progress is discussed at http://projectpluto.com/win32a.htm#2015may31 Short version: the Win32 console, DOS, X11, and SDL1 flavors all get at least some benefit from the Win32a changes. I obviously can't support overlined or struck-out text in DOS or Windows console, for example, and there are limits to how far I've gone with the other flavors thus far. However, the road is now paved for full RGB and full Unicode support for X11 and SDL. Note that I couldn't try out OS/2 or FlexOs. -- Bill
Re: [PDCurses] Update to Win32a posted: trying to "re-unify" PDCurses
Hi Anatoly, I've been sidetracked by several other projects. I really should do this, though... it would be relatively easy to put the Win32a changes in to the new hosting at this point, and I should do it before there's much divergence between what I've got and what is on github. (A quick look at the github version tells me that a fair bit of divergence has occurred -- there are a lot of things "reformatted slightly, markdown-style", and the Win32 console flavor has been heavily revised for the "new Win32 console API". Shouldn't be too tough to re-sync, though.) Once we're re-synced, I will probably attempt to extend the X11 version to include full colors, bold/italic text, "real" blinking text and cursor, recognition of all keys, etc... in other words, the improvements Win32a already has. -- Bill On 01/10/2016 10:59 PM, anatoly techtonik wrote: Hi Bill, How it's going? Have you tried submitting pull requests to the new hosting - https://github.com/wmcbrine/PDCurses ? On Sun, May 31, 2015 at 11:37 PM, Bill Gray wrote: Hello all, I've just posted an update at http://www.projectpluto.com/win32a.htm This has a few bug fixes in it, and adds a makefile for the Intel(R) compiler. But the big change is that I'm trying to get things such that the Win32a changes can be merged back into "mainstream" PDCurses, and at least some of its improvements conveyed to other flavors. (There is, as best I can tell, no real reason for forking here.) Current progress is discussed at http://projectpluto.com/win32a.htm#2015may31 Short version: the Win32 console, DOS, X11, and SDL1 flavors all get at least some benefit from the Win32a changes. I obviously can't support overlined or struck-out text in DOS or Windows console, for example, and there are limits to how far I've gone with the other flavors thus far. However, the road is now paved for full RGB and full Unicode support for X11 and SDL. Note that I couldn't try out OS/2 or FlexOs. -- Bill
Re: [PDCurses] Update to Win32a posted: trying to "re-unify" PDCurses
Hi Anatoly, I expect I'll be doing things exactly that way (submitting patches). Actually, it'll be a mix of patches to existing code, some of them quite large, plus the entire Win32a folder as "new code". I'm not at all familiar with Git. (I'm self-employed and haven't had to "work well with others" until now... though I realize there are good reasons for solo programmers to use version control, too. I figure this will be an opportunity for me to learn some useful new tools.) -- Bill On 01/11/2016 10:56 AM, anatoly techtonik wrote: Hi Bill, Do you use version control? If so, then you can convert your changes into series of patches and go through the changes one by one. Once you get familiar with Git, you can maintain you own branch of patched and rebase it periodically to make you changes on top. On Mon, Jan 11, 2016 at 6:10 PM, Bill Gray wrote: Hi Anatoly, I've been sidetracked by several other projects. I really should do this, though... it would be relatively easy to put the Win32a changes in to the new hosting at this point, and I should do it before there's much divergence between what I've got and what is on github. (A quick look at the github version tells me that a fair bit of divergence has occurred -- there are a lot of things "reformatted slightly, markdown-style", and the Win32 console flavor has been heavily revised for the "new Win32 console API". Shouldn't be too tough to re-sync, though.) Once we're re-synced, I will probably attempt to extend the X11 version to include full colors, bold/italic text, "real" blinking text and cursor, recognition of all keys, etc... in other words, the improvements Win32a already has. -- Bill On 01/10/2016 10:59 PM, anatoly techtonik wrote: Hi Bill, How it's going? Have you tried submitting pull requests to the new hosting - https://github.com/wmcbrine/PDCurses ? On Sun, May 31, 2015 at 11:37 PM, Bill Gray wrote: Hello all, I've just posted an update at http://www.projectpluto.com/win32a.htm This has a few bug fixes in it, and adds a makefile for the Intel(R) compiler. But the big change is that I'm trying to get things such that the Win32a changes can be merged back into "mainstream" PDCurses, and at least some of its improvements conveyed to other flavors. (There is, as best I can tell, no real reason for forking here.) Current progress is discussed at http://projectpluto.com/win32a.htm#2015may31 Short version: the Win32 console, DOS, X11, and SDL1 flavors all get at least some benefit from the Win32a changes. I obviously can't support overlined or struck-out text in DOS or Windows console, for example, and there are limits to how far I've gone with the other flavors thus far. However, the road is now paved for full RGB and full Unicode support for X11 and SDL. Note that I couldn't try out OS/2 or FlexOs. -- Bill
[PDCurses] Win32a now on Github, with some X11 changes
Hello all, I've forked the version of PDCurses on Github, and folded in the Win32a changes. It's now at https://github.com/Bill-Gray/PDCurses It is somewhat modified from the version on my Web site at http://www.projectpluto.com/win32a.htm in that I've fixed up the X11 flavor of PDCurses to allow most of the things the Win32a fork does: RGB colors, triple mouse clicks, overlined and strikeout and dimmed text, 256 colors and 256 color pairs, and fullwidth characters. The X11 flavor now also recognizes most keys, such as the "back" and "forward" and "refresh" and such special keys on some keyboards. (Almost all my development these days is in Linux, so the X11 flavor has become somewhat important to me.) Ideally, I'd also extend the X11 flavor to have "real" bold and italic fonts, programmatic resizing, "real" blinking text, and the ability for the user to choose a font... no promises that I'll get quite that far, though. I've put in a pull request, so this may eventually end up in "mainstream" PDCurses. (And on a side note, my thanks to Laura for the pointer to CDetect. It looks like a generally useful tool... probably helpful with PDCurses, but definitely useful for some of my own projects. Anatoly, I don't know of any "attempt to define standard set for those #define's and their meaning across compilers", and I could see some real problems in doing so. Which is why I'd think a CDetect that can figure out what headers, functions, etc. are available on a given system ought to be quite useful.) -- Bill
Re: [PDCurses] Win32a now on Github, with some X11 changes
On 01/18/2016 01:31 AM, Mark Hessling wrote: I've forked Bill's fork so I can get the changes I've made to the X11 port (XCurses) made available. Some nice changes here. I've pulled them in to my fork, and it looks as if they are now ready to be merged into the "official" version at https://github.com/wmcbrine/PDCurses . -- Bill The changes are: - support for "proper" bold font. Note that the user CAN select what font they want by adding entries to their ~/.Xresources file - added the ability to build a shared library with ABI versioning - ability to build XCurses from anywhere, not just in the PDCurses/x11 directory. I need this as I often build debug/wide etc versions for testing - targets for building a Debian .deb and RedHat .rpm package - build multiple architectures in a fat binary on MacOS X - made PDC_set_function_key() available on all platforms, and implemented shutdown capability on X11 My fork is at: https://github.com/rexx-org/PDCurses I've created a Pull Request for Bill Cheers, Mark On 18/01/16 01:49, Bill Gray wrote: Hello all, I've forked the version of PDCurses on Github, and folded in the Win32a changes. It's now at https://github.com/Bill-Gray/PDCurses It is somewhat modified from the version on my Web site at http://www.projectpluto.com/win32a.htm in that I've fixed up the X11 flavor of PDCurses to allow most of the things the Win32a fork does: RGB colors, triple mouse clicks, overlined and strikeout and dimmed text, 256 colors and 256 color pairs, and fullwidth characters. The X11 flavor now also recognizes most keys, such as the "back" and "forward" and "refresh" and such special keys on some keyboards. (Almost all my development these days is in Linux, so the X11 flavor has become somewhat important to me.) Ideally, I'd also extend the X11 flavor to have "real" bold and italic fonts, programmatic resizing, "real" blinking text, and the ability for the user to choose a font... no promises that I'll get quite that far, though. I've put in a pull request, so this may eventually end up in "mainstream" PDCurses. (And on a side note, my thanks to Laura for the pointer to CDetect. It looks like a generally useful tool... probably helpful with PDCurses, but definitely useful for some of my own projects. Anatoly, I don't know of any "attempt to define standard set for those #define's and their meaning across compilers", and I could see some real problems in doing so. Which is why I'd think a CDetect that can figure out what headers, functions, etc. are available on a given system ought to be quite useful.) -- Bill
[PDCurses] Updates to Win32a fork
Hello all, I've made various changes to the Win32a fork of PDCurses at https://github.com/Bill-Gray/PDCurses In the past few days, I've added real blinking to X11 (i.e., "blinking" text really blinks if PDC_set_blink( true) is called, or it's just highlighted if it's not); modified the Win32a mingwin32.mak file to support 64-bit and 32-bit builds; and added a makefile for DOS for the Digital Mars C/C++ compiler. (Which is very useful to me; it's the only way I have left to test out 16-bit builds or DOS builds. Turns out I can fire up a command shell using Wine, compile within it using DMC, then run the DOS executable using DOSBox.) I'm still hoping all this will eventually make it into the "mainstream" version of PDCurses -- I put in a pull request a while back -- but it'll be a lot to merge in, and it may be that some aspects of Win32a remain forever forked. -- Bill
Re: [PDCurses] Custom font with PDCurses 3.6 / SDL2
Not that I'd see this as a major issue, but perhaps something along the lines of changing line 200 in pdcscrn.c from if( !pdcfont) to if( !pdcfont || pdcfont->format->BitsPerPixel != 1) might provide suitable warning? Or possibly adding lines to check that we've got one bit per pixel and that the bitmap is a multiple of 32 in width and of 8 in height would be useful : assert( pdcfont->format->BitsPerPixel == 1); assert( pdcfont->w % 32 == 0); assert( pdcfont->h % 8 == 0); -- Bill On 2018-03-24 16:17, William McBrine wrote: On Sat, Mar 24, 2018 at 3:09 PM, Karl Garrison wrote: Also, I don't see this in the docs anywhere, but it took me a bit to realize that the BMP needed to be 1 BPP. ... I suggest adding a note to the documentation about the BMP depth requirement Ahem... "The font is a simple BMP, 32 characters wide by 8 characters tall, preferably with a palette. (BMPs without palettes still work, but in that case, no attributes will be available, nor will the cursor work.) The first entry in the palette (usually black) is treated as the background color; the last entry (usually white) is treated as the foreground. These are changed or made transparent as appropriate; any other colors in the palette are passed through unchanged. So -- although a one-bit depth is sufficient for a normal font -- you could redraw some characters as multi-colored tiles." That's from doc/sdl.md (combined into PDCurses.md, if you build that). It's been there since 2007.
