Resize problem

[BruceChen2017]

#include <pdcurses/curses.h>

 void initWin(void) {
     initscr();
     noecho();
     keypad(stdscr, TRUE);
     cbreak();
     if (has_colors())
	  start_color();
 }

 int main(int argc, char const *argv[])
{
  initWin();
  refresh();
  int ch;
  int y, x;
  while ((ch = getch()) != 'q'){
	   if (is_termresized())
		   resize_term(0, 0);
	   getmaxyx(stdscr, y, x);
	   clear();
	   mvprintw(y / 2, x / 2 -20, "size: height:%d, width:%d\n", y, x);
	   refresh();
    }
    endwin();
    return 0;
}    

In above code, I run it and press some key, then I get the size (30, 120).After that I maximize the windows, I get the maximal size. Then I click to make window go back to normal size, I get (30, 117).
By repeating this process(max then normal), maximal size is always the same, but width of normal size will decrease by 3 each time, i.e. (30, 114), (30,111) ....Then window become smaller and smaller. Is it a bug?
In my test, linux ncurses (not pdcurses) work so well that you need not to resize it manually because getmaxyx will get changed size.
I build latest library in Win10 by mingw64

[Bill-Gray]

This example seems to work correctly with SDL2 and X11, and even with the VT and Windows GUI platforms in my fork. (I'm not currently at a machine where I can try Windows console mode.) So I suspect it's an issue specific to the Windows console platform.

I initially couldn't compile with ncurses because that library lacks is_termresized(). Replacing
if (is_termresized())
with
if( ch == KEY_RESIZE)
enabled it to compile, whereupon I found (as Bruce did) that it worked correctly.

[wmcbrine]

Yeah, this is specific to wincon. And yeah, it's a bug, but the bug seems to be on the OS side -- the reduced value is being returned directly by Windows. And I can't see how to work around it.

The reduction factor isn't a constant 3, but rather, it's the width that the scroll bar would have, if there was a scroll bar. (You can see this by playing with the console's font size.) But so far, knowing that doesn't help me solve it.

[aiafrasinei]

Have a question related.
Im using x11 implementation, ubuntu 18.04:

resize_term(100, 100);

Doesnt seem to work , the window is not resized , function return -1 and i get a 24 80 window.

Is this a bug ?

[wmcbrine]

No, it's intentional. Programmatic resizing is not implemented for X11. (I'm trying in vain to find documentation or discussion of this from years ago, but what I remember is that it was Very Strongly Discouraged for X11 apps to do this.)

[Bill-Gray]

@aiafrasinei : note that it is implemented for SDL2, so you could just switch to that.
Alternatively, you can "borrow" a few lines of code from here :
https://github.com/Bill-Gray/PDCurses/blob/master/x11/pdcscrn.c#L58
With this, you can call PDC_resize_screen before initscr to specify a desired initial window size. Note that you still can't programmatically resize the window after initscr is called. For that, your options are SDL or (if you use my fork) VT.
William, your comment about resizing being Very Strongly Discouraged in X11 interests me. I haven't done it, solely because it looked unreasonably difficult (at least to a non-X11-knowledgeable person).
Oddly, ncurses (at least on my Xubuntu 18.04 system with xterm) lacks programmatic resizing, though it seems to me it would be simple enough to add it, as I did in the VT platform. Perhaps Thomas Dickey (author of ncurses) also thinks programmatic resizing in X is VSD.

[wmcbrine]

Well, if you want to set the size before initscr(), you can just use X resources, or even the command line, e.g.:

./appname -cols 90 -lines 30

(X11 only, requires Xinitscr(argc, argv) instead of initscr().) For SDL, you can set the environment variables PDC_COLS and PDC_LINES. (Or you can manually create the SDL window, as in sdltest.c.)

[aiafrasinei]

Thank you for the info , ill use those command line options.

[mrexodia]

I encountered this issue and actually it looks like Windows doesn't restore the console to the same size (the Window width is actually shrinking every time you restore the size).

[wmcbrine]

I encountered this issue and actually it looks like Windows doesn't restore the console to the same size (the Window width is actually shrinking every time you restore the size).

As I said: #42 (comment)

[mrexodia]

You can work around it with the following logic:

• On init, get screen buffer size and save it
• On resize to bigger, set flag
• On resize to smaller, check flag
• If the flag is set, restore the original buffer size

This heuristic can be improved further by using the GetConsoleScreenBufferInfoEx(?) function to get the maximum size and then you can update the resize handler to detect if the window size is the maximium you queried.

I implemented a similar workaround in ccmake and it seems to work great!