On Mon, May 26, 2014 at 10:29:43PM +0000, szukw...@arcor.de wrote: > On Mon, 26 May 2014 19:43:49 +0100, Dominik Vogt wrote: > > >First, I get three compile errors when building (on a Debian 32-bit > >system): > > The library 'tiff-4.0.3' has a 'libtiff-4.pc' file for 'pkg-config'. > Older versions do not have this file. > > Therefore the tiff-library you use (3.9.6) is not found because > > #ifdef HAVE_LIBTIFF > > is not activated. Therefore 'TIFF.hh' is hidden; but 'TIFF.hh' > contains 'extern void TIFF_free_read_info();': a local function > found in 'TIFF.cxx', not in 'libtiff'. > ...
Okay, I got that. I just want to point out that the code in TIFF.cxx is protected by "#if HAVE_LIBTIFF", but the calls to TIFF_free_read_info() in flimage.cxx (called from chooser_cb() and exit_cb()) are not. I.e. if HAVE_LIBTIFF is zero, you'll get compile errors in the callback functions in flimage.cxx. -- Now back to the undesirable behaviour of the windows. > The image is a multipage image. If I press the FORWARD/BACKWARD > button the FLTK window jumps like a frog with LINUX and FVWM. That is because Fltk is asking fvwm for trouble: 1. It sets the window gravity to StaticGravity when mapping the window. This is essentially *undefined* behaivour. The relevant standard, the ICCCM2, says nothing about what the window manager is supposed to do when initially mapping a window with StaticGravity. 2. The window uses the "user specified position hint" on its initial coordinates and thus prevents the window manager to find a nice place for the window. It is forbidden that applications use this hint unless the user has explicitly requested a certain window position in some way. 3. It is not really clear how a window using StaticGravity should be placed by the window manager when the application resizes it. At the moment, fvwm keeps the middle pixel of the client window (without the window manager decorations) at a constant position. Other window managers keep the top left corner of the window in a constant position. Both relies on badly specified behaviour and is more or less broken. Anyway, I'm still thinking hard whether fvwm's behaviour is optimal or not and may or may not make a patch in the future. So, to fix your application problem, I recommend that you A) use NorthWestGravity for the window, and B) do not use the "user specified position hint" in your program. I have no idea whatsoever how you can communicate this to Fltk, and I am aware that Fltk is using some secret, undocumented (but silly, no, idiotic) defaults. You may have to ask the Fltk developers how to do this. Applications insisting on using StaticGravity should really use the _NET_MOVERESIZE_WINDOW client message and refrain from reconfiguring their windows. Well, if you manage to figure out how to do these two little changes, your window will behave just as any other application window. Ciao Dominik ^_^ ^_^ -- Dominik Vogt
