Issue 49842 - right mouse-click popup menu does not appear with KDE "Focus Strictly Under Mouse" setting
Summary: right mouse-click popup menu does not appear with KDE "Focus Strictly Under M...
Status: CLOSED DUPLICATE of issue 39420
Alias: None
Product: Writer
Classification: Application
Component: ui (show other issues)
Version: OOo 2.0 Beta
Hardware: All Unix, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: ulf.stroehler
QA Contact: issues@sw
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-25 10:23 UTC by mwaeckerlin
Modified: 2013-08-07 14:42 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description mwaeckerlin 2005-05-25 10:23:02 UTC
The right mouse-click popup menu does not appear with KDE "Focus Strictly Under
Mouse" setting. It works with "Focus Under Mouse" (no "strictly"). The parameter
is set in "KControl", "Desktop" - "Window Behavior".

-> The same problem occurs in *all* OpenOffice components (chart, presentation,
draw)! (unfortunately, there's no category "all")

-> OpenOffice behaviour was always a problem, when focus is strictly under
mouse, also with 1.x, on PC-Linux and Sparc-Solaris. In OO 1.x. In OO 1.x the
problem is not with popup menu, but with popup windows, such as stylist. When
the window looses focus, stylist disappears. When there are two documents open,
only one stylist is open, and that one often on the wrong position, over the
wrong window. When stylist is outside of the OO window, it disappears, while
trying to move with the mouse over to the stylist. Sometimes, stylist flickers,
shows and hides and shows and hides ... at high frequency. sometimes, not too
seldom, OO 1.x crashes, when stylist shows or hides. But flickering and crashing
happens from time to time, but is not very reproducable. The source of these OO
1.x problems is probably the same as with the popup menu in OO 2beta. Suggested
solution for the 1.x problem: OO must not close stylist (and similar) windows,
when OO looses focus, and there should be one stylist window for each document!

-> In OO 2beta, I retested the problems from 1.x. I can reproduce the following:
When stylist is outside of the OO window, it disappears, while trying to move
with the mouse over to the stylist. -> This problem persists also, if "Focus
Under Mouse" is set, without the "Strictly"!!

In general, the support for the standard UNIX "focus follows mouse" concept is
very bad in OpenOffice, not only 2, but also 1.x!

Actally using: OpenOffice 1.9.79-9.2 from SuSE 9.3 RPM
Comment 1 michael.ruess 2005-05-25 10:36:40 UTC
Reassigned to US.
Comment 2 ulf.stroehler 2005-05-25 10:50:19 UTC
@mwaeckerlin: thanks for your issue report.
Admitedly a missing context menu is not acceptable; however P1 is surely
inappropriate.
Comment 3 mwaeckerlin 2005-05-26 09:14:32 UTC
I think all these problems can easily be resolved with one single correection:

Change: Nothing should ever be closed, only because something looses the focus!
A focus change is no reason for closing anything.

For the popup menu: It should only close on one of the following events:
 - an item was selected
 - the user hits "esc" key
 - the user clicks somewhere else
   (must be a click, not a simple focus change)

For the stylist, etc. windows:
 - They should *never* be closed at all, unless the
   user hits the close button! Why can't they simply
   stay open?
 - Every document window should have it's own stylist,
   on an individual position, not one window and a
   global position for all documents!

The behaviour of these windows has always been very strange and unusual in
OpenOffice! I've always hated this behaviour, but now together with the
popup-menu issue, it became really unusable. All other applications I know
behave exactly in the way I described above: No strange and unwanted window
closing. Windows (position, size, open/close), mouse, focus, etc., are things
that must be under full control of the user, at least after a first
initialisation (means also, mouse must not jump around - that's fortunately
configurable in OO).


@us: I agree to lowering the priority, but I suggest to correct it before final
2.0 release.
Comment 4 ulf.stroehler 2005-05-26 09:46:09 UTC
Dupe.

*** This issue has been marked as a duplicate of 39420 ***
Comment 5 ulf.stroehler 2005-05-26 09:48:37 UTC
Hope it's ok to close the dupe.
Please refer to issue 39420. Thx.