* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
@ 2009-05-15 21:54 Stephen Berman
2016-01-11 7:17 ` Alexis
` (2 more replies)
0 siblings, 3 replies; 9+ messages in thread
From: Stephen Berman @ 2009-05-15 21:54 UTC (permalink / raw)
To: emacs-pretest-bug
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2009-05-15 21:54 bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE) Stephen Berman
@ 2016-01-11 7:17 ` Alexis
2016-01-11 9:49 ` Stephen Berman
2019-06-27 1:41 ` Stefan Kangas
2019-07-05 18:01 ` Stefan Kangas
2 siblings, 1 reply; 9+ messages in thread
From: Alexis @ 2016-01-11 7:17 UTC (permalink / raw)
To: Stephen Berman; +Cc: 3301
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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2016-01-11 7:17 ` Alexis
@ 2016-01-11 9:49 ` Stephen Berman
2016-03-06 14:26 ` Stephen Berman
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Berman @ 2016-01-11 9:49 UTC (permalink / raw)
To: Alexis; +Cc: 3301
On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2016-01-11 9:49 ` Stephen Berman
@ 2016-03-06 14:26 ` Stephen Berman
2016-03-06 14:56 ` Jeff Trull
0 siblings, 1 reply; 9+ messages in thread
From: Stephen Berman @ 2016-03-06 14:26 UTC (permalink / raw)
To: Jeff Trull; +Cc: 3301
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@gmx.net> wrote:
> On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2016-03-06 14:26 ` Stephen Berman
@ 2016-03-06 14:56 ` Jeff Trull
2016-03-06 15:50 ` Stephen Berman
0 siblings, 1 reply; 9+ messages in thread
From: Jeff Trull @ 2016-03-06 14:56 UTC (permalink / raw)
To: Stephen Berman; +Cc: 3301
[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]
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@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@gmx.net>
> wrote:
>
> > On Mon, 11 Jan 2016 18:17:43 +1100 Alexis <flexibeast@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
>
[-- Attachment #2: Type: text/html, Size: 4671 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2016-03-06 14:56 ` Jeff Trull
@ 2016-03-06 15:50 ` Stephen Berman
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Berman @ 2016-03-06 15:50 UTC (permalink / raw)
To: Jeff Trull; +Cc: 3301
On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2009-05-15 21:54 bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE) Stephen Berman
2016-01-11 7:17 ` Alexis
@ 2019-06-27 1:41 ` Stefan Kangas
2019-06-27 8:48 ` Stephen Berman
2019-07-05 18:01 ` Stefan Kangas
2 siblings, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2019-06-27 1:41 UTC (permalink / raw)
To: Stephen Berman; +Cc: Jeff Trull, 3301
Stephen Berman <stephen.berman@gmx.net> writes:
> On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2019-06-27 1:41 ` Stefan Kangas
@ 2019-06-27 8:48 ` Stephen Berman
0 siblings, 0 replies; 9+ messages in thread
From: Stephen Berman @ 2019-06-27 8:48 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 3301
On Thu, 27 Jun 2019 03:41:10 +0200 Stefan Kangas <stefan@marxist.se> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> On Sun, 6 Mar 2016 06:56:46 -0800 Jeff Trull <edaskel@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
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)
2009-05-15 21:54 bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE) Stephen Berman
2016-01-11 7:17 ` Alexis
2019-06-27 1:41 ` Stefan Kangas
@ 2019-07-05 18:01 ` Stefan Kangas
2 siblings, 0 replies; 9+ messages in thread
From: Stefan Kangas @ 2019-07-05 18:01 UTC (permalink / raw)
To: Stephen Berman; +Cc: 3301-done
Stephen Berman <stephen.berman@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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-07-05 18:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-15 21:54 bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE) Stephen Berman
2016-01-11 7:17 ` Alexis
2016-01-11 9:49 ` Stephen Berman
2016-03-06 14:26 ` Stephen Berman
2016-03-06 14:56 ` Jeff Trull
2016-03-06 15:50 ` Stephen Berman
2019-06-27 1:41 ` Stefan Kangas
2019-06-27 8:48 ` Stephen Berman
2019-07-05 18:01 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).