|
From: | H.G. Muller |
Subject: | Re: [XBoard-devel] 4.9.0 readiness |
Date: | Tue, 12 Apr 2016 17:28:14 +0200 |
User-agent: | Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
Disappointing that the explicit call to DelayedDrag() does not solve
it. It gives more output than I get when starting XBoard without it,
so it seemes to trigger some avelanche of events. The third one
should be ignored, as none of the window parameters changes. But is
is very strange the first two don't do anything. These should lead
to calls of ReSize(), as the window width changes from -1 (a stored
value indicating 'default') to 958. So we seem to have solved one problem (that DragProc() was not called at all), but there still is a remaing problem (that ReSize does not seem to do anything). Could you put the following four print statements in ReSize()? printf("table size %dx%d squareSize=%d\n",w,h,squareSize); if(a.width < w || a.height < h) { // outer window smaller than dialog content? w = a.width - w; h = a.height - h; // subtract matrgins, measured as table minus board dimensions gtk_widget_get_allocation(optList[W_BOARD].handle, &a); printf("board size %dx%d\n",a.width,a.height); w += a.width; h += a.height; } else { gtk_widget_get_allocation(optList[W_BOARD].handle, &a); w = a.width; h = a.height; } printf("new board %dx%d\n",w,h); sqx = (w - lg) / BOARD_WIDTH - lg; sqy = (h - lg) / BOARD_HEIGHT - lg; if(sqy < sqx) sqx = sqy; printf("square size %d\n",sqx); There seem to be two possibilities here: the newly calculates square size can end up below 20, in which case ReSize() ignores the size request. (Unlikely!) Or the newly calculated sqx ends up the same as the previous squareSize, despite the fact that the size of the outer window changed. Normally the 'else' part of the above 'if' is taken, and it interrogates the size of the board drawing area. Normally this size in GTK is automatically coupled to that of the outer window, as we pack 'Graph' widgets in the layout table such that they expand to fill all available space, and the layout table in the outer window as well. So any window sizing the user does is taken up by the board (the clocks and message widget do not have the vertical GTK_EXPAND flag set), and the new square size can be determined from the new size of the board widget. It is very difficult to determine the size directly from the outer window, as we don't know how much space the window frame and clocks+message takes. (Initially we did it that way, by measuring a startup window size with a 1x1 board, but with bad results, as the clock height could still change afterwards due to font change or multiple lines.) What seems to be the case here is that i3wm did not only fail to inform the application through a configure-event that the outer window was enlarged, but also failed to inform GTK of this fact, so that it did not calculate a new layout for the widgets inside it. This is strange, as horizontally the clocks obviously do expand to fill the full window. So it seems GTK is informed by i3wm only of the horizontal window expansion, not of the vertical one. Instead of faking that the application got the configure-event signal by calling DelayedDrag(), it might help to actually fake the entire signal, so that GTK would also respond to it. I have never done such a thing, but it seems doable through g_signal_emit(shells[BoardWindow], "configure-event", ...); where the manual says the ... should be the parameters normally passed to handlers for this event. In this case that should be a configure-event structure with details about the new window parameters. We shoud obtain these first, however, and at a time after i3wm messed with the outer window. Requesting them in GenericPopUp will probably be too soon. That means it should be done in DragProc(), which is called after a timer delay. So we should continue to call DelayedDrag() by hand, like we we do now, but let DragProc() the first time it sees the window height go positive from the requested the window parameters, use the latter to fake a configure-event. Very complicated... H.G. Op 4/12/2016 om 3:20 PM schreef Adrian
Petrescu:
|
[Prev in Thread] | Current Thread | [Next in Thread] |