bug#3301: 23.0.93; menu bar bug with gtk-qt engine (KDE)

[Jeff Trull]

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