Apache OpenOffice (AOO) Bugzilla – Issue 82158
No longer able to have multiple presentations on different desktops
Last modified: 2014-04-16 16:18:45 UTC
With OpenOffice 2.0.3 our organization could run up to 4 different presentations in different desktops without problems. We have a dual-head setup. Each presentation would be open on a separate desktop. Each desktop would have the 'main' window and the 'presentation' window on separate screens. Now - with the option to assign the presentation to a screen we can no longer run multiple presentations at the same time. We can open them on separate desktops but the first 'presentation' window will be the only one to be displayed on the second head. In OpenOffice 2.0.3 we would see entries in the window list / task bar for both the 'main' window and the 'presentation' window. Now - with 2.3 we only see entries for the 'main' window and the 'presentation' window does not show up in the window list / task bar. We would love to have the ability to once again run multiple presentations at the same time on separate desktops and to have the windows on those desktops be displayed like before.
One more thing -- when not in dual-head mode I am able to open the presentation - start the presentation and then use alt-tab to see if the 'main' window and 'presentation' window are shown in the window list / task bar. They are. So it appears to be a dual-head/ooimpress issue. It doesn't matter which distribution (tried Ubuntu and Fedora) nor does it matter what window manager (tried GNOME and KDE). Thanks.
ooo 2.1 or 2.2 introduced a new feature for the presentation that allows you to set the monitor that the presentation runs on. Please see the settings in "Slide Show" > "Slide Show Settings", and look at the bottom of the window that appears. In the same dialog, you may also want to change the type of slide shot to window.
If we change it to window we then have a window border around the presentation -- and that isn't acceptable in our setup. I'm probably not describing the problem very well -- I am aware of the new setting so that you can assign the presentation to either the primary or secondary monitor. It's when you have it in a dual-head setup and are able to assign that it stops showing the presentation as actually being a window and it overtakes the second display without any way of minimizing the presentation window. This is unlike previous behavior (before the ability to assign to a monitor) when it displayed as a separate window and it was capable of minimizing to the task bar. Does that make more sense or should I try to include screen shots?? Thanks for looking into this...
That explains it better, but I'll leave it to someone from the presentation sub-project to comment.
Created attachment 48658 [details] Window Lists in Dual-Head
Created attachment 48659 [details] Single Screen Windows List Screenshot
I just tried OO 3.0b2 in Fedora 9 and the issue remains. I did notice that when you start openoffice first and then setup dual-head using xrandr it will show the presentation in the window list as a separate window. Although in the impress slideshow settings it does not give you the opportunity to assign it to a 'head'. Then - leaving dual-head set up - if you close and restart impress -- impress then gives you the chance to assign the presentation to the different displays -- but then the presentation no longer shows up in the window list. This suggests to me that the problem is somewhere in the way impress implements it's ability to assign the presentation to a specific display.
Reassigned.
I have just intalled the 3.0 release. The issue persists. Once the presentation is started in dual-head mode it places the presentation on every single desktop instead of just once on the desktop it's supposed to. I have two very old 2.0.4 installations that need to be upgraded -- but cannot be until this issue is resolved.
This seems very similar to Bug 96916. And I concur that this problem exists and must be fixed.
Yes, yes, yes -- it is the same! All the other workspaces on the second head have been unusable since I first noticed this problem. It would be amazingly great to have this fixed! Especially with the introduction of the presentation tool in 3.0.
> All the other workspaces on the second head have been unusable > since I first noticed this problem. Yes. I did more testing. Normally I use Twinview, which Impress handles fine on Ubuntu but does not handle on Fedora. In order to get Impress to recognize that there are multiple displays on Fedora, I had to enable separate X screens without using either Twinview or Xinerama. So what I found is that when using two separate X screens instead of Twinview and without Xinerama, I see exactly the behavior you mention: all workspaces on the external monitor are stolen, but workspaces on the internal display actually work. And that is true when using the Presenter Console, which goes full-screen only on one workspace of the internal display, while the Slide Show is full-screen on all workspaces of the external display. That applies only when X is configured in that manner; if using Twinview or using Xinerama, the workspaces are consumed on both the internal and external displays. Based on the differential behavior, I'd say that this appears to be OOo related code that can be fixed.
I have another open defect against Impress related to how it handles fullscreen windows. As I've noted in Bug 96919, changing how Impress does fullscreen might fix this bug as well. For example, I am currently running totem in its full-screen display mode on an external monitor (nvidia twinview), can drag other windows on top of the totem display, and when I switch workspaces, the workspace handling is exactly as I want, and (I believe) exactly as you want. The Impress developers should take a look at how Totem is performing fullscreen mode, and change Impress accordingly.
*** Issue 96916 has been marked as a duplicate of this issue. ***
I previously remarked that resolving Bug 96919 by changing how Impress does fullscreen might fix this bug as well. Even though this defect and the duplicate I'd reported are still listed here as UNCONFIRMED and apparently ignored, Bug 96919 now has a developer assigned to it and a target milestone. Folks interested in seeing this defect resolved might want to follow (and vote for) Bug 96919. You might also want to comment if you agree with my assessment of that being a fix for both defects.
Bug 96919 is marked as closed. I assume we shouldn't vote for that one?
> Bug 96919 is marked as closed. I assume we shouldn't vote for that one? Bug 96916 is closed, as a duplicate of this defect. Bug 96919 is very much open. I just checked it.