FVWM: fltk window origin and fvwm

[s***@arcor.de]

I have written an image viewer that uses FLTK-1.3 .

On MS-WINDOWS (Win7) the origin of the image window is fixed at
the current position and the image window height and/or width
changes with the width and height of the image.

On LINUX I use fvwm 2.6.5 .

With LINUX I have a severe problem: the image window hops around
like a frog when the image window height and width changes with the
width and height of the image. I have sent an EMAIL to the list

https://groups.google.com/forum/#!forum/fltkgeneral

This does not fix the window at the (x,y) position and the window
hops around like a frog when the width/height of the still image
changes.

That's odd.
Seems to work OK for me (testing on F17 and ubuntu-13.10) -
what does the resize demo form the test folder do? Does it work?

The problem is with LINUX.
So what can I do turn this frog into an window?

Are there nested windows or some thing like that?
I guess even if there are multiple widgets in the container,
it might be worth taking a look at init_sizes() after forcing
a re-size, in case the widgets are "remembering" their initial
states...

I have made a test. I have compiled and installed XFCE-4.10 and
found, that the image viewer shows the same stable behaviour as
with MS-WINDOWS: the window origin remains fixed while the width
and/or height of the image viewer changes.

Is it possible to configure FVWM such that the origin of the FLTK
window does not change?

winfried

[Dominik Vogt]

Post by s***@arcor.de
I have written an image viewer that uses FLTK-1.3 .
On MS-WINDOWS (Win7) the origin of the image window is fixed at
the current position and the image window height and/or width
changes with the width and height of the image.
On LINUX I use fvwm 2.6.5 .
With LINUX I have a severe problem: the image window hops around
like a frog when the image window height and width changes with the
width and height of the image. I have sent an EMAIL to the list

...

1. Could you make a minimal version of your program that still
exhibits the problem and send me the source code (along with
detailed instruction, if necessary)?

2. Also, please turn on some debug otuput with the following fvwm
command:

bugopts DebugCRMotionMethod on

and post the output it produces (before trying (3)).

3. Trying the following styles one after another may or may not
help:

Style <stylename> MoveByProgramMethod UseGravity
Style <stylename> MoveByProgramMethod IgnoreGravity
Style <stylename> MoveByProgramMethod AutoDetect

(Actually, AutoDetect is the default and would probably not change
anything.)

4. Finally, if (3) does not fix the problem and recompiling fvwm
is no problem for you, could you please edit the file
fvwm/events.c: In the function __handle_cr_on_client() there is
some disabled debug output:

#if 0
fprintf(stderr,
"cre: %d(%d) %d(%d) %d(%d)x%d(%d) fw 0x%08x w 0x%08x "
"ew 0x%08x '%s'\n",
...
#endif

(At line 960 in the latest version.). Could you change the "#if 0"
to "if 1" and recompile and reinstall fvwm? This produces more
details about what happens when the window is moved or resized.

Ciao

Dominik ^_^ ^_^

[s***@arcor.de]

Post by Dominik Vogt
1. Could you make a minimal version of your program that still
exhibits the problem and send me the source code (along with
detailed instruction, if necessary)?

The attached archive is a mininal version. The attached file
is not. But it shows the problem.
First call './bootstrap.sh', then call 'configure'.

Post by Dominik Vogt
2. Also, please turn on some debug otuput with the following fvwm
bugopts DebugCRMotionMethod on

Where? How?

Post by Dominik Vogt
4. Finally, if (3) does not fix the problem and recompiling fvwm

No output.

winfried

[Dominik Vogt]

Post by s***@arcor.de

Post by Dominik Vogt
2. Also, please turn on some debug otuput with the following fvwm
bugopts DebugCRMotionMethod on

Where? How?

In the fvwm config file or in FvwmConsole.

Post by s***@arcor.de

Post by Dominik Vogt
4. Finally, if (3) does not fix the problem and recompiling fvwm

No output.

To clarify; you're looking at the output of the X console? It's not
possible that this debug code does not produce output during an fvwm run.

Ciao

Dominik ^_^ ^_^

[Dominik Vogt]

Post by s***@arcor.de

Post by Dominik Vogt
1. Could you make a minimal version of your program that still
exhibits the problem and send me the source code (along with
detailed instruction, if necessary)?

The attached archive is a mininal version.

Thanks, I'll look into it when I have time, maybe not before next
week.

Post by s***@arcor.de
The attached file is not. But it shows the problem.

Um, why did you send a panorama image of a french castle to the
mailing list? What I wanted were instructions of how to repoduce
the poblem.

Ciao

Dominik ^_^ ^_^

[s***@arcor.de]

Post by Dominik Vogt
Um, why did you send a panorama image of a french castle to the
mailing list? What I wanted were instructions of how to repoduce
the poblem

The image is a multipage image. If I press the FORWARD/BACKWARD
button the FLTK window jumps like a frog with LINUX and FVWM.

This is the configuration file I use:

do_configure:
./configure --prefix=/usr \
--disable-dependency-tracking \
--disable-htmldoc \
--disable-xinerama \
--disable-nls \
--disable-gtk \
--without-gnome \
--with-xpm-library=/usr/lib \
--with-xpm-includes=/usr/include \
--with-imagepath=/usr/share/pixmaps \
--with-png-library=/usr/lib \
--with-png-includes=/usr/include \
--enable-xrender --enable-xft

You wrote I should insert

Post by Dominik Vogt
In the fvwm config file or in FvwmConsole.

the line

bugopts DebugCRMotionMethod on

I supposed the 'fvwm config file' is the '.fvwm2rc' file
and added the line

BugOpts DebugCRMotionMethod on

This failed totally: the cursor was the WAIT clock and after
5 minutes I press 'Control Alt F2' to finish WAITing.

'/usr/share/fvwm/' contains:

ConfigFvwmBacker FvwmForm-Desktop FvwmScript-FileBrowser
ConfigFvwmButtons FvwmForm-Form FvwmScript-Find
ConfigFvwmDefaults FvwmForm-QuitVerify FvwmScript-KeyboardSetup
ConfigFvwmIconBox FvwmForm-Rlogin FvwmScript-PointerSetup
ConfigFvwmIconMan FvwmForm-RootCursor FvwmScript-Quit
ConfigFvwmIdent FvwmForm-Setup FvwmScript-ScreenDump
ConfigFvwmPager FvwmForm-Talk FvwmScript-ScreenSetup
ConfigFvwmProxyDefaults FvwmForm-TalkHelp FvwmScript-Setup95
ConfigFvwmScroll FvwmScript-BaseConfig FvwmScript-WidgetDemo
ConfigFvwmSetup FvwmScript-BellSetup FvwmTabs-DefaultSetup
ConfigFvwmTabs FvwmScript-Buttons fvwm-script-ComExample.pl
ConfigFvwmTaskBar FvwmScript-Colorset fvwm-script-setup95.pl
ConfigFvwmWinList FvwmScript-ComExample perllib/
FvwmForm-Capture FvwmScript-Date system.fvwm2rc-sample-95


winfried

[Dominik Vogt]

Post by s***@arcor.de

Post by Dominik Vogt
Um, why did you send a panorama image of a french castle to the
mailing list? What I wanted were instructions of how to repoduce
the poblem

The image is a multipage image. If I press the FORWARD/BACKWARD
button the FLTK window jumps like a frog with LINUX and FVWM.

I understand, but it's still not what I asked for. What I need
are instructions and source code to make the problem happen on my
system. Before I have these instructions I will do absolutely
nothing to find what the problem is.

Post by s***@arcor.de
You wrote I should insert

Post by Dominik Vogt
In the fvwm config file or in FvwmConsole.

the line
bugopts DebugCRMotionMethod on
I supposed the 'fvwm config file' is the '.fvwm2rc' file
and added the line

Of course. Of use the FvwmConsole module and enter it there.

Post by s***@arcor.de
BugOpts DebugCRMotionMethod on
This failed totally: the cursor was the WAIT clock and after
5 minutes I press 'Control Alt F2' to finish WAITing.

This has aboslutely nothigng to do with the BugOpts command.
Sounds like an fvwm function that calls a command that does not
finish. To find out the bug in your config file, comment out
lines until it goes away and then look at the lines that cause it.
We're certainly willing to help you with that, but actually we're
not telepathic, so we don't know what's going on on your box
unless you provide relevant information.

To make that clear again: I'm not going to do anything with the
source code you sent unless you give me the instructions I need
(and I'm still waiting for the requested debug output).

Ciao

Dominik ^_^ ^_^

[s***@arcor.de]

------------------------------------------
1. You must have fltk-1.3.x and libtiff installed.
(Me: fltk-1.3.x-r10136, tiff-4.0.3)
2. cd flimage-fltk13-source-1.9.3
3. ./bootstrap.sh
4. ./configure
5. make
6. ./flimage PATH_TO/PalaisDuLouvre.tif
7. Press the forward button ('>') from 0 to 5
8. Press the backward button ('<') from 5 to 0

------------------------------------------
fvwm 2.7.1 (from cvs) compiled on May 26 2014 at 03:31:46
with support for:
ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRender, XCursor, XFT

------------------------------------------
events.c:961:
cre: 0(0) 0(0) 760(4)x685(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''

events.c:961:
cre: 0(0) 0(0) 760(4)x636(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''

events.c:961:
cre: 0(0) 0(0) 760(4)x429(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''

events.c:961:
cre: 0(0) 0(0) 689(4)x308(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''

events.c:961:
cre: 0(0) 0(0) 689(4)x256(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''

events.c:961:
cre: 0(0) 0(0) 689(4)x230(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
------------------------------------------

If this is not enough I give up. Because I now do know now it has to
do with my configuration of fvwm.

winfried

[Viktor Griph]

Post by s***@arcor.de
If this is not enough I give up. Because I now do know now it has to
do with my configuration of fvwm.

Can you test and see if using the style MoveByProgramMethod UseGravity
on your windows helps?

/Viktor

[Dominik Vogt]

Post by s***@arcor.de
------------------------------------------
1. You must have fltk-1.3.x and libtiff installed.
(Me: fltk-1.3.x-r10136, tiff-4.0.3)
2. cd flimage-fltk13-source-1.9.3
3. ./bootstrap.sh
4. ./configure
5. make
6. ./flimage PATH_TO/PalaisDuLouvre.tif
7. Press the forward button ('>') from 0 to 5
8. Press the backward button ('<') from 5 to 0

First, I get three compile errors when building (on a Debian 32-bit
system):

1) If I don't have libtiff4-dev (version 3.9.6-11) installed:

--
flimage.cxx: In function 'void chooser_cb(const char*)':
flimage.cxx:1280:22: error: 'TIFF_free_read_info' was not declared in this scope
flimage.cxx: In function 'void exit_cb(Fl_Widget*, void*)':
flimage.cxx:1409:22: error: 'TIFF_free_read_info' was not declared in this scope
make: *** [all] Error 1
--

I fixed that by installing the package, but the root cause of the
compile error is that TIFF_free_read_info() is called even with
the configure option --disable-tiff.

2) TIFF.cxx uses the type "tmsize_t" which isn't defined anywhere.

--
TIFF.cxx: In function 'int cpStrips(TIFF*, TIFF*)':
TIFF.cxx:684:2: error: 'tmsize_t' was not declared in this scope
TIFF.cxx:684:11: error: expected ';' before 'bufsize'
--

After some research on the web I concluded that this type is
provided by some versions of libtiff, and is just a 32-bit int on
an 32-bit system, so I added

typedef int tmsize_t;

at the beginning of TIFF.cxx.

3) TIFF.cxx uses the undefined type "uint64".

--
TIFF.cxx: In function 'int cpStrips(TIFF*, TIFF*)':
TIFF.cxx:694:2: error: 'uint64' was not declared in this scope
TIFF.cxx:694:10: error: 'bytecounts' was not declared in this scope
TIFF.cxx:703:29: error: expected ')' before 'bufsize'
--

I've circumvented this problem by adding

#include <stdint.h>
typedef uint64_t uint64;

at the beginning of TIFF64.cxx.

--

Second, after building, if I run

./flimage ~/PalaisDuLouvre.tif

The I just get a core dump:

TIFFOpen: (null): Cannot open.
zsh: segmentation fault (core dumped) ./flimage ~/PalaisDuLouvre.tif
./flimage ~/PalaisDuLouvre.tif 0.32s user 1.56s system 25% cpu 7.281 total

gdb session:

-- snip --
Core was generated by `./flimage /home/luthien/PalaisDuLouvre.tif'.
Program terminated with signal 11, Segmentation fault.
#0 0xb75550ec in TIFFFindFieldInfo ()
from /usr/lib/i386-linux-gnu/libtiff.so.4
(gdb) bt
#0 0xb75550ec in TIFFFindFieldInfo ()
from /usr/lib/i386-linux-gnu/libtiff.so.4
#1 0xb75545b6 in TIFFVGetField () from /usr/lib/i386-linux-gnu/libtiff.so.4
#2 0xb755464b in TIFFGetField () from /usr/lib/i386-linux-gnu/libtiff.so.4
#3 0x0804e824 in read_single_image (out_height=0xbfe8d1c0,
out_width=0xbfe8d1bc, read_idf=<optimized out>) at TIFF.cxx:180
#4 get_buf (i=***@entry=0, out_width=***@entry=0xbfe8d1bc,
out_height=***@entry=0xbfe8d1c0) at TIFF.cxx:232
#5 0x0805041a in TIFF_load (canvas=0x9d33be8, reader=0x9d2d728,
read_idf=0x9d33698 "/home/luthien/PalaisDuLouvre.tif", fsize=1971467)
at TIFF.cxx:407
#6 0x0804ca59 in load_image (fsize=1971467,
fname=0x9d33698 "/home/luthien/PalaisDuLouvre.tif", fp=0x9d2d728)
at flimage.cxx:1191
#7 chooser_cb (cs=***@entry=0xbfe908d6 "/home/luthien/PalaisDuLouvre.tif")
at flimage.cxx:1302
#8 0x0804b7c6 in main (argc=2, argv=0xbfe8f3a4) at flimage.cxx:1594
(gdb) list
1450 while((ch = *s++))
1451 {
1452 if(isspace(ch)) continue;
1453 *d++ = (char)tolower(ch);
1454 }
1455 *d = 0;
1456 }
1457
1458 int main(int argc, char *argv[])
1459 {
-- snip --

This looks like an incompatible version of libtiff. Do you have
an image or images in a less antique format that can be used to
make the problem show up (png? jpg? gif?). (Please post links
to the images or mail them to me directly.)

--

Third,

Post by s***@arcor.de
------------------------------------------
cre: 0(0) 0(0) 760(4)x685(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
cre: 0(0) 0(0) 760(4)x636(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
cre: 0(0) 0(0) 760(4)x429(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
cre: 0(0) 0(0) 689(4)x308(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
cre: 0(0) 0(0) 689(4)x256(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
cre: 0(0) 0(0) 689(4)x230(8) fw 0x0040025f w 0x00600006 ew 0x00600006 ''
_cdim: --- using StaticGravity 0x1d44180 ''
------------------------------------------

all this looks sensible and just expresses that the window had
been at the top left corner of the screen with various sizes.

Ciao

Dominik ^_^ ^_^

[s***@arcor.de]

Post by Viktor Griph
Can you test and see if using the style MoveByProgramMethod UseGravity
on your windows helps?

I added:

Style "*" MoveByProgramMethod UseGravity

to '.fvwm/.fvwm2rc' : not effect.

winfried

[s***@arcor.de]

Post by Dominik Vogt
First, I get three compile errors when building (on a Debian 32-bit

I use SLACKWARE-14.0, a 64-BIT distribution; no 32-bit, no '-m32'.

'configure' shows:

your configuration

--enable-openjpeg.....: no
--enable-libjpwl......: no
--enable-openjpeg-mj2.: no
--enable-jasper.......: no
--enable-jpeg.........: yes <==
--enable-mng..........: no
--enable-png..........:
--enable-tiff.........: yes <==
--enable-netpbm.......: no
--enable-lcms2........: yes <==
--enable-lcms1........: no
--enable-tga..........: no
--enable-dicom........: no
--with-language.......: english
use threads...........:

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'.

But 'configure' contains:

--enable-tiff
--with-tiff-includes=DIR TIFF includes in nonstandard DIR
--with-tiff-libraries=DIR TIFF library in nonstandard DIR

so that libtiff could be found and

#ifdef HAVE_LIBTIFF

could be activated.

And 'configure' contains:

--endable-jpeg
--with-jpeg-includes=DIR JPEG includes in nonstandard DIR
--with-jpeg-libraries=DIR JPEG library in nonstandard DIR

so that libjpeg could be found and

#ifdef HAVE_LIBJPEG

could be activated. I use jpegsrc.v09a .

That is all this minimal version can show: TIFF and JPEG images.

JPEG images can be downloaded from

http://home.arcor.de/szukw000/JPG_IMAGES.tar.xz

winfried

[Dominik Vogt]

Post by s***@arcor.de

Post by Dominik Vogt
First, I get three compile errors when building (on a Debian 32-bit

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.

Post by s***@arcor.de
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 ^_^ ^_^

[s***@arcor.de]

Post by Dominik Vogt
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.

Fixed. Thank you.

winfried