Implement menu and forms library

[wmcbrine]

Implement menu and forms library

[guilt]

Okay, I'll start looking into it. I haven't used these a lot myself, but they look like quite useful functions when people make applications with them.

[wmcbrine]

I'd love to see portable versions of these; unfortunately, the ncurses versions aren't. From time to time, I hear about someone working on it, but I've yet to see it finished.

[GitMensch]

@guilt I suggest starting with a new demo that uses the ncurses functions (and work there) and then go on with the actual PDCurses implementation.
I'm quite sure both will be a very useful addition and suggest starting with the menu API (we already have samples that use menus in PDCurses).

[wmcbrine]

I should clarify something. I'd really rather see portable versions of these than PDCurses-specific ones, and I doubt that PDCurses-specific features are necessary to implement the libraries. Either way, though, I don't intend to expand the scope of PDCurses by adopting these as part of it. They're huge on their own, entail a lot of support, and should IMHO remain a separate project. (That would also free developers up to, for example, take the ncurses versions and make them portable while retaining the ncurses license, without having to worry about the public domain.)

I've kept this issue open since this is a thing that comes up from time to time, but with the current direction of discussion, I fear it creates the wrong impression.

[wmcbrine]

Clipping is not contemplated. Working like ncurses means returning the requested size, even if parts of it are off-screen.

[GitMensch]

@guilt Can you picture yourself adding these after #59 is merged?
For reference... Bill-Gray/PDCursesMod#100

[guilt]

Hi,

Just logged in today. This means, if done right, it still may not be part of PDCurses?

We had panel.h, which is a Level-2 library, so I thought this would be a similar implementation. Okay, I would be happy if there were a way to treat it similarly.

I would definitely want to work on it and keep the patch out there, so when you find it comfortable to get it in, you'd vet it. I am trying to develop small, WIP patches after all. But I'd trust you know the internals and usages way better than I do.

[GitMensch]

Thank you @guilt for your interest. What William said was: it seems to not be as reasonable to include these directly as the panel stuff which is much more interacting with the curses windows.
He does see it as beneficial but not the need to directly incorporate this into PDCurses and suggest creating a new library that exposes the existing ncurses API as external functions and internally use the pdcurses API (ideally we have everything necessary in already) to provide the necessary functions.

This does indeed has a lot of benefits:

• usable with different versions of PDCurses (including older ones [software repos are sometimes outdated])
• usable with BSD and other curses versions as long as you keep on the core API, and even if not - possible to get working with other curses versions
• more lightweight for PDCurses: neither "always included" nor "makefiles and sources intermixed with defines to disable/enable it"

So the big question is @guilt: Do you create a repo with a new library (maybe two repos: one for curses-menu and the other one for curses-forms) for this task? I may could help a little, with things like setup/CI/compatibility/releases...

[tysenmoore-xse]

If anyone is interested I was able to port the ncurses-st-menu menu implementation to PDCurses. The overall project looks really good. For those interested you can have a look at my fork.

I have only tested the PDCurses X11 on Ubuntu 16.04 and Windows 10 using PDCurses wincon. The NCurses support is still maintained.

[GitMensch]

@tysenmoore-xse That sounds quite nice and I like those changes. Can you add additional screenshots for PDCurses X11 in your fork (additional to easy the upcoming PR to upstream)?

@wmcbrine @Bill-Gray Do you see an option to (or reason to not) include the adjustments done for newwin

which has been created to better handle windows that are out of the screen size. PDCurses will not allocate the window [...] ncurses appears to allocate the window just fine.

[wmcbrine]

Yeah, I noticed the oversized window thing a while back. I was actually surprised that ncurses does that, but, emulating it is probably the right thing.

[Bill-Gray]

I could conceivably see a problem here if somebody called newwin for a window of a particular size, parts of which would be off-screen, and then got back a window that was trimmed to the right and bottom edges. Say, they asked for 20 columns and only get 17. At present, you just don't get a window (return value is NULL) in such cases. I'd dislike breaking existing behaviour by clipping the window, but would defer to @wmcbrine's judgment here.
Alternatively, newwin could do no clipping nor checking, and would allocate the entire window; it's just that there would be parts of that window you couldn't see (unless the window was moved). That would require a fair bit of change elsewhere, I think, inasmuch as we'd have to have logic that said : 'use this part of the window, but only the parts that actually land on the screen." At present, you can move windows, but you can't move parts of them off-screen.

[GitMensch]

@wmcbrine Should adjusting newwin be tracked in a separate issue or kept here?

[wmcbrine]

It's premature to think about tracking it, really.

[wmcbrine]

Sorry, ignore me, I blame it on feeling sick. Obviously this does warrant a new issue, even if I won't get to it right away.

[tysenmoore-xse]

@GitMensch

I did push a screenshot to the README and screenshot directory. As for the discussion on my newwin2 creation, I'll defer to you experts.

[Bill-Gray]

I notice that newwin2 lets you have a window stick over the right and bottom edges of the screen. It doesn't let you allocate (or move) a window off the top or left edges. I just did some experimenting with newwin in ncurses, and found that it does have that limitation. You can call newwin with the x and y coordinates for the upper left corner to put the window partly off-screen to the right or bottom, but negative values for x or y fail.
I'd argue that ncurses has it wrong. If you're going to allow windows to go off the right or bottom edge, then the top and left edges should be fair game.

[tysenmoore-xse]

For those interested, the PDCurses compatible menu changes I had forked have been accepted as a PR and merged. The repo can be found here: https://github.com/okbob/ncurses-st-menu