Re: GTK build: some menus in the menu bar stay highlighted

[Stephen Berman]

On Sun, 22 Apr 2007 20:36:31 +0200 Jan Djärv <address@hidden> wrote:

> Stephen Berman skrev:
>> On Sun, 22 Apr 2007 12:58:46 +0200 "Franz Häuslschmid" <address@hidden> 
>> wrote:
>> 
>>> Using the GTK build, it always happens that menus entries of the menu
>>> bar, that are dynamically added or removed depending on the currently
>>> active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse
>>> cursor moves over them.  As I am writing this text and having moved the
>>> mouse cursor over all items of the menu bar, the menus "Edit", "Headers"
>>> and "Mail" are highlighted.  This accentuation of menus is lost, when I
>>> switch to another buffer not having those menus associated.
>> 
>> I have noticed the same thing with my Emacs (currently GNU Emacs
>> 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-20 but
>> I've noticed this for a long time), but only when running under KDE
>> using the GTK Style QtCurve.  This is on openSUSE 10.2 using kcm_gtk,
>> "the KDE control module for switching GTK+ style", which I think is
>> the openSUSE substitute for (or version of) the gtk-qt engine.  I
>> attach a picture showing the problem.
>
> It looks bad indeed.  However, this is all done in Gtk+, I don't even have a
> theme that highlights the menu bar like that.  Does only QtCurve do that?  Or
> are there other Gtk+-themes that highlights like that but doesn't have the
> same problem?

I tried all the GTK Styles available by default in openSUSE 10.2 KDE
(Personal Settings -> Appearance & Themes -> GTK Styles and Fonts),
and in addition to QtCurve the following also highlight the menu names
when the mouse moves over them: Glider, HighContrast,
HighContrastInverse, HighContrastLargePrint,
HighContrastLargePrintInverse, Redmond.  However, I observe the
"sticky" highlighting problem only with QtCurve.

> The GNUS menus are defined with easy-menu, thats about all I can think of that
> differs from "regular" menus.  Can you define a small menu with easy.menu and
> see if the problem is there then?

I made the file srb.el (attached) and did the following (again, only
with QtCurve in KDE):

1. emacs -Q -l srb.el

2. Moving the mouse over the menu bar in *scratch* does not induce the
"sticky" highlighting problem.

3. C-x C-f test.srb brings up a buffer in SRB mode with a menu SRB in
the menu bar.  When I move the mouse over the menu bar in this buffer,
as soon as it moves over and off of SRB the highlighting sticks to
this menu bar item.  If I switch to *scratch* and then back to
test.srb, the sticky highlighting is gone, but I get it again by
moving the mouse over and off of SRB.  I can repeat this ad infinitum.

I can also reliably get the sticky highlighting with the following
recipe:

1. emacs -Q

2. Moving the mouse over the menu bar in *scratch* does not induce the
"sticky" highlighting problem.

3. Do `M-x gnus RET y RET y RET n' to get the Gnus *Group* buffer.
When I move the mouse over the menu bar, the four menues Gnus, Groups,
Group, Agent get "sticky" highlighting.

4. If I now switch back to *scratch* and move the mouse over the menu
bar, the Edit menu gets sticky highlighting.

Steve Berman

(defvar srb-mode-map
  (let ((map (make-keymap)))
    map)
  "SRB mode keymap.")

(easy-menu-define srb-menu srb-mode-map "SRB Menu"
  '("SRB"))

(defun srb-mode ()
  (interactive)
  (kill-all-local-variables)
  (setq major-mode 'srb-mode)
  (setq mode-name "SRB")
  (use-local-map srb-mode-map)
  (easy-menu-add srb-menu))

(add-to-list 'auto-mode-alist '("\\.srb\\'" . srb-mode))

(provide 'srb)