On Mon, Oct 21, 2002 at 09:08:27PM +0000, Mikhael Goikhman wrote:
> On 21 Oct 2002 19:55:53 +0200, Dominik Vogt wrote:
> >
> > On Mon, Oct 21, 2002 at 05:31:39PM +0000, Mikhael Goikhman wrote:
> > > 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.
> >
> > No, you want
> >
> > MenuStyle * HilightBackOff, ActiveForeOff, ActiveColorset <n>
> >
> > I see no reason at all why ActiveFore should only work with
> > HilightBack.
>
> 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.
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.
> 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.
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.
> 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
^^^^^^^^^^^
Then you would see the background of the root window on the menu.
> 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.
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.
> > > 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.
> >
> > 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.
>
> 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.
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.
> > > > > 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.
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
