awesome changes the desktop because it receives
a _NET_CURRENT_DESKTOP open office client message.

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?

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 ) 
            GetDisplay()->getWMAdaptor()->switchToWorkArea(
mpParent->m_nWorkArea ); 
 

in salframe.cxx, around line 1168.

This kind of request are meant to be sent by a pager, see EWMH:
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2506278
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.

cd: This issue is related to gsl which includes VCL the user interface library.
Set pl on CC.

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 ?

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.

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.

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.

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.

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.

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.

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.

*** Issue 96684 has been confirmed by votes. ***

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.

This pretty much renders OO unusable for me. Well.. not OO, but the rest of the
system.

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.

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.

Checked and verified in cws vcl116 -> OK !

Got into AOO 3.4.0 => closing