Subject: feedback window colorset

From: Brad Giaccio <[email-masked]>
Date: Fri, 8 Oct 1999 09:06:54 -0400

I been playing around with my colorsets, and I noticed that we have the
feedback window set to Colorset 0, with no way to modify it.  Dominik,
did you plan on adding a command for this?  If not do you want me to
take a look.  And what should the option be FeedbackWindowColorset?

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://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: Fri, 8 Oct 1999 15:33:08 +0200

> take a look.  And what should the option be FeedbackWindowColorset?

Currently it is hardcoded to colour set 0 because the command to set
these colours is 'DefaultColors'.  The last thing I know is that the
default colours are not use anywhere else, but that was before colour
set support was added.  Tim? What are the implications if we change
this?

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://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: Tim Phipps <[email-masked]>
Date: Fri, 08 Oct 1999 15:34:30 +0100

> set support was added.  Tim? What are the implications if we change

I made fvwm create colorset 0 to prevent the case where FvwmTheme is not
run and a module tries to access the colorsets.  I think what would
happen if DefaultColors did not create colorset 0 is that any modules
that used colorsets would display in black on black (pixel 0 on pixel
0). I don't think they would segv since I think they all do an
AllocColorset(0) at start up but they would be unusable.

It's not necessary to tie DefaultColors to colorset 0 and it might
simplify some code in fvwm and FvwmTheme (it could ignore colorset
config lines from fvwm).

I'm not sure what DefaultColors actually controls. What happens if you
start fvwm with no color specifications other than DefaultColors? What
color are the window borders and menus? If they are not set by
DefaultColors then we have some other undocumented defaults in there.

If DefaultColors only sets the feedback window then shouldn't we rename
it and make a colorset version of the command?

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 8 Oct 1999 10:58:40 -0400

> it and make a colorset version of the command?

As I learned DefaultColors only seems to touch the feedback window.

Style "*" ForeColor, BackColor, 
HilightColor <fore> <back>
handles window borders and titles.

I think, menus are all controlled by MenuStyle lines now.  I don't know
if any of the above has an effect.

So I would say that DefaultColors becomes FeedBackColors and
FeedBackColorset

Comments?
Brad

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 8 Oct 1999 17:01:25 +0200

On Fri, Oct 08, 1999 at 03:34:30PM +0100, Tim Phipps wrote:
> color are the window borders and menus?

Borders and menus have their own defaults.  Furthermore the defaults
can not be changed.

> If they are not set by

Yes.

>From the man page:

  DefaultColors sets the default forground and background
  colors used in miscellaneous windows created by fvwm, for example
  in the geometry feedback windows during a move or resize operation.
  If you don't want to change one color or the other, use - as its
  color name.  To revert to the builtin default colors omit both
  color names.

  Note that the default colors are not used in menus, window titles
  or icon titles.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I'm not sure it's worth the trouble to rename the command.  Yes,
the name is confusing, but if nobody complains I wouldn't change
it.  Default colours could have an alternative syntax:

  DefaultColors <fore> <back>

or

  DefaultColors Colorset <n>

No big deal.  I'd recommend to use 'DefaultColors Colorset 0' as
the default that is set in fvwm.c.  'MiscColors' might have been
a better name.  BTW, the HilightColors command could use the same
enhancement.

Bye

Domink ^_^

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 14 Oct 1999 09:21:52 -0400

> a better name.  BTW, the HilightColors command could use the same

Well that took a little longer than planned but here is the patch and Changelog for the DefaultColors command I'll take a look at HilightColors next.

1999-10-14  Brad Giaccio  <[email-masked]>  

    * fvwm/builtins.c (HandleColorset):
    (SetDefaultColors):
    (ApplyDefaultFontAndColors):
    * fvwm/add_window.c (AddWindow):
    * fvwm/fvwm.c (main): 
    (InitVariables):
    * fvwm/icons.c (CreateIconWindow):
    * fvwm/screen.h:
    * fvwm/fvmw2.1:
    added DefaultColors Colorset <n> command

---

From: Tim Phipps <[email-masked]>
Date: Fri, 15 Oct 1999 14:19:04 +0100

> Well that took a little longer than planned but here is the patch and Changelog for the DefaultColors command I'll take a look at HilightColors next.

Could we back this patch out please? I think it could cause color
corruption on PseudoColor displays. With theis patch fvwm does not keep
track of wetehr it alloc'd a pixel or if it came from FvwmTheme. It
XFreeColors pixels regardless whihc could result in it freeing a pixel
that it shouldn't e.g.

fvwm does a "DefaultColors pink navy": fvwm allocs pink & navy
fvwm does a "menustyle * ..... yellow blue": fvwm allocs yellow & blue
FvwmTheme does a "colorset 0 yellow red": it allocs yellow & red
fvwm loads it copy of colorset 0 with yellow & red
fvwm does a "defaultcolors orange purple": fvwm frees yellow & red,
allocs orange & purple.
FvwmTheme does a "colorset 0 x y": frees yellow & red

What happens here is that the x server will free the red and yellow
pixels for re-use. When another program allocs colors the fvwm menu
colors will get trashed because it is using the pixel it thinks is
yellow.

fvwm should really keep the pixels it allocs seperate from the colorset
copies.

I think FvwmTheme suffers from this problem, I'll sort it out. But I
think we need to seperate the DefaultColors pixels from the colorset
pixels.

Didn't this patch come about because someone didn't like the feedback
window using colorset 0? Wouldn't it be easier to just say it is fixed
at 0 and just use colorsets other than 0 for everything else?

Cheers,
Tim.

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 15 Oct 1999 10:09:13 -0400

> at 0 and just use colorsets other than 0 for everything else?

Tim, unfortunetly I was the someone. The problem is the same problem
exists with or without my patch.  The code origionally looked like this:

 if (!StrEquals(fore, "-"))
    {
        FreeColors(&Colorset[0].fg, 1);
        Colorset[0].fg = GetColor(fore); 
    }
  if (!StrEquals(back, "-"))
    {
        FreeColors(&Colorset[0].bg, 1);
        FreeColors(&Colorset[0].hilite, 1);
        FreeColors(&Colorset[0].shadow, 1);
        Colorset[0].bg = GetColor(back);
        Colorset[0].hilite = GetHilite(Colorset[0].bg);
        Colorset[0].shadow = GetShadow(Colorset[0].bg);
    }

As you can see this presents the same problem as you described above.
So sure we can back out my patch, I was just trying to be consistent.
But regardless we need to do something different here.