Apache OpenOffice (AOO) Bugzilla – Issue 2943
Menus unusable with mouse under GNOME
Last modified: 2003-03-11 17:55:36 UTC
Under Solaris 8, no menus work with the mouse under GNOME. The menu pops up but as soon as you move the mouse to try to select a menu item it disappears. It doesn't matter if you hold the left button down or not. Keyboard shortcuts work fine. This wasn't an issue in 638. It happens under the GNOME 1.4 distributed by Sun and the one distributed by Ximian. There is no issue under CDE 1.4.
This also happens under RedHat Linux 7.2 with Sawfish. Running without a windowmanager makes the problem go away.
It's all related to the focus methods used by the window manager. I normally use "focus on enter-exit" under Sawfish. When I switch to "Focus on Click" the problem goes away. It's a basic problem with the whole UI in StarOffice because it's not just pull-down menus but all sorts of pop-down selectors etc.
This bug means that StarOffice 6 will not be usable at MIT. A fair number of users here are going to be unwilling to change their focus behavior to click-to-type. SURELY there is a way to craft the Open Office user interface in a way that requires neither eliminating the OTHER way to use input focus, nor a total rewrite of Open Office.
Actually this is fixed for sawfish (the default window manager on GNOME) in the next Ooo build as well as in SO6 final. We found one more window manager that exposes this behaviour and the corresponding fix is in for Ooo stable 1.
*** Issue 3334 has been marked as a duplicate of this issue. ***
It is troubling to see that the fix in OpenOffice is window-manager specific. Are you folks following the X InterClient Communications Conventions Manual properly? At MIT we have MANY users that default to using twm, and the SGI fvwm. OpenOffice is gonna look mighty bad if special case code is required for every window manager. That's why the ICCCM was written to OBVIATE wm-specific code. If you aren't following ICCCM, then your app is officially classifiable as "Poorly Behaved under X". -wdc (I was there when the ICCCM was written. It's not perfect, but following it IS a good idea.)
Excuse me for speaking so bluntly, but this is crap. Under 641, Gnome, sawfish WM, redhat 7.0, I got NO menus at all, so I threw it away and tried 642. At least under 642 I get the pull-down menus, but I have to use the keyboard to navigate them. Ok, at least I can use the thing. So the big day arrives, and I download 1.0. What do I find? NO PULL_DOWN MENUS at all. I.e. 641D behaviour. I am about to upgrade to redhat 7.3, but from what has been said here, that will make no difference. And I am not going to change to click-to-focus. Focus behaviour is one of the fundamental preferences that people express, and fundamental preferences are hard to change. Add to that the fact that there is no release note warning potential users like me what the cost of use is going to be. How many Gnome/Sawfish linux users are out there? How many of them have been hanging out for this software. And what so you suppose those users are going to say about the quality control on this software when they hit this bug?
Upgrading made a difference, but in unexpected ways. I upgraded to 7.3, but had a very messy upgraded because, e.g., I don't use RPMs for XFree86. Didn't like Nautilus, so I changed to KDE. At the end of the process, I wanted to retrieve some fonts from a deleted copy of so5.2, so I re-installed 5.2, copied the fonts, and deleted the installation. I then tried to run setup on 642 to repair the installation. It wouldn't load because it could not find libstdc++-libc6.1-2.so.3. After flailing around for a while, I linked /usr/lib/libstdc++-libc6.1-2.so.3 to /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so, which is in the libstdc++-2.96-110 RPM. At the same time, I added /usr/i386-glibc21-linux/lib to /etc/ld.so.conf and ran ldconfig in order to pick up /usr/i386-glibc21-linux/lib/libdb.so.2 -> libdb1-2.1.3.so in order to get some gnome binaries to work. libdb1-2.1.3.so is from the compat-glibc-6.2-2.1.3.2 RPM. At the end of this messy process, I ran the setup and repair of 642 successfully, and then, to my surprise, the menus worked with the mouse, and with focus-follows-mouse. At the very least, this above mess shows that the problem with menus on 642 relates not to focus-follows-mouse per se, but to implementation problems with specific WMs. I haven't tried the 641 release yet, but I have high hopes.
This looks like a dup of 3706, 3548 and 2691. 2786 has already been marked as a dup of 2691. *** This issue has been marked as a duplicate of 2691 ***
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details. First step in IssueZilla is unfortunately to set them to verified.
As mentioned on the qa dev list on March 5th I will close all resolved duplicate issues. Please see this posting for details.