Issue 96684 - Openoffice doesn't interacts fine with awesome window manager
Summary: Openoffice doesn't interacts fine with awesome window manager
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: All Unix, all
: P3 Trivial with 12 votes (vote)
Target Milestone: 3.4.0
Assignee: thorsten.martens
QA Contact: issues@gsl
Depends on:
Reported: 2008-11-28 11:28 UTC by i5513
Modified: 2012-10-09 09:05 UTC (History)
4 users (show)

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


Note You need to log in before you can comment on or make changes to this issue.
Description i5513 2008-11-28 11:28:37 UTC

If you have a firefox open in '2' tags and a oowriter instance in '4' tag, and
open from firefox download launcher one oo doc, it doesn't works like is expected.

In awesome issue tracker tells about this is a oo bug.

Is this bug dup ?

I'm with 2.4 debian version of openoffice (I don't known if 3.0 solve this issue)

Comment 1 i5513 2008-11-28 14:09:40 UTC
awesome changes the desktop because it receives
a _NET_CURRENT_DESKTOP open office client message.
Comment 2 2008-12-01 10:33:23 UTC
i belive i have lately had a problem with (likely) similar cause:
i had a bunch of documents open, and then ooo crashed. then i let it restore the
documents, while doing something else on another virtual desktop.
this, however, did not go according to plan, because whenever ooo opened a new
window, it switched to its own virtual desktop, so i couldn't do any web
browsing (err, i mean, work) in another desktop.
it is very nice of ooo to open the document windows on the same virtual desktop
as the recovery window, but could it please do that without switching the window
manager to that same virtual desktop?
in other words, can we do without sending these _NET_CURRENT_DESKTOP messages?
Comment 3 jdanjou 2009-02-11 14:19:12 UTC
This bugs come from the fix of issue 45160:

        // #i45160# switch to desktop where a dialog with parent will appear 
        if( mpParent && mpParent->m_nWorkArea != m_nWorkArea ) 
mpParent->m_nWorkArea ); 

in salframe.cxx, around line 1168.

This kind of request are meant to be sent by a pager, see EWMH:
Please, remove that code unless you are actually writing a
pager and not a word processing tool, and let the window
manager do it job.
Comment 4 carsten.driesner 2009-02-11 14:37:12 UTC
cd: This issue is related to gsl which includes VCL the user interface library.
Set pl on CC.
Comment 5 philipp.lohmann 2009-02-11 14:55:47 UTC
If window managers did their job, they would switch the workspace on their own
when a transient for a window gets mapped. Unfortunately not all window managers
behave that well.

Aside from that the line of code in salframe.cxx gets only active if there is a
transient for a document window about to appear, so this does not fit the
description of the submitter. Unless there was an undocked toolbar involved that
gets shown ? Could someone confirm that ?
Comment 6 jdanjou 2009-02-11 15:32:29 UTC
I know many window manager do bad job. The correct thing is here is not, IMHO,
to switch the active workspace, since that can disturb the user, but to tag the
transient windows with the same desktop, or just do nothing and let the window
manager doing it well (or not).

But this is definitively no the job of an application to switch workspaces.

FWIW, this event is sent whenever a menu appears, or when the mouse wheel is
used to scroll down the document in my case.
Comment 7 philipp.lohmann 2009-02-11 15:46:02 UTC
Yes, that would be the case, only in these cases the desktop won't really change
- granted that's unnecessary prtotocol traffic. We could of course take that
line out, but then people would end up with OOo opening a dialog on another
desktop again and wondering why nothing happens.

cd: originally we did this switching because people would open the file or
template dialog via the system's desktop menu and somehow OOo's framework could
not survive that those dialogs have no parent. Is that still the case ? Because
all my ranting about window managers aside (of which there are too many and you
cannot rely on a single thing with them aside from them causing all kinds of
pain), it is well within a window manager's domain to decide whether a newly
mapped window should get the focus or not - including switching the desktop. The
best solution would indeed be if those dialogs needn't have a parent, which
would make them appear on the current desktop instead of the other that by
chance contains one of OOo's frames.
Comment 8 gbe 2009-02-11 15:47:41 UTC
I agree the awesome community might not be as big as the KDE or Gnome community,
but what good does it to break compatibility with standards just for the sake of
adding comfort for users who use a windowmanager which does a bad job? (Not
saying KWin or Metacity are bad window managers, but here they do a bad job) I
am sure awesome is not the only (mostly) standards compliant window manager
which suffers from this problem.
Comment 9 jdanjou 2009-02-11 15:56:58 UTC
For the record and AFAIK stumpwm suffers of this is.

Well, the worst part is that it's cannot be turned off or worked around in the
window manager code, since there's no way to determine where this
_NET_CURRENT_DESKTOP message comes from.
Comment 10 philipp.lohmann 2009-02-11 16:13:40 UTC
gbe: it certainly is in OOo's best ineterest that OOo users can expect a useful
user experience even with a quirky window manager. As for OOo "breaking a
standard" here, OOo actually relies on the EWMH standard for the desktop switch
to work. There is no standard breaking involved here at all.

jdanjou: I'd rather hope that awesome can't find a way to see the desktop switch
comes from OOo. If they worked around the EWHM protocol, the only thing left to
us would be to work around its workaround.

As I already said, I'd remove that desktop switch request again if the original
problem (issue 45160) didn't show up again.
Comment 11 carsten.driesner 2009-02-11 16:30:34 UTC
cd->pl: I fear that there is code inside framework/toolkit which needs a parent
for every dialog. To be sure we should just try out what happens if you remove
it. May be we can see what must be done to change it. Depending on the effort we
can decide what to do.
Comment 12 oreolek 2010-07-16 03:51:36 UTC
I confirm the bug.
Please make a checkbox in the Options so a user could deactivate this behavior.
Or damned remove this code so OOo would not do what it's not supposed to 
do.There're more window managers in Linux than KDE and GNOME.
Comment 13 ewingd 2010-07-27 16:27:45 UTC
*** Issue 96684 has been confirmed by votes. ***
Comment 14 ewingd 2010-07-27 16:31:29 UTC
I can also confirm this bug while using Awesome.  Please do something to resolve
this issue.  In the current state OpenOffice is quite frustrating to use.
Comment 15 snsaipperi 2010-09-12 19:15:57 UTC
This pretty much renders OO unusable for me. Well.. not OO, but the rest of the
Comment 16 abargnesi 2010-10-04 17:10:23 UTC
I also have this issue with OpenOffice / Awesome Window Manager.  I'm running
dual heads and if I have one head with Open Office, and I scroll, the "Page 1 /
4" will appear on the other head.  This changes the current workspace on the
other head.
Comment 17 philipp.lohmann 2010-10-25 14:52:07 UTC
fixed in CWS vcl116

workspace switch not happening on awsome now per default. also added a
configuration option in VCL.xcu that will override this; no UI for that though.
Comment 18 thorsten.martens 2010-11-02 13:13:57 UTC
Checked and verified in cws vcl116 -> OK !
Comment 19 2012-10-09 09:05:03 UTC
Got into AOO 3.4.0 => closing