GNU bug report logs - #3301
23.0.93; menu bar bug with gtk-qt engine (KDE)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 3301 in the body.
You can then email your comments to 3301 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Fri, 15 May 2009 23:54:03 +0200

When the Emacs frame is not in focus on the desktop and then I bring it
into focus by clicking with the mouse pointer on the Emacs menu bar, but
to the right of any menu bar entry, this sometimes causes the menu bar
to become "active", as when I click directly on a menu bar entry; e.g. I
can navigate the menu bar with the arrow keys, and the keyboard is
otherwise unresponsive, except for ESC, and either typing this key or
clicking again with the mouse is the only way to "deactivate" the menu
bar and release the rest of the keyboard.  This behavior also happens,
though less frequently, by switching focus to Emacs with the window
manager key combination Alt-Q.  I haven't found a recipe for reproducing
this at will.  I have only gotten this behavior under KDE (both 3.5.10
and 3.4.2) with the gtk-qt engine.  I cannot say when I first saw this
behavior, but I'm pretty sure it wasn't too long ago, certainly well
into the pretest.

In GNU Emacs 23.0.93.2 (i686-pc-linux-gnu, GTK+ Version 2.14.4)
 of 2009-05-15 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10502000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Message #8 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: , 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Mon, 11 Jan 2016 18:17:43 +1100

Hi Stephen,

Sorry it's taken so long to get back to you. Do you still observe this
behaviour with more recent versions of Emacs?


Alexis.

Message #11 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Alexis <flexibeast <at> gmail.com>
Cc: 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Mon, 11 Jan 2016 10:49:02 +0100

On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast <at> gmail.com> wrote:

> Sorry it's taken so long to get back to you. Do you still observe this
> behaviour with more recent versions of Emacs?

Yes, I still see this with current builds of emacs-25 and master (built
with GTK+ 3.14.15) running in KDE 4.14.9 on openSUSE 13.2.  However, in
checking the behavior again now, it seems this is normal in KDE: the
same thing happens when I switch focus to any KDE application by
clicking on a menu bar item.  Once difference between Emacs and other
KDE applications is that with the latter, moving the mouse pointer over
a menu bar item highlights it, even when the application window is not
in focus, whereas moving the mouse pointer over an Emacs menu bar item
does not highlight it (it gets highlighted only when it's clicked, which
brings it into focus here).  Perhaps this is a limitation of the gtk-qt
engine or a theme issue which I didn't notice or didn't obtain at the
time of my OP.  Anyway, as far as the behavior of my OP is concerned, I
now think it is not an Emacs bug.

However, there is a related behavior which appears to be Emacs-specific:
if I click with mouse-1 on an empty part of the Emacs menu bar (i.e., a
part containing no menu bar item), then the mouse pointer changes to
"move" mode for relocating the frame on the desktop by dragging.  As
with the menu bar item behavior, no other mouse or keyboard action is
possible until I hit ESC.  This happens both when switching focus to the
Emacs frame as well as when it is already in focus.  This "move"
functionality of the mouse pointer is bound to the key combination
Alt+mouse1 in my KDE (the default binding), as well as to clicking and
holding down mouse-1 on the application window title bar, but Emacs is
the only application in which clicking on an empty part of the menu bar
also activates it, and I often do that unintentionally when switching
focus, so it's annoying -- all the more so, since the mouse pointer
remains in "move" mode even after releasing the mouse button (whereas
when pressing Alt+mouse1 or clicking on the title bar, "move" mode is
active only while holding down the mouse button).  In fact, I encounter
this much more often than the menu bar item behavior, and while I don't
remember if it also happened at the time of my OP, I think I would have
noticed it then, given how frequent and annoying it is.  Moreover,
although in my OP I said I couldn't reliably reproduce the behavior, it
is 100% reprodicible with my current Emacs and KDE, in both the menu
item and "move" realizations, though again, only the latter is
Emacs-specific and hence relevant to this bug.

Steve Berman

Message #14 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jeff Trull <edaskel <at> att.net>
Cc: 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Sun, 06 Mar 2016 15:26:42 +0100

Jeff,

Since (based on your reply to bug#3195) you appear to use KDE, can you
reproduce this bug -- in particular, the observation (repeated in the
last paragraph below) that clicking with mouse-1 on an empty part of the
Emacs menu bar (i.e., a part containing no menu bar item) makes the
mouse pointer changes to "move" mode for relocating the frame on the
desktop by dragging?  If you can and have any idea how to debug it, I'd
be very interested to hear.

Steve Berman

On Mon, 11 Jan 2016 10:49:02 +0100 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast <at> gmail.com> wrote:
>
>> Sorry it's taken so long to get back to you. Do you still observe this
>> behaviour with more recent versions of Emacs?
>
> Yes, I still see this with current builds of emacs-25 and master (built
> with GTK+ 3.14.15) running in KDE 4.14.9 on openSUSE 13.2.  However, in
> checking the behavior again now, it seems this is normal in KDE: the
> same thing happens when I switch focus to any KDE application by
> clicking on a menu bar item.  Once difference between Emacs and other
> KDE applications is that with the latter, moving the mouse pointer over
> a menu bar item highlights it, even when the application window is not
> in focus, whereas moving the mouse pointer over an Emacs menu bar item
> does not highlight it (it gets highlighted only when it's clicked, which
> brings it into focus here).  Perhaps this is a limitation of the gtk-qt
> engine or a theme issue which I didn't notice or didn't obtain at the
> time of my OP.  Anyway, as far as the behavior of my OP is concerned, I
> now think it is not an Emacs bug.
>
> However, there is a related behavior which appears to be Emacs-specific:
> if I click with mouse-1 on an empty part of the Emacs menu bar (i.e., a
> part containing no menu bar item), then the mouse pointer changes to
> "move" mode for relocating the frame on the desktop by dragging.  As
> with the menu bar item behavior, no other mouse or keyboard action is
> possible until I hit ESC.  This happens both when switching focus to the
> Emacs frame as well as when it is already in focus.  This "move"
> functionality of the mouse pointer is bound to the key combination
> Alt+mouse1 in my KDE (the default binding), as well as to clicking and
> holding down mouse-1 on the application window title bar, but Emacs is
> the only application in which clicking on an empty part of the menu bar
> also activates it, and I often do that unintentionally when switching
> focus, so it's annoying -- all the more so, since the mouse pointer
> remains in "move" mode even after releasing the mouse button (whereas
> when pressing Alt+mouse1 or clicking on the title bar, "move" mode is
> active only while holding down the mouse button).  In fact, I encounter
> this much more often than the menu bar item behavior, and while I don't
> remember if it also happened at the time of my OP, I think I would have
> noticed it then, given how frequent and annoying it is.  Moreover,
> although in my OP I said I couldn't reliably reproduce the behavior, it
> is 100% reprodicible with my current Emacs and KDE, in both the menu
> item and "move" realizations, though again, only the latter is
> Emacs-specific and hence relevant to this bug.
>
> Steve Berman

Message #17 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Jeff Trull <edaskel <at> att.net>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Sun, 6 Mar 2016 06:56:46 -0800

[Message part 1 (text/plain, inline)]

I cannot reproduce that issue under Emacs 24 or 25.  Mouse-1 clicks in
either the menu and toolbar in a part with no menu or icon appear to be
simply ignored.

I used ldd to confirm that the emacs binary uses Gtk3.  I am using KDE 5.15
though, unlike the OP's 4.14.

Best Regards,
Jeff

On Sun, Mar 6, 2016 at 6:26 AM, Stephen Berman <stephen.berman <at> gmx.net>
wrote:

> Jeff,
>
> Since (based on your reply to bug#3195) you appear to use KDE, can you
> reproduce this bug -- in particular, the observation (repeated in the
> last paragraph below) that clicking with mouse-1 on an empty part of the
> Emacs menu bar (i.e., a part containing no menu bar item) makes the
> mouse pointer changes to "move" mode for relocating the frame on the
> desktop by dragging?  If you can and have any idea how to debug it, I'd
> be very interested to hear.
>
> Steve Berman
>
> On Mon, 11 Jan 2016 10:49:02 +0100 Stephen Berman <stephen.berman <at> gmx.net>
> wrote:
>
> > On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast <at> gmail.com> wrote:
> >
> >> Sorry it's taken so long to get back to you. Do you still observe this
> >> behaviour with more recent versions of Emacs?
> >
> > Yes, I still see this with current builds of emacs-25 and master (built
> > with GTK+ 3.14.15) running in KDE 4.14.9 on openSUSE 13.2.  However, in
> > checking the behavior again now, it seems this is normal in KDE: the
> > same thing happens when I switch focus to any KDE application by
> > clicking on a menu bar item.  Once difference between Emacs and other
> > KDE applications is that with the latter, moving the mouse pointer over
> > a menu bar item highlights it, even when the application window is not
> > in focus, whereas moving the mouse pointer over an Emacs menu bar item
> > does not highlight it (it gets highlighted only when it's clicked, which
> > brings it into focus here).  Perhaps this is a limitation of the gtk-qt
> > engine or a theme issue which I didn't notice or didn't obtain at the
> > time of my OP.  Anyway, as far as the behavior of my OP is concerned, I
> > now think it is not an Emacs bug.
> >
> > However, there is a related behavior which appears to be Emacs-specific:
> > if I click with mouse-1 on an empty part of the Emacs menu bar (i.e., a
> > part containing no menu bar item), then the mouse pointer changes to
> > "move" mode for relocating the frame on the desktop by dragging.  As
> > with the menu bar item behavior, no other mouse or keyboard action is
> > possible until I hit ESC.  This happens both when switching focus to the
> > Emacs frame as well as when it is already in focus.  This "move"
> > functionality of the mouse pointer is bound to the key combination
> > Alt+mouse1 in my KDE (the default binding), as well as to clicking and
> > holding down mouse-1 on the application window title bar, but Emacs is
> > the only application in which clicking on an empty part of the menu bar
> > also activates it, and I often do that unintentionally when switching
> > focus, so it's annoying -- all the more so, since the mouse pointer
> > remains in "move" mode even after releasing the mouse button (whereas
> > when pressing Alt+mouse1 or clicking on the title bar, "move" mode is
> > active only while holding down the mouse button).  In fact, I encounter
> > this much more often than the menu bar item behavior, and while I don't
> > remember if it also happened at the time of my OP, I think I would have
> > noticed it then, given how frequent and annoying it is.  Moreover,
> > although in my OP I said I couldn't reliably reproduce the behavior, it
> > is 100% reprodicible with my current Emacs and KDE, in both the menu
> > item and "move" realizations, though again, only the latter is
> > Emacs-specific and hence relevant to this bug.
> >
> > Steve Berman
>

[Message part 2 (text/html, inline)]

Message #20 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jeff Trull <edaskel <at> att.net>
Cc: 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Sun, 06 Mar 2016 16:50:34 +0100

On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel <at> att.net> wrote:

> I cannot reproduce that issue under Emacs 24 or 25. Mouse-1 clicks in
> either the menu and toolbar in a part with no menu or icon appear to
> be simply ignored.
>
> I used ldd to confirm that the emacs binary uses Gtk3. I am using KDE
> 5.15 though, unlike the OP's 4.14.

Thanks, that's useful information, perhaps the bug doesn't occur in KDE
5.*.  I currently don't have access to that version, but will test it as
soon as I do.

Steve Berman

Message #23 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Jeff Trull <edaskel <at> att.net>, 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Thu, 27 Jun 2019 03:41:10 +0200

Stephen Berman <stephen.berman <at> gmx.net> writes:

> On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel <at> att.net> wrote:
>
>> I cannot reproduce that issue under Emacs 24 or 25. Mouse-1 clicks in
>> either the menu and toolbar in a part with no menu or icon appear to
>> be simply ignored.
>>
>> I used ldd to confirm that the emacs binary uses Gtk3. I am using KDE
>> 5.15 though, unlike the OP's 4.14.
>
> Thanks, that's useful information, perhaps the bug doesn't occur in KDE
> 5.*.  I currently don't have access to that version, but will test it as
> soon as I do.

Hi Stephen,

Did you ever get around to testing if this bug is still reproducible
using KDE 5.*?

Best regards,
Stefan Kangas

Message #26 received at 3301 <at> debbugs.gnu.org (full text, mbox):

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 3301 <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Thu, 27 Jun 2019 10:48:23 +0200

On Thu, 27 Jun 2019 03:41:10 +0200 Stefan Kangas <stefan <at> marxist.se> wrote:

> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel <at> att.net> wrote:
>>
>>> I cannot reproduce that issue under Emacs 24 or 25. Mouse-1 clicks in
>>> either the menu and toolbar in a part with no menu or icon appear to
>>> be simply ignored.
>>>
>>> I used ldd to confirm that the emacs binary uses Gtk3. I am using KDE
>>> 5.15 though, unlike the OP's 4.14.
>>
>> Thanks, that's useful information, perhaps the bug doesn't occur in KDE
>> 5.*.  I currently don't have access to that version, but will test it as
>> soon as I do.
>
> Hi Stephen,
>
> Did you ever get around to testing if this bug is still reproducible
> using KDE 5.*?

Thanks for reminding me about this.  I stopped regularly using the menu
bar in Emacs a while ago and also had not been using KDE for some time,
but recently started using it again (KDE Frameworks 5.59.0 in openSUSE),
and checking now (in current master) with the Emacs menu bar enabled, I
cannot reproduce the problem that clicking mouse-1 activates "move" mode
(and it remains active after releasing mouse-1), only holding down
mouse-1 does that.  So it seems this was only an issue with KDE 4*.  The
other issue mentioned in my followup to my OP, that in KDE applications
moving the mouse pointer over a menu bar item highlights it, even when
the application window is not in focus, whereas moving the mouse pointer
over an Emacs menu bar item does not highlight it, I still see but it's
a minor cosmestic blemish, so as far as I'm concerned this bug can be
closed.

Steve Berman

Message #31 received at 3301-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 3301-done <at> debbugs.gnu.org
Subject: Re: bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
Date: Fri, 5 Jul 2019 20:01:47 +0200

Stephen Berman <stephen.berman <at> gmx.net> writes:

> Thanks for reminding me about this.  I stopped regularly using the menu
> bar in Emacs a while ago and also had not been using KDE for some time,
> but recently started using it again (KDE Frameworks 5.59.0 in openSUSE),
> and checking now (in current master) with the Emacs menu bar enabled, I
> cannot reproduce the problem that clicking mouse-1 activates "move" mode
> (and it remains active after releasing mouse-1), only holding down
> mouse-1 does that.  So it seems this was only an issue with KDE 4*.  The
> other issue mentioned in my followup to my OP, that in KDE applications
> moving the mouse pointer over a menu bar item highlights it, even when
> the application window is not in focus, whereas moving the mouse pointer
> over an Emacs menu bar item does not highlight it, I still see but it's
> a minor cosmestic blemish, so as far as I'm concerned this bug can be
> closed.

Thank you for your reply.  Based on that, I'm closing this bug.

Thanks,
Stefan Kangas

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.