Subject: FVWM: FvwmButton bug ????

From: [email-masked] (Albrecht Kadlec)
Date: Fri, 17 Jan 97 23:25:31 +0100

now that the wait function hangs, I had to remove
#+			"I"	FvwmBanner
#+			"I"	Wait FvwmBanner
from my RestartFunction.

I still experience the old FvwmButtons / fvwm2 bug:

	a second instance of all swallowed (UseOld, NoClose, Respawn) 
	applications is started, since FvwmButtons had no time to
	regurgitate the old instances completely.
	Therefore no window does exist for them, and they're simply not
	found by UseOld.

I thought somebody sent chuck a patch for that for 2.0.43, but I can't find
it.

albrecht
-- 
What happened to the heart that I gave you,
What are you hiding in your chest these days,
You wanted someone to save you,
I wanted someone who could not be saved.  -- The Hooters
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Eddy J. Gurney" <[email-masked]>
Date: Fri, 17 Jan 1997 18:20:28 -0500

On Jan 17, 23:25, Albrecht Kadlec wrote:

> now that the wait function hangs...

This seems like the biggest problem with fvwm-2.0.44 right now. Is anybody
looking at why this doesn't work?

Also, the AutoRaise problem hasn't been fixed in regards to menus: if
you pop-down a menu, then the AutoRaise delay expires, the window is
raised and obscures the menu. Isn't there any way to fix this?

The other problem is if a user doesn't have a .fvwm2rc file, it complains
that it can't find it OR the system.fvwm2rc file, even though the
system.fvwm2rc file DOES exist. This needs to be fixed before I can install
it on our machines as well, since not everyone has a ~/.fvwm2rc...

Finally, something that needs to be fixed in Fvwm.tmpl: in order for
the Solaris dynamic linker to find the X libraries, I needed to change
the FvwmModuleTarget and FvwmProgramTarget from '$(CC) -o $@...' to
'$(CCLINK) -o $@...'. This is very important! It makes sure the
LD_LIBRARY_PATH gets set before the link so the dynamic linker can find
the X libraries. Prior to making this change, 'fvwm2' would not run,
with the linker complaining about not be able to find the X libraries,
and 'ldd' confirmed it. I tracked it down to this oversight in 'Fvwm.tmpl'.
Can this be fixed?

Also, I'm fairly certain I've applied all the patches (the placement.c
patch, all the patches from andrew [up to andrew4], got the new FvwmIconMan,
and the new FvwmAuto and FvwmAudio updates) that have been released to date,
but it would be nice to maybe release an "fvwm-2.0.44.1" (or something)
once things settle down that includes all the patches, some Decor samples,
etc...

Eddy

---

From: [email-masked] (Albrecht Kadlec)
Date: Sat, 18 Jan 97 00:43:13 +0100

>>>>> Eddy J Gurney writes:

> now that the wait function hangs...

E> This seems like the biggest problem with fvwm-2.0.44 right now. Is anybody
E> looking at why this doesn't work?

not me - next time I might possibly see a computer is mon/tuesday, but
probably not.

E> Also, the AutoRaise problem hasn't been fixed in regards to menus: if
E> you pop-down a menu, then the AutoRaise delay expires, the window is
E> raised and obscures the menu. Isn't there any way to fix this?

not reported 'till now.
On a quick look (it's 0:26) my FvwmAuto doesn't do that. 

	    +-------------+
       3    | 2		  |
            | 		  |
            | 		  |
            | 		  |
   +-------------+        |
   | 1           |        |
   |             |--------+
   |             |
   |             |

move from 1 over 2 to 3, open menu, before 2 is raised,
(menu overlaps both windows just a little bit, so you can tell the exact
order)
stay in menu as long as you like, nothing is raised over the menu.
exit menu -> 2 is raised over 1.

The raise is delayed until the menu is closed, no strange behaviour found.

E> Finally, something that needs to be fixed in Fvwm.tmpl: in order for
E> the Solaris dynamic linker to find the X libraries, I needed to change
E> the FvwmModuleTarget and FvwmProgramTarget from '$(CC) -o $@...' to
E> '$(CCLINK) -o $@...'. This is very important! It makes sure the
E> LD_LIBRARY_PATH gets set before the link so the dynamic linker can find
E> the X libraries. Prior to making this change, 'fvwm2' would not run,
E> with the linker complaining about not be able to find the X libraries,
E> and 'ldd' confirmed it. I tracked it down to this oversight in 'Fvwm.tmpl'.
E> Can this be fixed?

I still have to rename all FvwmManPath settings to FvwmManDir settings,
but X11R4 is the least common denominator here (mix of X11R4, R5 & R6 sun
workstations). 
So this could be our local setup.

E> Also, I'm fairly certain I've applied all the patches (the placement.c
E> patch, all the patches from andrew [up to andrew4], got the new FvwmIconMan,
E> and the new FvwmAuto and FvwmAudio updates) that have been released to date,
E> but it would be nice to maybe release an "fvwm-2.0.44.1" (or something)
E> once things settle down that includes all the patches, some Decor samples,
E> etc...

so there's a new Auto & Audio (dateed Jan 18th) out there right now, but
only minor fixies. :-)
SO THERE !

we're all hoping for a new synced release.
(andrew hasn't made any upgrade patches for his andrew3.2.0.44.diff, which
I applied to my working tree. - guess I'll have to do it by hand, or wait
for 2.0.45 or 2.0.44.1)

cheers,
albrecht
-- 
Strangers passing in the street		|  And no one calls us to the land
By chance two separate glances meet	|  And no one crosses there alive
And I am you and what I see is me	|  And no one speaks
And do I take you by the hand		|  And no one tries
And lead you through the land		|  And no one flies around the sun
And help me understand the best I can			-- Pink Floyd, "Echoes"
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Trent Piepho <[email-masked]>
Date: Fri, 17 Jan 1997 16:16:25 -0800 (PST)

> On a quick look (it's 0:26) my FvwmAuto doesn't do that. 

This is what you need to do:

        1

 ---------------
 |             |
 |      2      |
 |             |
 |             |
 ---------------

Put the mouse in 1 (which is probably the root window), make sure window 2
doesn't have focus, move the mouse to window 2, make a pop-up menu appear
BEFORE the autorase timeout.  Window 2 will raise above the pop-up.  I know
where the bug is in fvwm, it's not FvwmAuto's fault.  When FvwmAuto tells fvwm
to raise window 2, like it should, fvwm alters the stacking order something
like:

Bottom
1.  window 2
2.  window 2's transients  (netscape open URL window, _not_ a menu)
3.  StatysOnTop windows
Top

All other windows, which includes pop-menu windows, will be moved below window
2.  Somenow fvwm needs to know:

a) that the pop-up window is part of window 2, and that it should always be
   above window 2. 
b) that window 2 and it's children shouldn't change their relative stacking
   order.
c) that pop-up windows should always go on the very top

I would like c, as sometimes a pop-up appears under FvwmButtons or xload and I
can't see it.  However I don't know how to tell if a window is a pop-up, or
how to get fvwm to know about all those pop-up windows.  It seems that pop-up's
aren't reparented to the window manager like other top-level windows.

|Gazing up to the breeze of the heavens \ on a quest, meaning, reason  |
|came to be, how it begun \ all alone in the family of the sun         |
|curiosity teasing everyone \ on our home, third stone from the sun.   |
|Trent Piepho ([email-masked])                   -- Metallica  |
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Albrecht Kadlec)
Date: Sat, 18 Jan 97 01:31:07 +0100

>>>>> Trent Piepho writes:

T> 2.  Somenow fvwm needs to know:

T> a) that the pop-up window is part of window 2, and that it should always be
T>    above window 2. 
T> b) that window 2 and it's children shouldn't change their relative stacking
T>    order.
T> c) that pop-up windows should always go on the very top

T> I would like c, as sometimes a pop-up appears under FvwmButtons or xload and I
T> can't see it.  However I don't know how to tell if a window is a pop-up, or
T> how to get fvwm to know about all those pop-up windows.  It seems that pop-up's
T> aren't reparented to the window manager like other top-level windows.

the transient flag ?
It must be in the DecorateTransient code.

Just sort all transient windows to the top, without changing their relative
order ? Ignore the top part of the stack on reorders?

albrecht
-- 
I know the fool who wears the crown	-- Pink Floyd

---

From: Trent Piepho <[email-masked]>
Date: Fri, 17 Jan 1997 18:55:16 -0800 (PST)

> order ? Ignore the top part of the stack on reorders?

Fvwm does that, except it seems that pop-up menu ins't a "transient" window.

---

From: "Randall S. Winchester" <[email-masked]>
Date: Tue, 21 Jan 1997 17:36:58 -0500 (EST)

On Fri, 17 Jan 1997, Eddy J. Gurney wrote:

: On Jan 17, 23:25, Albrecht Kadlec wrote:
: 
: ....stuff deleted.
: 
: Finally, something that needs to be fixed in Fvwm.tmpl: in order for
: the Solaris dynamic linker to find the X libraries, I needed to change
: the FvwmModuleTarget and FvwmProgramTarget from '$(CC) -o $@...' to
: '$(CCLINK) -o $@...'. This is very important! It makes sure the
: LD_LIBRARY_PATH gets set before the link so the dynamic linker can find
: the X libraries. Prior to making this change, 'fvwm2' would not run,
: with the linker complaining about not be able to find the X libraries,
: and 'ldd' confirmed it. I tracked it down to this oversight in 'Fvwm.tmpl'.
: Can this be fixed?
:
: ....stuff deleted. 
: 
: Eddy
: --

This is indeed a problem with CC=cc. It is also true with some versions of
gcc. I have just upgraded from gcc 2.7.0 which did not have this problem to
2.7.2 which does as well as older gcc 2.6.*. In the gcc case it is not
LD_LIBRARY_PATH that gets set but rather LD_RUN_PATH, but the end result is
the same. Either of thses are supposed to get set to $(USRLIBDIR). In my
case this would be USRLIBDIR = /usr/local/X11R6/lib. Imake of corse thakes
care of this part.

The following command shows the problem with out the fix; 

ldd fvwm/fvwm2
        libXpm.so.4.3 =>   (unknown)
        libXext.so.6.0 =>  (unknown)
        libX11.so.6.0 =>   (unknown)
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libintl.so.1 =>  /usr/lib/libintl.so.1
        libmp.so.1 =>    /usr/lib/libmp.so.1

I looked at the source to xdm and the builds on my various platforms, and
that all use a line like;
 $(CCLINK) -o $@ $(LDOPTIONS).......
with;
 CCLINK = $(CC)
automaticaly by imake for the non trivial case. 

Thus I believe the following patch to Fvwm.tmpl should be in fvwm-2.0.45.
Would the fvwm-workers please try this on their platforms, if they are not
using X11R6.

Randall

diff -u -r1.1 Fvwm.tmpl
--- 1.1 1997/01/21 20:01:00
+++ Fvwm.tmpl   1997/01/21 22:25:30
@@ -466,7 +466,7 @@
                                                                        @@\
 program: $(OBJS) $(DEPLIBS)                                            @@\
        RemoveTargetProgram($@)                                         @@\
-       $(CC) -o $@ $(OBJS) $(LDOPTIONS) $(LOCAL_LIBRARIES) $(LDLIBS) $(EXTRA_LOAD_FLAGS) @@\
+       $(CCLINK) -o $@ $(OBJS) $(LDOPTIONS) $(LOCAL_LIBRARIES) $(LDLIBS) $(EXTRA_LOAD_FLAGS) @@\
                                                                        @@\
 InstallProgram(program,$(FVWMDIR))                                     @@\
 InstallManPage(program,$(MANDIR))                                      @@\
@@ -491,7 +491,7 @@
                                                                        @@\
 program: $(OBJS) $(DEPLIBS)                                            @@\
        RemoveTargetProgram($@)                                         @@\
-       $(CC) -o $@ $(OBJS) $(LDOPTIONS) $(LOCAL_LIBRARIES) $(LDLIBS) $(EXTRA_LOAD_FLAGS) @@\
+       $(CCLINK) -o $@ $(OBJS) $(LDOPTIONS) $(LOCAL_LIBRARIES) $(LDLIBS) $(EXTRA_LOAD_FLAGS) @@\
                                                                        @@\
 InstallProgram(program,$(FVWMBINDIR))                                  @@\
 InstallManPage(program,$(MANDIR))                                      @@\

---

From: [email-masked] (Albrecht Kadlec)
Date: Wed, 22 Jan 97 00:27:20 +0100

diff -u -r1.1 Fvwm.tmpl
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I install fvwm2 under my home dir.

I need the following diffs to Fvwm.tmpl:

0:18 einstein:~/bin/tools/44/fvwm-2.0.44> diff Fvwm.tmpl ../../fvwm-2.0.45-almos
t/
67c67
< #define HasXpm  YES     /* NO */
---
> #define HasXpm YES     /* NO */
69a70
> #define XpmLibs -L/XTech/lib/X11
280a282
> #define FvwmBinDir /net/einstein/home/einstein/albrecht/bin
283a286
> #define FvwmDir /net/einstein/home/einstein/albrecht/bin/Fvwm
286a290
> #define FvwmLibDir /net/einstein/home/einstein/albrecht/bin/lib

this is ok.

289c293
< /* #define FvwmManPath /usr/local/X11R6/man */
---
> /* #define FvwmManDir /usr/local/X11R6/man */
291a296,297
> #define FvwmManDir /net/einstein/home/einstein/albrecht/bin/tools/man/mann
> #define FvwmManSuffix 1
377,378c383,384
< #ifdef FvwmManPath
<         MANPATH = FvwmManPath
---
> #ifdef FvwmManDir
>         MANDIR = FvwmManDir

This is not, I guess.
Make tries to install the man pages to obscure locations, but not to the
one I specified.

cause:
The man pages are installed under MANDIR (see last line of above patch from
Randall S. Winchester)

so _this_ should be changed instead of MANPATH (which is the search path,
with different directories, not the man-page install directory)

albrecht
-- 
When we came back from the war the banners and Flags hung on everyones door
We danced and we sang in the street and the church bells rang
But burning in my heart my memory smoulders on
Of the gunners dying words on the intercom	-- Pink Floyd, "A Hero's Return"
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Christopher Wolf <[email-masked]>
Date: Tue, 21 Jan 1997 17:46:13 -0600 (CST)

I have 'Style "*" NoPPosition' in my .fvwm2rc, and I use
smartplacement with the SmartPlacementIsReallySmart option.

If I start SparcWorks debugger like: "debugger -geometry +88+33 file",
it always ignore the geometry placement request, no matter whether or
not I use the SmartPlacementIsReallySmart flag.

Also, if I remove the NoPPosition style, it always ignores the
position request and places the debugger in position 0,0

Does anyone know why I cannot get the debugger to come up at +88+33?

-Wolf

---

From: Anthony Martin <[email-masked]>
Date: Wed, 22 Jan 1997 10:54:29 -0800 (PST)

> Does anyone know why I cannot get the debugger to come up at +88+33?

It's possible that your application ignores the geometry information you
provide it.  Has this worked with any previous version of fvwm or any
other window manager?  I suspect it is the application's fault.  Perhaps
there are some resources you can set to place it where you want it.

Tony.

---

From: John Tillema <[email-masked]>
Date: Wed, 22 Jan 1997 14:02:23 -0700 (MST)

> there are some resources you can set to place it where you want it.
I can't say for Christopher, but I have that problem with any window I
open.  On 2.0.43, I had it setup for active placement for all cases, but in
upgrading to 2.0.44, this changed to smart placement I believe (it places it
if there is an obvious place, otherwise you place it).  Below is what I have
been using for my default styles, did something change?  (From a reading
through the man page, it doesn't appear so)

Style "*" MWMButtons, MWMFunctions, MWMDecor, HintOverride
Style "*" ForeColor white, BackColor lightsteelblue3
Style "*" ActivePlacement, NoPPosition 

Or am I doing something wrong?

John

__
John Tillema             email: [email-masked]
Hewlett-Packard      ** Standard disclaimers apply **
Fort Collins Systems Lab      Quote of the Minute:
The only reason God was able to make the world in 7 days was he didn't have to
remain compatible with the previous version.
  -- Peter da Silva
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Mark Borges <[email-masked]>
Date: 23 Jan 1997 09:48:13 -0700

>> On Tue, 21 Jan 1997 17:36:58 -0500 (EST),
>> Randall S Winchester(r) wrote:
r> On Fri, 17 Jan 1997, Eddy J. Gurney wrote:
r> : On Jan 17, 23:25, Albrecht Kadlec wrote:
r> : 
r> : ....stuff deleted.
r> : 
r> : Finally, something that needs to be fixed in Fvwm.tmpl: in order for
r> : the Solaris dynamic linker to find the X libraries, I needed to change
r> : the FvwmModuleTarget and FvwmProgramTarget from '$(CC) -o $@...' to
r> : '$(CCLINK) -o $@...'. This is very important! It makes sure the
r> : LD_LIBRARY_PATH gets set before the link so the dynamic linker can find
r> : the X libraries. Prior to making this change, 'fvwm2' would not run,

r> This is indeed a problem with CC=cc. It is also true with some versions of
r> gcc. I have just upgraded from gcc 2.7.0 which did not have this problem to
r> 2.7.2 which does as well as older gcc 2.6.*. In the gcc case it is not
r> LD_LIBRARY_PATH that gets set but rather LD_RUN_PATH, but the end result is

I see LD_RUN_PATH set as well. I always explicitly unset LD_LIBRARY_PATH
before any builds -- it seems to always lead to trouble
here. Solaris-2.5, cc-4.0, X11R6.3.

r> the same. Either of thses are supposed to get set to $(USRLIBDIR). In my
r> case this would be USRLIBDIR = /usr/local/X11R6/lib. Imake of corse thakes
r> care of this part.

This (use of CCLINK instead of CC) is a nice trick -- do older xmkmf's
generate this CCLINK as well?

Previously I was building with 

    make EXTRA_LDOPTIONS=-R/usr/local/X11R6/lib

which also works (but is more typing).

Thanks.

-- 
  -mb-