Subject: bugs 122, 128, 137, 144, 154, 155

From: Dominik Vogt <[email-masked]>
Date: Tue, 2 Feb 1999 19:14:43 +0100

I've lost track a bit. Could someone have a look at said bugs in
the incoming directory and see which are resolved/setup problem/...
i.e. which can be moved to some 'resolved' state?

Bye

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Tim Phipps <[email-masked]>
Date: Tue, 02 Feb 1999 18:26:05 +0000

128) I think is resolved in that AutoHide is known to be dodgy and there
is already a bug report.  The focus changing bit was due to running the
wrong version of FvwmTaskBar.

154) is the FvwmWinList core dump that caused us to go to 2.1.11. It's
fixed

Cheers,
Tim.

---

From: [email-masked] (Paul D. Smith)
Date: 02 Feb 1999 13:41:50 -0500

137) This was fixed before 2.1.10 came out, I think; we switched the
     configure tests and makefiles around to put the specific XPM lib
     and include flags before the generic X flags.

     Marked fixed.

144) This one we never really resolved.  The situation was very odd, to
     begin with; Steve (? someone, anyway) suggested using
     LD_LIBRARY_PATH and that resolved the problem for the user.  We
     decided not to bother pursuing it.

     Marked fixed.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 2 Feb 1999 19:48:33 +0100

> i.e. which can be moved to some 'resolved' state?

122 was unreproducible and 155 hasn't been pursued yet. Is this
correct?

Bye

Dominik

---

From: Brad Giaccio <[email-masked]>
Date: Tue, 2 Feb 1999 14:41:19 -0500

> 122 was unreproducible and 155 hasn't been pursued yet. Is this

For 155 I think I have seen this, what had done was eaten up all my colors on an 8-bit display changed some of the title stuff in FvwmConsole and then did a recapture to pick up the changes .

When te recapture finished I didn't get any buttons at all until I freed some colors and did another recapture.  I'm not sure this is the same bug.  If it is I would say its not a bug but a limitation of a bit displays.

Brad
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 02 Feb 1999 14:49:05 -0500

%% Brad Giaccio <[email-masked]> writes:

  bg> For 155 I think I have seen this, what had done was eaten up all
  bg> my colors on an 8-bit display changed some of the title stuff in
  bg> FvwmConsole and then did a recapture to pick up the changes .

  bg> When te recapture finished I didn't get any buttons at all until I
  bg> freed some colors and did another recapture.  I'm not sure this is
  bg> the same bug.  If it is I would say its not a bug but a limitation
  bg> of a bit displays.

Well, it's still a bug I think.

If fvwm can't allocate a pixmap for a button, for any reason including
lack of colors, it should choose a default and still allow the button to
operate (while printing an error to the log about it).

It must be more complex than simply not being able to create the pixmap,
because I've quite often fat-fingered my config file such that a pixmap
could not be found; then the button was blank but it still worked.

Never did it during a recapture, I guess.

---

From: Dan Espen <[email-masked]>
Date: Tue, 02 Feb 1999 15:07:05 -0500

> Never did it during a recapture, I guess.

Given the problem report:

The title bar buttons stop  working occasionally, they no longer press
in and do not perform their defined function.

I don't see this as a color map problem.

Given the way the Title bar buttons are bound:

  Mouse 0 2 N     Close
  Mouse 0 3 N     Stick
  Mouse 0 4 N     Maximize
  Mouse 3 6 N     Replace
  Mouse 0 6 N     Iconify
            ^

I would think it very likely there was a modifier active at the time.
(Ie. num-lock, or caps-lock was on.)

This would explain the seemingly random way the symptom appeared and disappeared.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].