Resizable window 'hangs' during start

[chris]

The attached simple program behaves odd at start. First I thought it
hangs at opening the window, but actually the window appears, but it's
size is about 1x1px on the edge of the screen.. (It can be located when
playing with the task bar).

It has to to with the resizable() statement *and* the resizable widget
(the group) beeing created *larger* than the window originally.

Queer is, that some initial sizes of the group (e.g. 150x150) work ok.

System is Ubuntu 14.04, tested with FLTK 1.3 and FLTK 1.4.

Something rings this might be a window manager thing again.
Can someone reproduce?

Chris

[Greg Ercolano]

I can't reproduce here with scilinux 6.3 + flwm.

As wrong as making child widgets larger than the window might be,
we should determine the cause and fix this, whatever it is,
as it certainly shouldn't hang.

Is the cpu spinning during the hang?
If so, there might be a resize loop going on, possibly induced
by the window manager, or within FLTK.

You might try replacing Fl_Window and Fl_Group instances
with custom classes, and implement resize() with printf()'s
to see if there's a resize() war going on. For instance, try
the following code. On my system the output is:

MyWindow::resize(910,558,100,100), old: 0,0,100,100
MyWindow::resize(910,558,100,100), old: 910,558,100,100
MyWindow::resize(910,558,100,100), old: 910,558,100,100

Here's the code with the implemented resize() / printf()s:

#include <stdio.h>
#include <FL/Fl_Window.H>
#include <FL/Fl_Group.H>
#include <FL/Fl.H>

class MyWindow : public Fl_Window {
public:
MyWindow(int W,int H,const char *L=0) : Fl_Window(W,H,L) { }
MyWindow(int X,int Y,int W,int H,const char *L=0) : Fl_Window(X,Y,W,H,L) { }
void resize(int X,int Y,int W,int H) {
printf("MyWindow::resize(%d,%d,%d,%d), old: %d,%d,%d,%d\n",
X,Y,W,H, x(),y(),w(),h());
Fl_Window::resize(X,Y,W,H);
}
};

class MyGroup : public Fl_Group {
public:
MyGroup(int X,int Y,int W,int H,const char *L=0) : Fl_Group(X,Y,W,H,L) { }
void resize(int X,int Y,int W,int H) {
printf("MyGroup::resize(%d,%d,%d,%d), old: %d,%d,%d,%d\n",
X,Y,W,H, x(),y(),w(),h());
Fl_Group::resize(X,Y,W,H);
}
};

int main()
{
MyWindow *win = new MyWindow(100, 100);
MyGroup *group = new MyGroup(0, 0, 300, 300);
win->resizable(group);
win->end();
win->show();
return Fl::run();
}

[chris]

> Is the cpu spinning during the hang?
> If so, there might be a resize loop going on, possibly induced
> by the window manager, or within FLTK.

No cpu spinning. Seems to bn normal program flow (The window is there,
but hard to spot :)

So most likely really a window manager thing...

> You might try replacing Fl_Window and Fl_Group instances
> with custom classes, and implement resize() with printf()'s
> to see if there's a resize() war going on. For instance, try
> the following code. On my system the output is:
>
> MyWindow::resize(910,558,100,100), old: 0,0,100,100
> MyWindow::resize(910,558,100,100), old: 910,558,100,100
> MyWindow::resize(910,558,100,100), old: 910,558,100,100
>

My output with your program:

MyWindow::resize(0,24,100,100), old: 0,0,100,100
MyWindow::resize(1,53,1,1), old: 0,24,100,100
MyGroup::resize(0,0,201,201), old: 0,0,300,300
MyWindow::resize(1,53,1,1), old: 1,53,1,1
MyWindow::resize(1,53,1,1), old: 1,53,1,1

[Greg Ercolano]

On 11/13/16 10:57, chris wrote:
> My output with your program:
> MyWindow::resize(0,24,100,100), old: 0,0,100,100
> MyWindow::resize(1,53,1,1), old: 0,24,100,100

That last line telling the window to shrink to 1,1 in size
seems to be the problem. Wonder why the heck that is.

Which window manager is this? (gnome/kde/other?)

[chris]

>
> Which window manager is this? (gnome/kde/other?)

metacity 2.34.13


I added a timer callback and tried to resize the window there.
Even if reports the given size afterwards, it is still 1x1 px on the
screen. Even hide() and show() does not help.

[Greg Ercolano]

If you want to prevent the window from being sized smaller than 100,100,
just add that logic to the MyWindow::resize() callback, e.g.

void resize(int X,int Y,int W,int H) {

if ( W<100 ) W=100;
if ( H<100 ) H=100;

[chris]

> If you want to prevent the window from being sized smaller than 100,100,
> just add that logic to the MyWindow::resize() callback, e.g.
>
> void resize(int X,int Y,int W,int H) {
> if ( W<100 ) W=100;
> if ( H<100 ) H=100;
> printf("MyWindow::resize(%d,%d,%d,%d), old: %d,%d,%d,%d\n",
> X,Y,W,H, x(),y(),w(),h());
> Fl_Window::resize(X,Y,W,H);
> }
>

Unfortunately it does not help in this particular case. There must be
something screwed up severely either in the WM or in the communication
with it. Maybe there is bug in the WM. The window does not honour any
size change request and stays at 1x1, though FLTK reports the sizes it
sets. What works is, that FLTK reacts on dragging the 1x1 window and
reports changing x/y coords and also can set the window position.

---

Thanks for checking and making the the things clearer...

It is not an important problem for me currently - just wanted to report
it, as I stumbled upon it working on a more complex application and had
some difficulty to find out what the reason was for my window not appearing.

Cheers,
Chris

[Greg Ercolano]

OK, I can replicate on Ubuntu 16.04 + KDE, so it's not entirely window manager specific.
In my case it opens as a tiny/thin window that is 8x33 in size that can't be resized or moved easily because the titlebar is so small. And I get this same behavior with various other hard coded window sizes, as long as the child group is over 100x100 larger in size than the window (see next paragraph).

Next, playing around with the window + group size values, it seems the magic number that causes this problem is if the child group is 100x100 larger (or more) than the window. So for instance if the window is set to 400x400, the group can be up to 499x499 in size and still open normally (499-400=99), but a group size of 500x500 causes the problem. (500-400=100).

So we must have 100 hard coded in the FLTK X windows source somewhere that's causing this.

I've made a bug for this thread:
http://www.fltk.org/str.php?L3352
..so lets use that for further discussion/solutions.