Subject: SetMenuStyleProblem

From: [email-masked]
Date: Wed, 16 Dec 1998 14:13:15 -0600 (CST)

Full_Name: Brad Giaccio
Version: 2.1.6
CVS_Date: 11:00EST Dec,16,1998
OS: Solaris 2.6
X_Server: Xsun
Submission from: (NULL) (199.99.166.68)

I have removed all refrences to MenuStyle from my rc file and have just
been using 
SetMenuStyle, but in light of recent discusions of the feedback window and
removal 
of the next tag I started paying a little more attention.
If you use a line like the following just up to mwm there is no problem. 
The problem
arises when you add *Gradient.  This calls ReadMenuFace which sets the
style element 
of the passed in MenuFace to [HVD]GradientMenu.  But style can also contain
 MWM FVWM or 
Win Menu.  So if you have a gradient in your menu style all conditionals
that are 
looking for FVWM MWM WIN just go with the default.  

The only place I see The Gradients getting used are in PaintMenu in menus.c
,  I would think the simple solution is to 
add a second style for graddients to the MenuFace struct.

SetMenuStyle default gray90 #515178 gray40 Black \
   -adobe-helvetica-medium-r-*-*-12-*-*-*-*-*-*-* anim mwm \
   (HGradient 8 #515178 #424278)

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
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: Thu, 17 Dec 1998 01:12:46 +0100

>    (HGradient 8 #515178 #424278)

Ah, now I understand. The (fvwm/mwm/win) menu style is immediately
overridden because as soon as the MenuFace bit is parsed. But this
applies to all MenuFace styles, not just the gradients. This is no
problem where painting is concerned, but kills the special behaviour
of fvwm menus (prepop menus and the place where the submenu is drawn).
I suggest we split up the style bit into a behaviour specific part
(that is still called 'style') and a painting related part
'visual_style'. 'style' can only be fvwm/mwm/win. 'visual_style'
defaults to the value set for 'style' but is overridden when
a MenuFace is used.
 
Bye

Dominik
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Thu, 17 Dec 1998 09:38:59 +0000

> defaults to the value set for 'style' but is overridden when

This sounds like a good idea.  I'm not sure the differences between mwm and win
styles are significant enough to warrant keeping them as a separate style (the
placement of submenus look almost the same).  mwm highlights using 3D, win
hilights using colour - I think these attributes should be in the visual style.
We could just have fvwm and mwm style with a section in the man pages telling how
to make mwm look like win95.  It would mean less things to test.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 17 Dec 1998 11:25:38 +0100

> to make mwm look like win95.  It would mean less things to test.

This is not the only difference. Submenus are placed two pixels
farther to the left with WIN menus than with MWM menus. There
may be other differences too. The manpage is by no means
complete (and I don't think it should be). And the 'next'
style had a different idea of how things should look like too:
It didn't underline menu titles and places submenus four pixels
right of mwm submenus.

Unfortunately having a (menuface) option suppresses item
highlighting (other than text colour). We're a bit inconsistent
here. Another thing is the order of parameters. Brad noticed
that the anim/noanim bit and the style have changed places.
Since I removed the reason for that (menufaces can now be
specified for all styles), we might want to change this back
before 2.2.

Earlier we started a discussion about the SetMenuStyle syntax.
I want to propose the following now that we still have a choice:

  SetMenuStyle stlye-name <option> [, <option>] ...

where <option> can be:
                           Default
  Foreground <colour>      black
  Background <colour>      white
  Shade <colour>           ?

  Hilight <colour>         black
  Animation on|off         off
  Font <font>              ?
  Style fvwm|mwm|win       fvwm
  MenuFace (<menuface>)    none

The options in the second group could be easily set with
sensible defaults while the user has to set the first
three if he wants to get something sensible.

Any comments on 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.hpc.uh.edu/fvwm/>.
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: Thu, 17 Dec 1998 11:01:20 +0000

Dominik Vogt wrote:

> farther to the left with WIN menus than with MWM menus. (Next) didn't underline menu
> titles and places submenus four pixels
> right of mwm submenus.

I don't think a few pixels matter.  If we had a Hilight3D setting that could take care of
some of the win/mwm style differences.

> here.

I agree that it should suppress background colour highlighting, but I'd like it to be able
to draw a 3D relief around the active item.  There is a bit of a bug in the current
TiledPixmap bit: the left and right relief is overwritten with the pixmap.

>   MenuFace (<menuface>)    none

I think Hilight should be HilightFore and there should be HilightBack colour and Hilight3D
on|off.  I really think we should lose the win style.

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 17 Dec 1998 13:11:08 +0100

> on|off.  I really think we should lose the win style.

Good idea.

The like this:
                           default
----------------------------------
  Foreground <colour>        black
  Background <colour>        white
  Shade <colour>             ?
  HilightFore <colour>       none
  HilightBack <colour>       none
  Hilight3D on|off           on
  Animation on|off           off
  Font <font>                ?
  MenuFace (<menuface>)      none
  Look fvwm|mwm[|win]        fvwm
  Feel fvwm|mwm|win          fvwm
  PositionHints <poshints>   none

Hilight... can be (de)activated independently (Fore and Back are
turned off by leaving the colour blank? Or perhaps by specifying
'none' as colour?). The 'Look' bit just sets defaults for the
visual settinga (e.g. Hilight3D off, HilightBack black, Animation
off for WIN). The 'Feel' part controls the differences in handling
(popup offset, prepopping menus and so on). The only reason why
the WIN look is needed is for the popup offset. Probably nobody
will notice if we remove that.

The PosHints might be a logical extension to the position hints
for single menus. In fact I use this with all my menus, just like
a style:

  Popup foobar item +100 c

This gives me submenus always centered on the current menu item
vertically. This saves a lot of space. If you can override this
for individual menus it would be nice to have the general setting.
However this can wait until after 2.2 since it is a non-disruptive
enhancement.

Bye

Dominik