bug#6608: Menu bar not working

bug#6608: Menu bar not working

[Angelo Graziosi]

With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu 10.04, 
when I click (mouse-1) on an item of menu bar, 'Options' for example, it 
opens only for a fraction of a second then is immediately closed. In 
this way it is difficult to work wit menu bar items: one should hold 
mouse-1 pressed and move the mouse, and this is very uncomfortable.

Ciao,
Angelo.

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
> With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu 10.04,
> when I click (mouse-1) on an item of menu bar, 'Options' for example, it
> opens only for a fraction of a second then is immediately closed. In
> this way it is difficult to work wit menu bar items: one should hold
> mouse-1 pressed and move the mouse, and this is very uncomfortable.

I would ask if this is related to BUG #6603...

>
> Ciao,
> Angelo.

bug#6608: Menu bar not working

[Eli Zaretskii]

> Date: Sun, 11 Jul 2010 10:56:16 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: 
> 
> Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
> > With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu 10.04,
> > when I click (mouse-1) on an item of menu bar, 'Options' for example, it
> > opens only for a fraction of a second then is immediately closed. In
> > this way it is difficult to work wit menu bar items: one should hold
> > mouse-1 pressed and move the mouse, and this is very uncomfortable.
> 
> I would ask if this is related to BUG #6603...

I can't imagine how it could be.  6603 is about "C-h f", not about
popping the menus.  And it is specific to the native w32 build.

In any case, 6603 is solved in the repository, so trying the latest
trunk should tell.

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 11/07/2010 11.26, Eli Zaretskii ha scritto:
>> Date: Sun, 11 Jul 2010 10:56:16 +0200
>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>> Cc:
>>
>> Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
>>> With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu 10.04,
>>> when I click (mouse-1) on an item of menu bar, 'Options' for example, it
>>> opens only for a fraction of a second then is immediately closed. In
>>> this way it is difficult to work wit menu bar items: one should hold
>>> mouse-1 pressed and move the mouse, and this is very uncomfortable.
>>
>> I would ask if this is related to BUG #6603...
>
> I can't imagine how it could be.  6603 is about "C-h f", not about
> popping the menus.  And it is specific to the native w32 build.
>
> In any case, 6603 is solved in the repository, so trying the latest
> trunk should tell.

Same problem with rev. 100776. I thought *that* because clicking on an 
item of menu bar ('Options', for example), *pop-ups* the menu only for a 
fraction of a second, and because it is very recent. It does not happen 
with the build I did 20100708: there, clicking, opens (pop-ups) 
'Options', for example, and it remains opened up to one chooses 
something ('Case-insensitive search', for example), or clicks in some 
other place.

Ciao,
Angelo.

bug#6608: Menu bar not working

[Jan Djärv]

I can for the life of me not reproduce this, neither on trunk, 100771 or 
100776.  Please give some more info, like compiler version, architecture (32 
or 64-bit?), Gtk+ version?  Optimise flags to the compiler?  I assume you can 
repeat this with emacs -Q?  I don't have Kubuntu 10.04, but regular Ubuntu 10.04.

Now, the Motif menus have problems though, different for Lesstif and 
Openmotif.  Openmotif ones behave like you describe, Lesstif doesn't but they 
don't close right.  I don't know if this is related.

	Jan D.


Angelo Graziosi skrev 2010-07-11 11.42:
> Il 11/07/2010 11.26, Eli Zaretskii ha scritto:
>>> Date: Sun, 11 Jul 2010 10:56:16 +0200
>>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>>> Cc:
>>>
>>> Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
>>>> With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu 10.04,
>>>> when I click (mouse-1) on an item of menu bar, 'Options' for example, it
>>>> opens only for a fraction of a second then is immediately closed. In
>>>> this way it is difficult to work wit menu bar items: one should hold
>>>> mouse-1 pressed and move the mouse, and this is very uncomfortable.
>>>
>>> I would ask if this is related to BUG #6603...
>>
>> I can't imagine how it could be. 6603 is about "C-h f", not about
>> popping the menus. And it is specific to the native w32 build.
>>
>> In any case, 6603 is solved in the repository, so trying the latest
>> trunk should tell.
>
> Same problem with rev. 100776. I thought *that* because clicking on an item of
> menu bar ('Options', for example), *pop-ups* the menu only for a fraction of a
> second, and because it is very recent. It does not happen with the build I did
> 20100708: there, clicking, opens (pop-ups) 'Options', for example, and it
> remains opened up to one chooses something ('Case-insensitive search', for
> example), or clicks in some other place.
>
> Ciao,
> Angelo.
>
>

bug#6608: Menu bar not working

[Chong Yidong]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I can for the life of me not reproduce this, neither on trunk, 100771
> or 100776.  Please give some more info, like compiler version,
> architecture (32 or 64-bit?), Gtk+ version?  Optimise flags to the
> compiler?  I assume you can repeat this with emacs -Q?  I don't have
> Kubuntu 10.04, but regular Ubuntu 10.04.

I see the problem on the emacs-23 branch as well as the trunk.

  In GNU Emacs 24.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
    of 2010-07-11 on furry
  Windowing system distributor `The X.Org Foundation', version 11.0.10706000
  configured using `configure  'CC=gcc' 'CFLAGS=-g''

It does not happen on every click, but a majority of them.
Reverting the following change seems to remove the problem:

2010-07-03  Jan Djärv  <jan.h.d@swipnet.se>

  * xmenu.c (x_activate_menubar): Send Press/Release for Gtk+ to avoid
  grab on just Press (Bug#6499).

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 11/07/2010 20.40, Jan Djärv ha scritto:
> I can for the life of me not reproduce this, neither on trunk, 100771 or

Strange... Have you done a clean checkout and a clean bootstrap?

For me it happens also with rev.100787 on

GNU/Linux Kubuntu 8.04:
------------------------------------------------------------
GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of 
2010-07-12 on ubuntu

$ uname -a
Linux ubuntu 2.6.24-28-generic #1 SMP Fri Jun 18 12:02:15 UTC 2010 i686 
GNU/Linux

$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr 
--enable-shared --with-system-zlib --libexecdir=/usr/lib 
--without-included-gettext --enable-threads=posix --enable-nls 
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc 
--enable-mpfr --enable-targets=all --enable-checking=release 
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

What compiler should emacs be built with?               gcc -g -O2 
-Wold-style-definition -Wdeclaration-after-statement -Wno-pointer-sign
---------------------------------------------------------------------

GNU/Linux Kubuntu 10.04
---------------------------------------------------------------------
GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
  of 2010-07-11

$ uname -a
Linux ubuntu 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC 
2010 x86_64 GNU/Linux

$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 
4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs 
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr 
--enable-shared --enable-multiarch --enable-linker-build-id 
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 
--program-suffix=-4.4 --enable-nls --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-plugin --enable-objc-gc 
--disable-werror --with-arch-32=i486 --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu 
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)


What compiler should emacs be built with?               gcc -g -O2 
-Wold-style-definition -Wdeclaration-after-statement -Wno-pointer-sign
---------------------------------------------------------------------

$ emacs -Q &

Now, to open an item (File, Edit, Options etc.) on menu bar, one MUST 
click on it (with mouse-1) and HOLD mouse-1 pressed, otherwise the menu 
does not remains opened, but it is closed in a fraction of a second.

Perhaps, one of these changes is the cause:

----------------------------
2010-07-09  Jan Djärv  <jan.h.d@swipnet.se>

	* xmenu.c (set_frame_menubar): Must realize menubar_widget to get the
	correct size for Motif.
	(free_frame_menubar): Call x_set_window_size to update frame size.

	* xfns.c (x_window): Set borderWidth to 0 for pane and
	EmacsFrame.  Frame size calculation is wrong otherwise.
----------------------------
2010-07-08  Jan Djärv  <jan.h.d@swipnet.se>

	* xmenu.c (set_frame_menubar, create_and_show_popup_menu)
	(create_and_show_dialog): Don't call apply_systemfont_to_(menu|dialog)
	unless USE_LUCID.
----------------------------
[...]
----------------------------

Ciao,
Angelo.

> 100776. Please give some more info, like compiler version, architecture
> (32 or 64-bit?), Gtk+ version? Optimise flags to the compiler? I assume
> you can repeat this with emacs -Q? I don't have Kubuntu 10.04, but
> regular Ubuntu 10.04.
>
> Now, the Motif menus have problems though, different for Lesstif and
> Openmotif. Openmotif ones behave like you describe, Lesstif doesn't but
> they don't close right. I don't know if this is related.
>
> Jan D.
>
>
> Angelo Graziosi skrev 2010-07-11 11.42:
>> Il 11/07/2010 11.26, Eli Zaretskii ha scritto:
>>>> Date: Sun, 11 Jul 2010 10:56:16 +0200
>>>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>>>> Cc:
>>>>
>>>> Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
>>>>> With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu
>>>>> 10.04,
>>>>> when I click (mouse-1) on an item of menu bar, 'Options' for
>>>>> example, it
>>>>> opens only for a fraction of a second then is immediately closed. In
>>>>> this way it is difficult to work wit menu bar items: one should hold
>>>>> mouse-1 pressed and move the mouse, and this is very uncomfortable.
>>>>
>>>> I would ask if this is related to BUG #6603...
>>>
>>> I can't imagine how it could be. 6603 is about "C-h f", not about
>>> popping the menus. And it is specific to the native w32 build.
>>>
>>> In any case, 6603 is solved in the repository, so trying the latest
>>> trunk should tell.
>>
>> Same problem with rev. 100776. I thought *that* because clicking on an
>> item of
>> menu bar ('Options', for example), *pop-ups* the menu only for a
>> fraction of a
>> second, and because it is very recent. It does not happen with the
>> build I did
>> 20100708: there, clicking, opens (pop-ups) 'Options', for example, and it
>> remains opened up to one chooses something ('Case-insensitive search',
>> for
>> example), or clicks in some other place.
>>
>> Ciao,
>> Angelo.
>>
>>

bug#6608: Menu bar not working

[Angelo Graziosi]

For completeness, same problem on Cygwin:

------------------------------------------------------------
GNU Emacs 24.0.50.1 (i686-pc-cygwin, GTK+ Version 2.20.1)
  of 2010-07-12

$ uname -a
CYGWIN_NT-5.1 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: 
/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4/configure 
--srcdir=/gnu/gcc/releases/packaging/4.3.4-3/gcc4-4.3.4-3/src/gcc-4.3.4 
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin 
--libexecdir=/usr/lib --datadir=/usr/share --localstatedir=/var 
--sysconfdir=/etc --infodir=/usr/share/info --mandir=/usr/share/man 
--datadir=/usr/share --infodir=/usr/share/info --mandir=/usr/share/man 
-v --with-gmp=/usr --with-mpfr=/usr --enable-bootstrap 
--enable-version-specific-runtime-libs --with-slibdir=/usr/bin 
--libexecdir=/usr/lib --enable-static --enable-shared 
--enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld 
--with-gnu-as --with-dwarf2 --disable-sjlj-exceptions 
--enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --disable-symvers 
--enable-libjava --program-suffix=-4 --enable-libgomp --enable-libssp 
--enable-libada --enable-threads=posix --with-arch=i686 
--with-tune=generic --enable-libgcj-sublibs CC=gcc-4 CXX=g++-4 
CC_FOR_TARGET=gcc-4 CXX_FOR_TARGET=g++-4 GNATMAKE_FOR_TARGET=gnatmake 
GNATBIND_FOR_TARGET=gnatbind AS=/opt/gcc-tools/bin/as.exe 
AS_FOR_TARGET=/opt/gcc-tools/bin/as.exe LD=/opt/gcc-tools/bin/ld.exe 
LD_FOR_TARGET=/opt/gcc-tools/bin/ld.exe 
--with-ecj-jar=/usr/share/java/ecj.jar
Thread model: posix
gcc version 4.3.4 20090804 (release) 1 (GCC)

What compiler should emacs be built with?               gcc -g -O2 
-Wold-style-definition -Wdeclaration-after-statement -Wno-pointer-sign

------------------------------------------------------------

Ciao,
Angelo.


Il 12/07/2010 1.13, Angelo Graziosi ha scritto:
> Il 11/07/2010 20.40, Jan Djärv ha scritto:
>> I can for the life of me not reproduce this, neither on trunk, 100771 or
>
> Strange... Have you done a clean checkout and a clean bootstrap?
>
> For me it happens also with rev.100787 on
>
> GNU/Linux Kubuntu 8.04:
> ------------------------------------------------------------
> GNU Emacs 24.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of
> 2010-07-12 on ubuntu
>
> $ uname -a
> Linux ubuntu 2.6.24-28-generic #1 SMP Fri Jun 18 12:02:15 UTC 2010 i686
> GNU/Linux
>
> $ gcc -v
> Using built-in specs.
> Target: i486-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
> --enable-mpfr --enable-targets=all --enable-checking=release
> --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
> Thread model: posix
> gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
>
> What compiler should emacs be built with? gcc -g -O2
> -Wold-style-definition -Wdeclaration-after-statement -Wno-pointer-sign
> ---------------------------------------------------------------------
>
> GNU/Linux Kubuntu 10.04
> ---------------------------------------------------------------------
> GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
> of 2010-07-11
>
> $ uname -a
> Linux ubuntu 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28 UTC
> 2010 x86_64 GNU/Linux
>
> $ gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu
> 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --enable-shared --enable-multiarch --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
> --program-suffix=-4.4 --enable-nls --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-plugin --enable-objc-gc
> --disable-werror --with-arch-32=i486 --with-tune=generic
> --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5)
>
>
> What compiler should emacs be built with? gcc -g -O2
> -Wold-style-definition -Wdeclaration-after-statement -Wno-pointer-sign
> ---------------------------------------------------------------------
>
> $ emacs -Q &
>
> Now, to open an item (File, Edit, Options etc.) on menu bar, one MUST
> click on it (with mouse-1) and HOLD mouse-1 pressed, otherwise the menu
> does not remains opened, but it is closed in a fraction of a second.
>
> Perhaps, one of these changes is the cause:
>
> ----------------------------
> 2010-07-09 Jan Djärv <jan.h.d@swipnet.se>
>
> * xmenu.c (set_frame_menubar): Must realize menubar_widget to get the
> correct size for Motif.
> (free_frame_menubar): Call x_set_window_size to update frame size.
>
> * xfns.c (x_window): Set borderWidth to 0 for pane and
> EmacsFrame. Frame size calculation is wrong otherwise.
> ----------------------------
> 2010-07-08 Jan Djärv <jan.h.d@swipnet.se>
>
> * xmenu.c (set_frame_menubar, create_and_show_popup_menu)
> (create_and_show_dialog): Don't call apply_systemfont_to_(menu|dialog)
> unless USE_LUCID.
> ----------------------------
> [...]
> ----------------------------
>
> Ciao,
> Angelo.
>
>> 100776. Please give some more info, like compiler version, architecture
>> (32 or 64-bit?), Gtk+ version? Optimise flags to the compiler? I assume
>> you can repeat this with emacs -Q? I don't have Kubuntu 10.04, but
>> regular Ubuntu 10.04.
>>
>> Now, the Motif menus have problems though, different for Lesstif and
>> Openmotif. Openmotif ones behave like you describe, Lesstif doesn't but
>> they don't close right. I don't know if this is related.
>>
>> Jan D.
>>
>>
>> Angelo Graziosi skrev 2010-07-11 11.42:
>>> Il 11/07/2010 11.26, Eli Zaretskii ha scritto:
>>>>> Date: Sun, 11 Jul 2010 10:56:16 +0200
>>>>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>>>>> Cc:
>>>>>
>>>>> Il 11/07/2010 10.53, Angelo Graziosi ha scritto:
>>>>>> With Emacs 24 trunk rev. 100771, GTK build, on GNU/Linux Kubuntu
>>>>>> 10.04,
>>>>>> when I click (mouse-1) on an item of menu bar, 'Options' for
>>>>>> example, it
>>>>>> opens only for a fraction of a second then is immediately closed. In
>>>>>> this way it is difficult to work wit menu bar items: one should hold
>>>>>> mouse-1 pressed and move the mouse, and this is very uncomfortable.
>>>>>
>>>>> I would ask if this is related to BUG #6603...
>>>>
>>>> I can't imagine how it could be. 6603 is about "C-h f", not about
>>>> popping the menus. And it is specific to the native w32 build.
>>>>
>>>> In any case, 6603 is solved in the repository, so trying the latest
>>>> trunk should tell.
>>>
>>> Same problem with rev. 100776. I thought *that* because clicking on an
>>> item of
>>> menu bar ('Options', for example), *pop-ups* the menu only for a
>>> fraction of a
>>> second, and because it is very recent. It does not happen with the
>>> build I did
>>> 20100708: there, clicking, opens (pop-ups) 'Options', for example,
>>> and it
>>> remains opened up to one chooses something ('Case-insensitive search',
>>> for
>>> example), or clicks in some other place.
>>>
>>> Ciao,
>>> Angelo.
>>>
>>>
>

bug#6608: Menu bar not working

[Jan Djärv]

Chong Yidong skrev 2010-07-12 00.23:
> Jan Djärv<jan.h.d@swipnet.se>  writes:
>
>> I can for the life of me not reproduce this, neither on trunk, 100771
>> or 100776.  Please give some more info, like compiler version,
>> architecture (32 or 64-bit?), Gtk+ version?  Optimise flags to the
>> compiler?  I assume you can repeat this with emacs -Q?  I don't have
>> Kubuntu 10.04, but regular Ubuntu 10.04.
>
> I see the problem on the emacs-23 branch as well as the trunk.
>
>    In GNU Emacs 24.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
>      of 2010-07-11 on furry
>    Windowing system distributor `The X.Org Foundation', version 11.0.10706000
>    configured using `configure  'CC=gcc' 'CFLAGS=-g''
>
> It does not happen on every click, but a majority of them.
> Reverting the following change seems to remove the problem:
>
> 2010-07-03  Jan Djärv<jan.h.d@swipnet.se>
>
>    * xmenu.c (x_activate_menubar): Send Press/Release for Gtk+ to avoid
>    grab on just Press (Bug#6499).

I'll revert that then, but it can't be that change that is responsible for the 
same beahviour in Motif menu bars.

	Jan D.

bug#6608: Menu bar not working

[Jan Djärv]

Thanks for the details.

Angelo Graziosi skrev 2010-07-12 01.13:

>
> $ emacs -Q &
>
> Now, to open an item (File, Edit, Options etc.) on menu bar, one MUST click on
> it (with mouse-1) and HOLD mouse-1 pressed, otherwise the menu does not
> remains opened, but it is closed in a fraction of a second.
>
> Perhaps, one of these changes is the cause:
>
> ----------------------------
> 2010-07-09 Jan Djärv <jan.h.d@swipnet.se>
>
> * xmenu.c (set_frame_menubar): Must realize menubar_widget to get the
> correct size for Motif.
> (free_frame_menubar): Call x_set_window_size to update frame size.
>
> * xfns.c (x_window): Set borderWidth to 0 for pane and
> EmacsFrame. Frame size calculation is wrong otherwise.
> ----------------------------
> 2010-07-08 Jan Djärv <jan.h.d@swipnet.se>
>
> * xmenu.c (set_frame_menubar, create_and_show_popup_menu)
> (create_and_show_dialog): Don't call apply_systemfont_to_(menu|dialog)
> unless USE_LUCID.


No, that cant be it.  These are all #ifdef USE_LUCID or USE_MOTIF changes.

	Jan D.

bug#6608: Menu bar not working

[Eli Zaretskii]

> Date: Mon, 12 Jul 2010 09:06:49 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> Cc: 6608@debbugs.gnu.org, Angelo Graziosi <angelo.graziosi@alice.it>
> 
> > 2010-07-03  Jan Djärv<jan.h.d@swipnet.se>
> >
> >    * xmenu.c (x_activate_menubar): Send Press/Release for Gtk+ to avoid
> >    grab on just Press (Bug#6499).
> 
> I'll revert that then, but it can't be that change that is responsible for the 
> same beahviour in Motif menu bars.

AFAIR, Emacs built with Motif always behaved like that.  Caveat: last
time I tried a Motif Emacs was several years ago.

bug#6608: Menu bar not working [found breaking revision!]

[Angelo Graziosi]

Il 12/07/2010 12.33, Angelo Graziosi ha scritto:
> Il 12/07/2010 9.06, Jan Djärv ha scritto:
>>
>>
>> Chong Yidong skrev 2010-07-12 00.23:
>>> Jan Djärv<jan.h.d@swipnet.se> writes:
>>>
>>>> I can for the life of me not reproduce this, neither on trunk, 100771
>>>> or 100776. Please give some more info, like compiler version,
>>>> architecture (32 or 64-bit?), Gtk+ version? Optimise flags to the
>>>> compiler? I assume you can repeat this with emacs -Q? I don't have
>>>> Kubuntu 10.04, but regular Ubuntu 10.04.
>>>
>>> I see the problem on the emacs-23 branch as well as the trunk.
>>>
>>> In GNU Emacs 24.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
>>> of 2010-07-11 on furry
>>> Windowing system distributor `The X.Org Foundation', version
>>> 11.0.10706000
>>> configured using `configure 'CC=gcc' 'CFLAGS=-g''
>>>
>>> It does not happen on every click, but a majority of them.
>>> Reverting the following change seems to remove the problem:
>>>
>>> 2010-07-03 Jan Djärv<jan.h.d@swipnet.se>
>>>
>>> * xmenu.c (x_activate_menubar): Send Press/Release for Gtk+ to avoid
>>> grab on just Press (Bug#6499).
>>
>> I'll revert that then, but it can't be that change that is responsible
>> for the same beahviour in Motif menu bars.
>
> NOT, NOT yet! Please read!
>
> With a binary search I have found the breaking revision. It is rev.100770.
>
> Indeed r100769 works as expected, r100700 NOT. Reverting the change to
> xmenu.c, i.e. applying this patch
>
> ===========================
> --- emacs-r100770/src/xmenu.c 2010-07-12 10:45:19.000000000 +0200
> +++ emacs-r100769/src/xmenu.c 2010-07-12 10:20:51.000000000 +0200
> @@ -676,14 +676,6 @@
> set_frame_menubar (f, 0, 1);
> BLOCK_INPUT;
> #ifdef USE_GTK
> - /* If we click outside any menu item, the menu bar still grabs.
> - So we send Press and the Release. If outside, grab is released.
> - If on a menu item, it is popped up normally.
> - PutBack is like a stack, so we put back in reverse order. */
> - f->output_data.x->saved_menu_event->type = ButtonRelease;
> - XPutBackEvent (f->output_data.x->display_info->display,
> - f->output_data.x->saved_menu_event);
> - f->output_data.x->saved_menu_event->type = ButtonPress;
> XPutBackEvent (f->output_data.x->display_info->display,
> f->output_data.x->saved_menu_event);
> popup_activated_flag = 1;
> ===========================
>
> fix the problem for me!
>
> As you can see, it regards GTK build (ifdef USE_GTK). Perhaps I
> understand the motivations for the changes in xmenu.c, but they break
> something. It is definitely a bug (better: a regression) for me. Since
> Emacs 22.0.50, I never seen the problem I described nor in all my GTK
> builds.
>
> Ciao,
> Angelo.

bug#6608: Menu bar not working

[Jan Djärv]

I just tried an older version om the emacs-23 branch.  It sometimes don't open 
the menu, but sometimes it does (50/50).  I must try on an even older version. 
  Anyway, if it did behave that way before, I'd say that was a bug.

Not that people seem to be using Motif much anymore, the build for Motif on 
the trunk was broken for several months until I tried to build it last week.

	Jan D.


Eli Zaretskii skrev 2010-07-12 09.58:
>
> AFAIR, Emacs built with Motif always behaved like that.  Caveat: last
> time I tried a Motif Emacs was several years ago.

bug#6608: Menu bar not working [found breaking revision!]

[Jan Djärv]

You are talking about the same change :-).  But a fix for both this bug and 
6499 is needed. I'm on it but it may take a few days.

	Jan D.


Angelo Graziosi skrev 2010-07-12 12.33:
> Il 12/07/2010 9.06, Jan Djärv ha scritto:
>>
>>
>> Chong Yidong skrev 2010-07-12 00.23:

>>> It does not happen on every click, but a majority of them.
>>> Reverting the following change seems to remove the problem:
>>>
>>> 2010-07-03 Jan Djärv<jan.h.d@swipnet.se>
>>>
>>> * xmenu.c (x_activate_menubar): Send Press/Release for Gtk+ to avoid
>>> grab on just Press (Bug#6499).
>>
>> I'll revert that then, but it can't be that change that is responsible
>> for the same beahviour in Motif menu bars.
>
> NOT, NOT yet! Please read!
>
> With a binary search I have found the breaking revision. It is rev.100770.
>
> Indeed r100769 works as expected, r100700 NOT. Reverting the change to
> xmenu.c, i.e. applying this patch
>
> ===========================
> --- emacs-r100770/src/xmenu.c 2010-07-12 10:45:19.000000000 +0200
> +++ emacs-r100769/src/xmenu.c 2010-07-12 10:20:51.000000000 +0200
> @@ -676,14 +676,6 @@
> set_frame_menubar (f, 0, 1);
> BLOCK_INPUT;
> #ifdef USE_GTK
> - /* If we click outside any menu item, the menu bar still grabs.
> - So we send Press and the Release. If outside, grab is released.
> - If on a menu item, it is popped up normally.
> - PutBack is like a stack, so we put back in reverse order. */
> - f->output_data.x->saved_menu_event->type = ButtonRelease;
> - XPutBackEvent (f->output_data.x->display_info->display,
> - f->output_data.x->saved_menu_event);
> - f->output_data.x->saved_menu_event->type = ButtonPress;
> XPutBackEvent (f->output_data.x->display_info->display,
> f->output_data.x->saved_menu_event);
> popup_activated_flag = 1;
> ===========================
>
> fix the problem for me!
>
> As you can see, it regards GTK build (ifdef USE_GTK). Perhaps I understand the
> motivations for the changes in xmenu.c, but they break something. It is
> definitely a bug (better: a regression) for me. Since Emacs 22.0.50, I never
> seen the problem I described nor in all my GTK builds.
>
> Ciao,
> Angelo.

bug#6608: Menu bar not working

[Jan Djärv]

I have checked in a fix in the emacs-23 branch.  It will propagate to the 
trunk shortly.

	Jan D.

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 14/07/2010 12.17, Jan Djärv ha scritto:
> I have checked in a fix in the emacs-23 branch.  It will propagate to
> the trunk shortly.
>
> Jan D.

Sorry, but it is NOT YET FIXED in rev.100823 :(.

Indeed I still have to apply this patch:

=============================================
--- xmenu.c.orig        2010-07-13 00:22:58.674000000 +0200
+++ xmenu.c     2010-07-13 00:27:38.750000000 +0200
@@ -671,14 +671,6 @@
    set_frame_menubar (f, 0, 1);
    BLOCK_INPUT;
  #ifdef USE_GTK
-  /* If we click outside any menu item, the menu bar still grabs.
-     So we send Press and the Release.  If outside, grab is released.
-     If on a menu item, it is popped up normally.
-     PutBack is like a stack, so we put back in reverse order.  */
-  f->output_data.x->saved_menu_event->type = ButtonRelease;
-  XPutBackEvent (f->output_data.x->display_info->display,
-                 f->output_data.x->saved_menu_event);
-  f->output_data.x->saved_menu_event->type = ButtonPress;
    XPutBackEvent (f->output_data.x->display_info->display,
                   f->output_data.x->saved_menu_event);
    popup_activated_flag = 1;
=============================================

Should we reopen this BUG?

Ciao,
Angelo.

bug#6608: Menu bar not working [NOT FIXED]

[Angelo Graziosi]

I have bootstrapped (GTK builds) rev.100823-trunk on GNU/Linux Kubuntu 
(10.04) and on Cygwin, and the BUG is still there.

Definitively, NOT FIXED, for me.

Ciao,
Angelo.

Il 14/07/2010 23.58, Angelo Graziosi ha scritto:
> Il 14/07/2010 12.17, Jan Djärv ha scritto:
>> I have checked in a fix in the emacs-23 branch. It will propagate to
>> the trunk shortly.
>>
>> Jan D.
>
> Sorry, but it is NOT YET FIXED in rev.100823 :(.
>
> Indeed I still have to apply this patch:
>
> =============================================
> --- xmenu.c.orig 2010-07-13 00:22:58.674000000 +0200
> +++ xmenu.c 2010-07-13 00:27:38.750000000 +0200
> @@ -671,14 +671,6 @@
> set_frame_menubar (f, 0, 1);
> BLOCK_INPUT;
> #ifdef USE_GTK
> - /* If we click outside any menu item, the menu bar still grabs.
> - So we send Press and the Release. If outside, grab is released.
> - If on a menu item, it is popped up normally.
> - PutBack is like a stack, so we put back in reverse order. */
> - f->output_data.x->saved_menu_event->type = ButtonRelease;
> - XPutBackEvent (f->output_data.x->display_info->display,
> - f->output_data.x->saved_menu_event);
> - f->output_data.x->saved_menu_event->type = ButtonPress;
> XPutBackEvent (f->output_data.x->display_info->display,
> f->output_data.x->saved_menu_event);
> popup_activated_flag = 1;
> =============================================
>
> Should we reopen this BUG?
>
> Ciao,
> Angelo.
>

bug#6608: Menu bar not working

[Jan Djärv]

As it clearly says below: "the emacs-23 branch".  It has not even propagated 
to the trunk yet, it is a manual operation and it isn't done every day.

	Jan D.


Angelo Graziosi skrev 2010-07-14 23.58:
> Il 14/07/2010 12.17, Jan Djärv ha scritto:
>> I have checked in a fix in the emacs-23 branch. It will propagate to
>> the trunk shortly.
>>
>> Jan D.
>
> Sorry, but it is NOT YET FIXED in rev.100823 :(.
>
> Indeed I still have to apply this patch:
>
> =============================================
> --- xmenu.c.orig 2010-07-13 00:22:58.674000000 +0200
> +++ xmenu.c 2010-07-13 00:27:38.750000000 +0200
> @@ -671,14 +671,6 @@
> set_frame_menubar (f, 0, 1);
> BLOCK_INPUT;
> #ifdef USE_GTK
> - /* If we click outside any menu item, the menu bar still grabs.
> - So we send Press and the Release. If outside, grab is released.
> - If on a menu item, it is popped up normally.
> - PutBack is like a stack, so we put back in reverse order. */
> - f->output_data.x->saved_menu_event->type = ButtonRelease;
> - XPutBackEvent (f->output_data.x->display_info->display,
> - f->output_data.x->saved_menu_event);
> - f->output_data.x->saved_menu_event->type = ButtonPress;
> XPutBackEvent (f->output_data.x->display_info->display,
> f->output_data.x->saved_menu_event);
> popup_activated_flag = 1;
> =============================================
>
> Should we reopen this BUG?
>
> Ciao,
> Angelo.

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 15/07/2010 8.09, Jan Djärv ha scritto:
> As it clearly says below: "the emacs-23 branch".  It has not even
> propagated to the trunk yet, it is a manual operation and it isn't done
> every day.

Hmm... This means that #6608 should not be closed as 'FIXED' if we can't 
verify this on trunk.

Just for completeness, rev.100823 contains a new 'xmenu.c' file which, 
then, is not yet good for us :-).

Ciao,
Angelo.

>
> Jan D.
>
>
> Angelo Graziosi skrev 2010-07-14 23.58:
>> Il 14/07/2010 12.17, Jan Djärv ha scritto:
>>> I have checked in a fix in the emacs-23 branch. It will propagate to
>>> the trunk shortly.
>>>
>>> Jan D.
>>
>> Sorry, but it is NOT YET FIXED in rev.100823 :(.
>>
>> Indeed I still have to apply this patch:
>>
>> =============================================
>> --- xmenu.c.orig 2010-07-13 00:22:58.674000000 +0200
>> +++ xmenu.c 2010-07-13 00:27:38.750000000 +0200
>> @@ -671,14 +671,6 @@
>> set_frame_menubar (f, 0, 1);
>> BLOCK_INPUT;
>> #ifdef USE_GTK
>> - /* If we click outside any menu item, the menu bar still grabs.
>> - So we send Press and the Release. If outside, grab is released.
>> - If on a menu item, it is popped up normally.
>> - PutBack is like a stack, so we put back in reverse order. */
>> - f->output_data.x->saved_menu_event->type = ButtonRelease;
>> - XPutBackEvent (f->output_data.x->display_info->display,
>> - f->output_data.x->saved_menu_event);
>> - f->output_data.x->saved_menu_event->type = ButtonPress;
>> XPutBackEvent (f->output_data.x->display_info->display,
>> f->output_data.x->saved_menu_event);
>> popup_activated_flag = 1;
>> =============================================
>>
>> Should we reopen this BUG?
>>
>> Ciao,
>> Angelo.

bug#6608: Menu bar not working

[Eli Zaretskii]

> Date: Thu, 15 Jul 2010 14:53:51 +0200
> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Cc: Chong Yidong <cyd@stupidchicken.com>, bug-gnu-emacs <bug-gnu-emacs@gnu.org>
> 
> Il 15/07/2010 8.09, Jan Djärv ha scritto:
> > As it clearly says below: "the emacs-23 branch".  It has not even
> > propagated to the trunk yet, it is a manual operation and it isn't done
> > every day.
> 
> Hmm... This means that #6608 should not be closed as 'FIXED' if we can't 
> verify this on trunk.

??? Why?  The problem is fixed on a branch.  No one says it must only
be fixed on the trunk If you want it with the trunk now and cannot
wait for the merge, you can merge it yourself, manually.  If it later
turns out that the fix does not solve the problem, the bug could be
reopened.

Please don't increase the burden of those who fix bugs more than it is
already.

bug#6608: Menu bar not working

[Angelo Graziosi]

Il 15/07/2010 15.04, Eli Zaretskii ha scritto:
>> Date: Thu, 15 Jul 2010 14:53:51 +0200
>> From: Angelo Graziosi<angelo.graziosi@alice.it>
>> Cc: Chong Yidong<cyd@stupidchicken.com>, bug-gnu-emacs<bug-gnu-emacs@gnu.org>
>>
>> Il 15/07/2010 8.09, Jan Djärv ha scritto:
>>> As it clearly says below: "the emacs-23 branch".  It has not even
>>> propagated to the trunk yet, it is a manual operation and it isn't done
>>> every day.
>>
>> Hmm... This means that #6608 should not be closed as 'FIXED' if we can't
>> verify this on trunk.
>
> ??? Why?  The problem is fixed on a branch.  No one says it must only
> be fixed on the trunk If you want it with the trunk now and cannot
> wait for the merge, you can merge it yourself, manually.  If it later
> turns out that the fix does not solve the problem, the bug could be
> reopened.
>
> Please don't increase the burden of those who fix bugs more than it is
> already.

Eli, as you can see, I wrote also:

> Just for completeness, rev.100823 contains a new 'xmenu.c' file which, then, is not yet good for us :-).

So, one expected the fix was propagated to trunk... and the request to 
non close the bug was only by precaution, just to avoid the overload 'of 
those who fix bugs'. Evidently, my mental processes are too simple.

Thanks for your work and *Sorry* for the noise.

Ciao, Angelo.