Subject: Re: FVWM: Hilight active menu fg w/out active menu bg?

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Oct 2002 17:31:39 +0000

On 21 Oct 2002 12:53:28 +0200, Dominik Vogt wrote:
> 
> On Sat, Oct 19, 2002 at 06:27:04PM +0000, Mikhael Goikhman wrote:
> > On 19 Oct 2002 15:06:20 +1000, Scott Smedley wrote:
> > > 
> > > Is there a way to highlight the active fg menu item without having to
> > > highlight the bg of the active menu item?
> > > 
> > > This highlights the fg in AntiqueWhite (which is what I want) & the
> > > background in a horrible green:
> > > 
> > > ImagePath $HOME/images/icons
> > > MenuStyle * MenuFace DGradient 255 2 darkgray 50 MidnightBlue 50 white
> > > MenuStyle * SidePic happy.xpm
> > > MenuStyle * ActiveFore AntiqueWhite
> > > MenuStyle * HilightBack green
> > > 
> > > If I comment out the HilightBack line, then there is no bg (obviously)
> > > but also no AntiqueWhite on the active menu item ...
> > > 
> > > What I really want is the AntiqueWhite fg & my menuface gradient to
> > > still be visible in the bg.
> > 
> > You can't do this. The only current possibility is to have a solid
> > active background if it is different from the main background.
> 
> I have fixed this.  With the latest code from CVS it should work
> fine.  When using an ActiveColorset, you have to specifiy
> 
>   MenuStyle * HilightBackOff, ActiveFore, ActiveColorset <n>

Well, this line works for me just like before the latest change.
And it it ok, please don't change this.

The real fix for colorsets is to implement the fully functional
ActiveColorset as I wrote below.

In the future I would remove both HilightBack and ActiveFore as well as
MenuFace. They are all pretty redudant.

> > What you really want is to have a transparent ActiveColorset, but it
> > is not currently implemented.
> > 
> > Hopefully someone (Olivier) will enhance the menu ActiveColorset to be
> > fully functional, including Pixmap and Transparent options.

Regards,
Mikhael.
--
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: Mon, 21 Oct 2002 19:55:53 +0200

> And it it ok, please don't change this.

No, you want

  MenuStyle * HilightBackOff, ActiveForeOff, ActiveColorset <n>

I see no reason at all why ActiveFore should only work with
HilightBack.

> MenuFace. They are all pretty redudant.

Agreed with ActiveFore and HilightBack (with coour arguments), but
I won't remove everything in favour of colour sets.  Don't forget
that colour sets can eat up a lot of memory or be very slow.

> > > fully functional, including Pixmap and Transparent options.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
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: Mikhael Goikhman <[email-masked]>
Date: Mon, 21 Oct 2002 21:08:27 +0000

On 21 Oct 2002 19:55:53 +0200, Dominik Vogt wrote:
> > > > > Is there a way to highlight the active fg menu item without
> > > > > having to highlight the bg of the active menu item?
> > > > > 
> > > > > This highlights the fg in AntiqueWhite (which is what I want) &
> > > > > the background in a horrible green:
> > > > > 
> > > > > If I comment out the HilightBack line, then there is no bg
> > > > > (obviously) but also no AntiqueWhite on the active menu item ...
> > > > > 
> > > > > What I really want is the AntiqueWhite fg & my menuface gradient
> > > > > to still be visible in the bg.
> > > > 

Both of these lines has the same effect, because HilightBackOff turns
active background and foreground off completely.

But I see that ActiveForeOff/ActiveFore does work with HilightBack,
i.e. makes ActiveColorset fg be ignored or not.

Now, about the whole idea of ignoring one or another colorset component.
This may be useful, but such functionality is only a small part of a
bigger functionality: take the original main colorset colors and do
some transformation on them (for example tint) and not just leave as is.

Such functionality is useful everywhere, think FvwmIconMan or FvwmButtons
where there is one parent colorset and another one that may or may not
reuse the parent colorset. This is why I would not achieve such
functionality using menu booleans, but move it to colorsets.

I see 2 possible solutions. One, statical, is available now.
I use here symbolic names for colorset instead of numbers for clarity.

  MenuStyle * MenuColorset MENU. ActiveColorset MENU2

  Colorset MENU fg yellow, bg navy, Pixmap navy_sky.xpm
  Colorset MENU2 fg $[fg.csMENU], bg $[bg.csMENU], Plain

or:

  Colorset MENU2 fg cyan, Transparent

Another solution is dynamical, like:

  Colorset MENU fg yellow, bg navy, Pixmap navy_sky.xpm
  Colorset MENU2 fg parent, bg parent, Plain

where "parent" is handled specially just like the current "contrast" and
"average" are. This only valid in the 2-colorset context, where the parent
colorset is defined.

> that colour sets can eat up a lot of memory or be very slow.

I don't think there is a big difference in memory or speed if no fancy
features are used. But we can only guess without benchmarks.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Oct 2002 00:38:15 +0200

> i.e. makes ActiveColorset fg be ignored or not.

That is all an attempt to keep the old menu style logic.  In my
eyes it makes no sense to artificially limit the possibilities of
what gets drawn in which colour.

> functionality using menu booleans, but move it to colorsets.

There is one flaw in this reasoning:  there is no parent colorset
here.  Menu items are not buttons in a large button (the menu)
that could shine through or not.  Menu items are solely a
foreground over a constant background.

And there is another problem with colour sets.  You can not say
"ignore this part from my colour set and use it from that other
colour set instead".  That is what we need here.  The idea of
colour sets is to provide the colours and leave it to the caller
which (s)he wants to use.

>   Colorset MENU2 fg cyan, Transparent
                            ^^^^^^^^^^^

Then you would see the background of the root window on the menu.

> "average" are. This only valid in the 2-colorset context, where the parent

I don't like that idea at all.  Colour sets must not know anything
of each other.  When transformations have to be done, a higher
instance has to do them.  We should take care not to overload
colour sets with unrelated functionality.

> features are used. But we can only guess without benchmarks.

We have done benchmarks with the [BDHV]Gradient menu faces and it
makes a big difference.  For example, when I fire up my directory
menu script on the /dev directory, it takes up 4.5 screens at
1152x870x32 = 18 MB for the colour set backgrounds while the menu
built-in gradient implementation uses only a few bytes.

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: Mikhael Goikhman <[email-masked]>
Date: Tue, 22 Oct 2002 02:28:00 +0000

> foreground over a constant background.

I don't see any logical difference between FvwmIconMan and menus.
Whatever functionality you have in one regarding the active item, you want
in another.

> which (s)he wants to use.

Colorsets hold color information. There is nothing wrong for this
information to be "use parent's colors or any defaults if there is no
parent".

> >   Colorset MENU2 fg cyan, Transparent

This depends on how ActiveColorset is implemented, currently it is not
really used except for storing 2 values fg and bg.

I would like the active menu item to have the parent colorset that is the
whole menu surface. This way there is a lot of flexibility without any
additional flags. Of course if this is proven to have a bad performance,
this is another story. But logically I want menus not to be different from
FvwmIconMan or FvwmButtons.

> colour sets with unrelated functionality.

Yes, but there may be library functions that merge 2 colorsets. And even
create new colorsets on the fly if needed.

Do you suggest, instead, to have a lot of flags (similarly to what
ActiveFore and HilightBack do) and the same code in different places?

> built-in gradient implementation uses only a few bytes.

Gradients in colorsets are not currently optimized, but this does not mean
they can't be made as effective. I don't suggest to remove MenuFace before
this happens.

Regards,
Mikhael.