Subject: Notification: incoming/705

From: [email-masked]
Date: Tue, 13 Mar 2001 01:42:50 -0600

FVWM Bug Tracking notification

new message incoming/705

Message summary for PR#705
	From: [email-masked]
	Subject: Toggled button styles broken
	Date: Tue, 13 Mar 2001 01:42:49 -0600
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

>From [email-masked] Tue Mar 13 01:42:50 2001
From: [email-masked]
To: [email-masked]
Subject: Toggled button styles broken
Date: Tue, 13 Mar 2001 01:42:49 -0600

Full_Name: Pekka Marjola
Version: 2.3.30
CVS_Date: 2001-03-12
OS: Linux
X_Server: XFree-3.3.6
Submission from: (NULL) (194.197.118.69)

Setting ToggledActiveUp style for Title causes the title to use wrong style
(ActiveDown or ToggleActiveDown, didn't test/read code). Even though the
Title does not need Toggled styles, these are copied for buttons, so the
Toggled styles need not be specified for Stick/WindowsShade/Maximize
buttons separately (and three times).

DestroyDecor Standard
AddToDecor Standard
+	TitleStyle	  ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+	TitleStyle ToggledActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+	TitleStyle	  ActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+	TitleStyle ToggledActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+	ButtonStyle 0 Pixmap mini.stick.xpm
+	ButtonStyle 0 ToggledActiveUp	(Pixmap mini.stickpressed.xpm)
+	ButtonStyle 0 ToggledActiveDown	(Pixmap mini.stickpressed.xpm)
+	ButtonStyle 0 - MWMDecorStick
+	AddButtonStyle All -- UseTitleStyle flat

Style * UseDecor Standard

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Pekka Marjola <[email-masked]>
Date: 14 Mar 2001 14:10:59 +0200

>>>>> In <[email-masked]>,
>>>>> On Tue, 13 Mar 2001 16:56:51 +0100,
>>>>> "Dominik" == Dominik Vogt <[email-masked]> writes:

>> buttons separately (and three times).

Dominik> Could you please rephrase that?  I don't understand the problem.

Actually, I noticed more strange things: For the first style, the bug
exists, but not for the second similar style. Try following:

Emacs gets ActiveDown style for ActiveUp, but xterm does not.

(So the toggled styles are defined for title so that I do not have to
define the styles for every toggled button; see below.)

DestroyDecor Foo
AddToDecor Foo
+       BorderStyle Simple
+       BorderStyle Inactive (-- HiddenHandles)
+       TitleStyle        ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle ToggledActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle        ActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle ToggledActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle        Inactive (VGradient 10 LightBlue4 LightBlue3 -- flat)
+       TitleStyle ToggledInactive (VGradient 10 LightBlue4 LightBlue3 -- flat)

DestroyDecor Standard
AddToDecor Standard
+       BorderStyle Simple
+       BorderStyle Inactive (-- HiddenHandles)
+       TitleStyle        ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle ToggledActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle        ActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle ToggledActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle        Inactive (VGradient 10 LightBlue4 LightBlue3 -- flat)
+       TitleStyle ToggledInactive (VGradient 10 LightBlue4 LightBlue3 -- flat)
+       ButtonStyle Reset
+       ButtonStyle 2 Pixmap jbomb.xpm
+       ButtonStyle 4 Vector 5 20x20@1 20x80@1 80x80@0 80x20@0 20x20@1
+       ButtonStyle 6 Vector 5 40x40@1 40x60@1 60x60@0 60x40@0 40x40@1
+       ButtonStyle 8 Vector 5 20x40@1 20x60@1 80x60@0 80x40@0 20x40@1
+       ButtonStyle 0 Pixmap mini.stick.xpm
+       ButtonStyle 0 ToggledInactive   (Pixmap mini.stickpressed.xpm)
+       ButtonStyle 0 ToggledActiveUp   (Pixmap mini.stickpressed.xpm)
+       ButtonStyle 0 ToggledActiveDown (Pixmap mini.stickpressed.xpm)
+       ButtonStyle 1 MiniIcon
+       ButtonStyle 1 - MWMDecorMenu
+       ButtonStyle 4 - MWMDecorMax
+       ButtonStyle 6 - MWMDecorMin
+       ButtonStyle 8 - MWMDecorShade
+       ButtonStyle 0 - MWMDecorStick
+       AddButtonStyle All -- UseTitleStyle flat

Style Emacs UseDecor Foo
Style XTerm UseDecor Standard

-- 
[email-masked] * http://www.iki.fi/pema/
Saga Keeper 	(Ars Magica web tool)	1.0b6	http://www.sagakeeper.com/
pema-init	(emacs startup)		0.18	http://www.iki.fi/pema/emacs/
zbkrc		(shell startup)		0.18	http://www.iki.fi/pema/zbkrc/
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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, 13 Mar 2001 16:56:51 +0100

> buttons separately (and three times).

Could you please rephrase that?  I don't understand the problem.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Sat, 17 Mar 2001 23:38:18 +0100

> Emacs gets ActiveDown style for ActiveUp, but xterm does not.

Unfortunately I can't confirm any of this.  I tried this by
reading in the the configs you sent with "read" from a file in a
running session with my normal config and with an empty config and
it does not happen here.

Can you try to 

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Pekka Marjola <[email-masked]>
Date: 18 Mar 2001 11:15:14 +0200

>>>>> In <[email-masked]>,
>>>>> On Sat, 17 Mar 2001 23:38:18 +0100,
>>>>> "Dominik" == Dominik Vogt <[email-masked]> writes:

Dominik> Unfortunately I can't confirm any of this.  I tried this by
Dominik> reading in the the configs you sent with "read" from a file in a
Dominik> running session with my normal config and with an empty config and
Dominik> it does not happen here.

Dominik> Can you try to 

OK, here's a .fvwm2rc, which demonstrates problem. The problem
disappears, if I remove the *FvwmTheme line.

*FvwmThemeColorset 5    Foreground black, Background #009acd
ModuleSynchronous FvwmTheme

DestroyDecor Foo
AddToDecor Foo
+       BorderStyle Simple

DestroyDecor Standard
AddToDecor Standard
+       BorderStyle Simple
        
Style XTerm UseDecor Foo

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 18 Mar 2001 14:25:41 +0100

> Style *         UseDecor Standard

The deocors' contents are the same, and it still happens only for
xterms and not for other windows?  That is odd.  Are you
absolutely sure that everything was built, installed and started
correctly?  Such weirdness usually indicates that parts of fvwm do
not fit together - e.g. fvwm was linked with an outdated fvwmlib.
I can't think of anything else that explains why the ActiveDown
style could be used.  According to the code it will never be used
without a button press.

I have added a debug statement to borders.c at line 400.  If the
problem persists after a fresh checkout and rebuild, pay attention
to the output it generates.  As far as I understood, the buggy
windows get ActiveDown style as soon as the pointer enters the
window.  If the ActiveDown style is really used, the debug
statement would generate some output at this moment.

Bye

Dominik ^_^  ^_^

---

From: Pekka Marjola <[email-masked]>
Date: 18 Mar 2001 17:30:46 +0200

>>>>> In <[email-masked]>,
>>>>> On Sun, 18 Mar 2001 14:25:41 +0100,

Dominik> The deocors' contents are the same, and it still happens only for
Dominik> xterms and not for other windows?

Xterm is there just for an example. Any window shows the bug.

Dominik> That is odd. Are you absolutely sure that everything was
Dominik> built, installed and started correctly? Such weirdness
Dominik> usually indicates that parts of fvwm do not fit together -
Dominik> e.g. fvwm was linked with an outdated fvwmlib. I can't think
Dominik> of anything else that explains why the ActiveDown style could
Dominik> be used. According to the code it will never be used without
Dominik> a button press.

Well, I have not run make clean, just automake & stuff. I'll try with
make clean, too.

Dominik> I have added a debug statement to borders.c at line 400.  If the
Dominik> problem persists after a fresh checkout and rebuild, pay attention
Dominik> to the output it generates.  As far as I understood, the buggy
Dominik> windows get ActiveDown style as soon as the pointer enters the
Dominik> window.  If the ActiveDown style is really used, the debug
Dominik> statement would generate some output at this moment.

---

From: Pekka Marjola <[email-masked]>
Date: 18 Mar 2001 17:52:06 +0200

Actually, now it uses black/black for instead of ActiveUp. Black was
used this morning, too, but not earlier this week.

Here's debug output (when pressed):

// active down usedpw = 0x01000042, w = 0x01000042, has_focus = 1, toggled = 0

For another window (with correct title decoration):

// active down usedpw = 0x0100004e, w = 0x0100004e, has_focus = 1, toggled = 0

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 18 Mar 2001 18:28:38 +0100

> // active down usedpw = 0x0100004e, w = 0x0100004e, has_focus = 1, toggled = 0

It seems that the ActiveDown style is not actually used.  Perhaps
there is some memory corruption going on?  Do you have a memory
debugger like insure or purify handy to check this?  If not, could
you try efence or dmalloc instead (configure with --enable-efence
or --enable-dmalloc)?

Bye

Dominik ^_^  ^_^

---

From: Pekka Marjola <[email-masked]>
Date: 18 Mar 2001 19:05:15 +0200

>>>>> In <[email-masked]>,
>>>>> On Sun, 18 Mar 2001 18:28:38 +0100,

Dominik> Do you have a memory debugger like insure or purify handy to
Dominik> check this?

Nope :(

Dominik> If not, could you try efence or dmalloc instead
Dominik> (configure with --enable-efence or --enable-dmalloc)?

Yes, but not today. I have already coded whole day.

Unfortunately I'm rather busy next week, so I cannot promise any date.

---

From: Pekka Marjola <[email-masked]>
Date: 26 Mar 2001 15:03:44 +0300

>>>>> "Dominik" == Dominik Vogt <[email-masked]> writes:

Dominik> you try efence or dmalloc instead (configure with --enable-efence
Dominik> or --enable-dmalloc)?

Efence did not complain anything, but strange effects were noticed in
AllocLinearGradient, when it is called for the first time:
XAllocColor returns empty colors (but not 0 nor BadColor).

256         if (!XAllocColor(Pdpy, Pcmap, &c))
(gdb) n
254         c.green = (unsigned short)(g + (i * dg + 0.5));
(gdb) p c
$36 = {pixel = 0, red = 0, green = 0, blue = 0, flags = 7 '\a', pad = 0 '\000'}

dr changes to infinite.

Saga Keeper 	(Ars Magica web tool)	1.0b7	http://www.sagakeeper.com/

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 27 Mar 2001 12:40:41 +0200

On Mon, Mar 26, 2001 at 03:03:44PM +0300, Pekka Marjola wrote:
> y

Hm.

  if (npixels < 1)
  {
    fprintf(stderr, "AllocLinearGradient: Invalid number of pixels: %d\n",
            npixels);
    return NULL;
  }
  ...
  div = (npixels == 1) ? 1 : npixels - 1;
  ...
  dr = (float)(to.red - from.red) / (float)div;

So, I don't see how dr can become infinity if to.red and from.red
are properly set.  On the other hand:

  if (!s_from || !XParseColor(Pdpy, Pcmap, s_from, &from))
    return NULL;
  if (!s_to || !XParseColor(Pdpy, Pcmap, s_to, &to))
    return NULL;

So if either to or from are not set correctly, then the
XParseColor() function is broken (?)  Can you provide more verbose
debug output?  What are the contents of the parameters?  If
the input values are correct, there must be a line in the function
at which things start to go wrong.

BTW, please post your config file, perhaps it helps to reproduce
this.

Bye

Dominik ^_^  ^_^

---

From: Pekka Marjola <[email-masked]>
Date: 27 Mar 2001 16:14:59 +0300

>>>>> In <[email-masked]>,
>>>>> On Tue, 27 Mar 2001 12:40:41 +0200,

Dominik> So if either to or from are not set correctly, then the
Dominik> XParseColor() function is broken (?)  Can you provide more verbose
Dominik> debug output?  What are the contents of the parameters?  If
Dominik> the input values are correct, there must be a line in the function
Dominik> at which things start to go wrong.

XAllocColor returns null pixel values, and then sometimes r and dr
start to get weird values. I have 24/32 bit TrueColor display mode.

pinguino% gdb /local/pkg/fvwm-efence-2.3.30-2/bin/fvwm2
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) break AllocLinearGradient
Breakpoint 1 at 0x808cc94: file Graphics.c, line 218.
(gdb) break 250
Breakpoint 2 at 0x808cdb5: file Graphics.c, line 250.
(gdb) break 255
Breakpoint 3 at 0x808ce27: file Graphics.c, line 255.
(gdb) r
Starting program: /local/pkg/fvwm-efence-2.3.30-2/bin/fvwm2 

Breakpoint 1, AllocLinearGradient (s_from=0x80ad668 "IndianRed4", 
    s_to=0x80b0a20 "OrangeRed", npixels=10, skip_first_color=0)
    at Graphics.c:218
218       int got_all = 1;
(gdb) c
Continuing.

Breakpoint 2, AllocLinearGradient (s_from=0x80ad668 "IndianRed4", 
    s_to=0x80b0a20 "OrangeRed", npixels=10, skip_first_color=0)
    at Graphics.c:250
250       c.flags = DoRed | DoGreen | DoBlue;
(gdb) p from
$12 = {pixel = 0, red = 35723, green = 14906, blue = 14906, flags = 7 '\a', 
  pad = 0 '\000'}
(gdb) p to
$13 = {pixel = 40, red = 65535, green = 17733, blue = 0, flags = 7 '\a', 
  pad = -65 '¿'}
(gdb) p c
$14 = {pixel = 0, red = 35723, green = 14906, blue = 14906, flags = 7 '\a', 
  pad = 0 '\000'}
(gdb) c
Continuing.

Breakpoint 3, AllocLinearGradient (s_from=0x80ad668 "IndianRed4", 
    s_to=0x80b0a20 "OrangeRed", npixels=10, skip_first_color=0)
    at Graphics.c:255
255         c.blue  = (unsigned short)(b + (i * db + 0.5));
(gdb) p c
$15 = {pixel = 0, red = 35723, green = 14906, blue = 14906, flags = 7 '\a', 
  pad = 0 '\000'}
(gdb) n
253         c.red   = (unsigned short)(r + (i * dr + 0.5));
(gdb) 
254         c.green = (unsigned short)(g + (i * dg + 0.5));
(gdb) 
255         c.blue  = (unsigned short)(b + (i * db + 0.5));
(gdb) 
256         if (!XAllocColor(Pdpy, Pcmap, &c))
(gdb) 
254         c.green = (unsigned short)(g + (i * dg + 0.5));
(gdb) p c
$16 = {pixel = 0, red = 0, green = 14906, blue = 14906, flags = 7 '\a', 
  pad = 0 '\000'}
(gdb) n
255         c.blue  = (unsigned short)(b + (i * db + 0.5));
(gdb) 
256         if (!XAllocColor(Pdpy, Pcmap, &c))
(gdb) 
258         pixels[ i ] = c.pixel;
(gdb) p c
$17 = {pixel = 0, red = 0, green = 0, blue = 0, flags = 7 '\a', pad = 0 '\000'}
(gdb) 

Dominik> BTW, please post your config file, perhaps it helps to reproduce
Dominik> this.

FvwmTheme must be running to notice the effect.

DestroyDecor Foo
AddToDecor Foo
+       BorderStyle Simple
+       BorderStyle Inactive (-- HiddenHandles)
+       TitleStyle        ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
#+      TitleStyle ToggledActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle        ActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
#+      TitleStyle ToggledActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle        Inactive (VGradient 10 LightBlue4 LightBlue3 -- flat)
#+      TitleStyle ToggledInactive (VGradient 10 LightBlue4 LightBlue3 -- flat)

DestroyDecor Standard
AddToDecor Standard
+       BorderStyle Simple
+       BorderStyle Inactive (-- HiddenHandles)
+       TitleStyle        ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
#+      TitleStyle ToggledActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)
+       TitleStyle        ActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
#+      TitleStyle ToggledActiveDown (VGradient 10 #401515 OrangeRed3 -- flat)
+       TitleStyle        Inactive (VGradient 10 LightBlue4 LightBlue3 -- flat)
#+      TitleStyle ToggledInactive (VGradient 10 LightBlue4 LightBlue3 -- flat)

zbkrc		(shell startup)		0.20	http://www.iki.fi/pema/zbkrc/

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Mar 2001 02:41:12 +0200

> $16 = {pixel = 0, red = 0, green = 14906, blue = 14906, flags = 7 '\a', 

Weird. What if you explicitly turn off optimizing compile with

  make CFLAGS="-g -Wall -Werr"

in the libs directory?

I added some debug output to Graphics.c.  To enable it, set the
DEBUG_ALG macro in line 238 to 1.  Then post the output (all lines
prepended with "***").

Bye

Dominik ^_^  ^_^

---

From: Pekka Marjola <[email-masked]>
Date: 28 Mar 2001 10:55:06 +0300

>>>>> In <[email-masked]>,
>>>>> On Wed, 28 Mar 2001 02:41:12 +0200,

Dominik> Weird. What if you explicitly turn off optimizing compile with

Dominik> make CFLAGS="-g -Wall -Werr"

Dominik> in the libs directory?

Did that... (with latest CVS sources) No more troubles. 

Then I did make clean, and re-compiled the whole stuff with -O6, and
even then the problem did not appear anymore.

(I have Debian unstable, and did dist-upgrade again today. Lots of X
library stuff was upgraded, too.)

Dominik> I added some debug output to Graphics.c.  To enable it, set the
Dominik> DEBUG_ALG macro in line 238 to 1.  Then post the output (all lines
Dominik> prepended with "***").

Do you still want this?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Mar 2001 09:05:16 +0200

> Dominik> prepended with "***").

No.  I somewhat improved the formula that calculates the colours
and that seems to hide or fix the problem now.  I didn't find a
reason for this problem though.

Bye

Dominik ^_^  ^_^

---

From: Pekka Marjola <[email-masked]>
Date: 30 Mar 2001 11:36:17 +0300

>>>>> In <[email-masked]>,
>>>>> On Wed, 28 Mar 2001 09:05:16 +0200,

Oops, seems like I had Module FvwmTheme line commented out...

So I can still notice the problem :(

Actually, it seems like allocating the first gradient always fails.
For example, the following works:

AddToDecor Foo

But this does not:

AddToDecor Foo

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Mar 2001 21:32:57 +0200

> +       TitleStyle        ActiveUp (VGradient 10 IndianRed4 OrangeRed -- flat)

Then please try that snapshot with the debug code.  In the end it
seems to be a problem of the X server that is triggered under
obscure circumstance.

Could you try XFree 4.x?

Bye

Dominik ^_^  ^_^