Issue 82158 - No longer able to have multiple presentations on different desktops
Summary: No longer able to have multiple presentations on different desktops
Alias: None
Product: Impress
Classification: Application
Component: viewing (show other issues)
Version: OOo 3.0
Hardware: All Linux, all
: P3 Trivial with 3 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: needhelp
: 96916 (view as issue list)
Depends on:
Reported: 2007-10-01 22:26 UTC by markginter24
Modified: 2014-04-16 16:18 UTC (History)
5 users (show)

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

Window Lists in Dual-Head (288.89 KB, image/png)
2007-10-02 21:41 UTC, markginter24
no flags Details
Single Screen Windows List Screenshot (168.79 KB, image/png)
2007-10-02 21:42 UTC, markginter24
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description markginter24 2007-10-01 22:26:16 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.
Comment 1 markginter24 2007-10-01 22:28:19 UTC
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).

Comment 2 shaunmcdonald131 2007-10-02 17:38:12 UTC
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.
Comment 3 markginter24 2007-10-02 20:27:41 UTC
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...
Comment 4 shaunmcdonald131 2007-10-02 21:39:13 UTC
That explains it better, but I'll leave it to someone from the presentation sub-project to comment.
Comment 5 markginter24 2007-10-02 21:41:30 UTC
Created attachment 48658 [details]
Window Lists in Dual-Head
Comment 6 markginter24 2007-10-02 21:42:04 UTC
Created attachment 48659 [details]
Single Screen Windows List Screenshot
Comment 7 markginter24 2008-07-28 13:30:34 UTC
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.
Comment 8 wolframgarten 2008-09-05 12:45:13 UTC
Comment 9 markginter24 2008-10-16 18:53:34 UTC
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.  
Comment 10 noeljb 2008-12-05 04:16:44 UTC
This seems very similar to Bug 96916.  And I concur that this problem exists and
must be fixed.
Comment 11 markginter24 2008-12-05 12:19:16 UTC
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.
Comment 12 noeljb 2008-12-05 20:23:57 UTC
> All the other workspaces on the second head have been unusable
> since I first noticed this problem.


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.
Comment 13 noeljb 2008-12-05 21:23:58 UTC
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.
Comment 14 wolframgarten 2008-12-08 08:43:01 UTC
*** Issue 96916 has been marked as a duplicate of this issue. ***
Comment 15 noeljb 2008-12-10 15:07:01 UTC
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.
Comment 16 markginter24 2008-12-10 18:13:39 UTC
Bug 96919 is marked as closed.  I assume we shouldn't vote for that one?
Comment 17 noeljb 2008-12-10 20:10:07 UTC
> 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.