Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, May 26, 2014 at 10:29:43PM +, 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
Re: FVWM: [fvwm] fltk window origin and fvwm
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): 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=DIRJPEG 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
Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, 26 May 2014 16:38:39 +0200, Viktor Griph wrote: >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
Re: FVWM: [fvwm] fltk window origin and fvwm
On Mon, May 26, 2014 at 04:23:52AM +, szukw...@arcor.de wrote:
> --
> 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
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=) at TIFF.cxx:180
#4 get_buf (i=i@entry=0, out_width=out_width@entry=0xbfe8d1bc,
out_height=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=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
1450while((ch = *s++))
1451 {
1452if(isspace(ch)) continue;
1453*d++ = (char)tolower(ch);
1454 }
1455*d = 0;
1456}
1457
1458int 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,
> --
> events.c:961:
> cre: 0(0) 0(0) 760(4)x685(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 760(4)x636(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 760(4)x429(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 689(4)x308(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 689(4)x256(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _cdim: --- using StaticGravity 0x1d44180 ''
>
> events.c:961:
> cre: 0(0) 0(0) 689(4)x230(8) fw 0x0040025f w 0x0066 ew 0x0066 ''
> _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 ^_^ ^_^
--
Dominik V
Re: FVWM: fvwm and mvwm? How is fvwm?
lee writes: > Thomas Adam writes: > >> So I don't want idle speculation or wonder to permeate the work I'm doing, >> the only thing FVWM will benefit from this will be bug-fixes, and I've >> already identified a few memory leaks. It's nice for FVWM in a way, it's >> being audited for free as a result of this work. > > Is the code currently in the repo on github "useful"? "Useful" would > mean that one could compile it and use it instead of fvwm. So I cloned and compiled it, and it works --- even seems to be a lot faster than the fvwm version in Fedora. However, I have FvwmRearrange -tile -a -mn 2 -noraise 0 0 100 100 in a menu, and it doesn`t work anymore in that it doesn`t seem to do anything. Is this feature disabled/removed in mvwm? -- Knowledge is volatile and fluid. Software is power.
Re: FVWM: fvwm and mvwm? How is fvwm?
Thomas Adam writes: > So I don't want idle speculation or wonder to permeate the work I'm doing, > the only thing FVWM will benefit from this will be bug-fixes, and I've > already identified a few memory leaks. It's nice for FVWM in a way, it's > being audited for free as a result of this work. Is the code currently in the repo on github "useful"? "Useful" would mean that one could compile it and use it instead of fvwm. I`m all for removing cruft and better efficiency, and I appreciate your effort and would be happy if I could help. -- Knowledge is volatile and fluid. Software is power.
Re: FVWM: [fvwm] fltk window origin and fvwm
2014-05-26 6:23 GMT+02:00 : > 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
