To-do list (possibilities)

[Bill-Gray]

I don't expect to do anything with this project for a while (way behind on other projects). By the time I do, I may well have completely forgotten all of the following. This will serve as an aide memoire if that happens. But you can be pretty sure that none of it is going to happen any time soon... well, if it does, the credit will go to somebody else.

It is in absolutely no order whatsoever (and at least some open issues would take priority). Please feel free to add to the list or tackle items on the list, but this is mostly just something to remind me a few months/years from now of possible projects.

(Updated 2022 July 13 to remove items that have actually been done.)

• I got a start on code to configure curses.h; see issue How to evade library mismatches? #133 and search for 'a bit of code to configure/reconfigure'. Ideally, if you ran make with a particular combination of WIDE, UTF8, DLL_BUILD, etc. flags, curses.h would be appropriately modified. In some ways, this one isn't a big deal. config_curses works quite well. It's just that PDCursesMod has a lot of ports and makefiles to test.
• Pull out PSF/PSF2 font handling from the framebuffer port, put it into the common directory, and modify the DOSVGA and possibly SDL1 and SDL2 ports to make use of it. This is largely in the category of eliminating redundant code; we currently have two different implementations of PSF parsing, and SDL1/2 get fonts (in 8-bit character mode) from a .BMP file with no counterpart in the rest of the universe. (See issue Use of PSF2 fonts; possible Linux framebuffer port #208 for further discussion of this.)
• After or in parallel to that : the framebuffer port has a built-in PSF font as a static array, and the ability to load one or more PSF fonts and to switch among them by hitting Alt-Minus. It'd be nice to have a mechanism for specifying fallback fonts ("if you can't get the desired glyph from the default font, look in this one or this one"), with the glyph resized as needed (not really difficult to do). If you use Unifont as your "final fallback", you've got at least a passable glyph for any situation. (At present, only the WinGUI port has a fallback font option.)
• It'd also be nice to have fullwidth characters with PSF2 fonts. That'd be tricky, since PSF* was designed with the idea that all glyphs would be the same size. It might fit with the above scheme of fallback fonts, though, with the fullwidth characters put into a separate font.
• Clipboard functions for the VT port in Linux. The downside to that is that (I think) you have to drag in all the X libraries to do it. We might be able to make that code that is common between the X11 and VT/Linux ports. I've also sometimes wished I had access to both the 'clipboard' and 'selection' buffers (this is a really useful distinction of which Windows, sadly, is unaware).
• It appears that the use of the Linux framebuffer is somewhat deprecated. The code could be modified to use the Direct Rendering Manager without a lot of trouble. From the standpoint of our code, it doesn't make much difference; we're still just looking at a flat memory-mapped array of pixels. It's just a difference in how we get a pointer to that array. Probably not a big deal, since it appears framebuffer access isn't going anywhere and does not (from our humble viewpoint) have any real drawbacks.
• Direct access to the mouse and keyboard in the framebuffer port would be useful, though there appears to be no agreement on how that ought to be done.
• A 'touchscreen' mouse mode might be interesting. In this mode, instead of having buttons 1, 2, 3, etc., we would have fingers 1, 2, 3, etc., and they would have press, move, and release events. It would be entirely possible to have "'button` 1 was pressed here, moved here, then 'button' 2 pressed here, both 'buttons' may move around, then one or the other is released." A button 'number' N would simply mean that at the time it was pressed, N-1 other fingers were currently being kept track of. I have a cellphone that runs Linux, and have done no programming on it, but it'd be nifty to run PDCurses programs on it.