Created attachment 75468 [details]
The patch fixing the bug. Reversed from OOo4Kids by EducOOo

Sorry, I wrongly described the case 1 in the tests. 

"1) start with one monitor only" means either 

- start on the laptop alone
- start on a machine 

without any videoprojector nor monitor attached, but just the current screen

HTH

The first patch was wrong and does work only when we click on "OK" dialog box,
what is not the expected behavior.

The problem is, we have to set the right monitor from the Presenter, and it
seems to not work well. As workaround, I modified present.cxx, and
slideshow.cxx, to make it work. 

Now, it works well (tested) on 

- Mac OS X 
- Linux

Windows is untested.


Remains : one issue when te user want's to change the monitor for the presentation.

I'll attach the patch as temporary fix, and if I can improve, I'll complete.
Apologies for the wrong initial patch.

Created attachment 75521 [details]
New patch, workig well on both Linux and MAc OS X (10.4 Intel)

I am not yet clear about the actual problem.

Here is what should happen:

- When there is only one display the presenter screen is not shown.

- When there are two displays then you can define the one on which to show the
presentation via the "Slide Show->Slide Show Settings..." dialog (at the bottom:
"Presentation display"). The presenter screen is then shown on the other display.

Does this not work on your system?

@af

Actually : 

- when there is one monitor only (e.g. the laptop without videoprojector) , the
Presenter screen is not shown. OK

-  When there are two displays then you can define the one on which to show the
presentation via the "Slide Show->Slide Show Settings..."

*BUT* the second specification is not sufficient.

Currently -without my patch- and starting the presentation doing nothing, the
Presenter screen is ALWAYS shown on the external monitor (the videoprojector
one), and the presentation appears always on my laptop. 

=>  This is wrong, and a bad user experience, because to make it work, the user
must always open the dialog box, to make it work as expected (and the user
sometimes has no clue where click to solve the issue ... )

The goal of my patch, is to swap the screens as the should be during the
presentation : simply always have the presenter screen on the laptop, and the
presentation on the videoprojector  _without_open_any_dialog_box_ ... just working. 

The later behavior provides a far better user experience, and this is what I
propose in my patch. I must say it is not perfect, and certainly needs some
change, but this is imho a good beginning.


Is it more clear ?

If I understand you correctly then the dialog box fox selecting the screen works
as expected.  It just is not very user friendly?

Yes, I agree with you on that.
But I have another idea of a solution: Add a button to the presenter screen for
exchanging the displays.

I do not know if one can properly divine the display on which to show the slide
show and the one on which to show the presenter screen.  But if I understand you
correctly you just want to provide a better default, right?

Can you be more specific about the details?  How to programatically identify the
displays of laptop, beamer, desktop pc, etc.

I agree with Eric that on a dual monitor system with the presenter console
running the slideshow should default to the second monitor.

_BUT_ please no symptom fixes. Without the presenter console the slideshow
should default to the primary display. And the primary display is the one with
index 0.

So this is a tough one, should the mere existence of the presenter console
switch the setting to index 1?
Or should the presenter console ignore the setting? Bad Idea IMHO.

Currently I have no idea how this is done sane. As always I think that solutions
using 'Magic' never work.

@af:

> If I understand you correctly then the dialog box fox selecting 
> the screen works as expected. 

Yes it does

> It just is not very user friendly?

In fact, the right user frendly behavior woud be to NOT have to open any dialog
box at all.


> Yes, I agree with you on that.

:-) 

> But I have another idea of a solution: 
> Add a button to the presenter screen for exchanging the displays.

Well, I agree with that, but with this solution, we do not avoid the user to
click. The initial request is : open the file, and launch the presenter screen
on the right display, doing nothing else. Imagine somebody double clicking on
the .odp document : the result is systematicaly wrong, because the monitors are
swaped by default.


> Can you be more specific about the details? 

I'll try

Please note that most of the issue is caused by the fact, that there is no other
way to exchange the monitors than opening the dialog box AND click OK 

(this is imho, due to a deep limitation in OpenOffice.org, asking to click on OK
buttons with modal dialogs, but that's another debate ;-)  )

> How to programatically identify the displays of laptop, 
> beamer, desktop pc, etc.

I traced on Mac and Linux (not Windows), and so far, when only one monitor is
detected, it is seen as number 0

My choice is : the Presenter screen must be blind and rely on what the 
void SdStartPresentationDlg::InitMonitorSettings() returns (
sd/source/ui/dlg/present.cxx:187 )

How does it work ? 
sd/source/ui/present.cxx and sd/source/ui/slideshow/slideshow.cxx will do the job

The principle is simple to add +1 to the selected monitor, and let the Presenter
screen use them

1) Modifications in present.cxx 

SdStartPresentationDlg::InitMonitorSettings() instantiates xMultiMon instance.
The number of monitors is returned by mnMonitors = xMultiMon->getCount() 

If mnMonitors is <= to 1, no need to use the PresenterScreen.

In the opposite case, means  if two or more monitors are detected, we are in the
case the Presenter screen is used. In this case, we check for system properties
MultiDisplay (boolean), and DefaultDisplay ( nPrimaryIndex ) will help.  Last if
bMultiScreen is true, we'll not start the Presenter screen either, because it
means the frame is shared in several monitors, and it does not make sense to use
the presenter screen here.

Behind the UNO interface, we have in fact the real work done in vcl. 
e.g. GetDefaultDisplayNumber is defined vcl/inc/salsys.hxx and implemented in
svapp.cxx, in Application::GetDefaultDisplayNumber(), itself using
pSys->GetDisplayScreenCount() ( pSys is a pointer of SalSystem object type,
defined in salsys.hxx ).

What I did is : 

if !bMultiScreen and nMonitor > 0 

and in the case the nSelected == 0 ( the default display ), then I select
nPrimaryIndex + 1 as default display.

In present.cxx:  maLBMonitor.SelectEntryPos( (USHORT)nSelected ) means that the
selected monitor who will appear in the listbox (if ever we open the dialog box)
is the one matching with nPrimaryIndex +1

2) Modifications in sd/source/ui/slideshow/slideshow.cxx 

Because the Presenter screen has no setter, we do the work when starting the
presentation, more precisely in void SlideShow::StartFullscreenPresentation( ) :


pWorkWindow->StartPresentationMode( TRUE,
mpDoc->getPresentationSettings().mbAlwaysOnTop ? PRESENTATION_HIDEALLAPPS : 0,
nDisplay +1 

=> this exactly forces to display the presentation on the right monitor, doing
nothing.


At the end, in PresenterScreen.cxx, I did :

- increment the nScreenCount  and nScreenNumber, to match the case ( nMonitor > 1)
- not swap the monitors, because it is no longer needed.


Unfortunaly, my patch is not perfect and needs some work. 

Sorry if I was not clear, but I'm not a native speaker.  HTH

@cl

I first thought to add some method in SalSystem, returning the "SecondDisplay"
value, if ever it exists. Maybe pl could answer ?

one idea I just had. Not a solution but a convenience feature...

What about a 'swap display' button on the presenter console?

user scenario:

- user starts presentation with two displays
- presenter console comes up at the audience display, slideshow comes up at the
presenters screen
- instead of stopping presentation and fiddling with presentation settings the
presenter presses the 'change display' button and the display is swapped

This could also be a nice feature for a speaker to promote OOo by demonstrating
the audience what 'he' currently sees with a mouse click.

@cl

Your idea is a great idea, e.g. we could train teachers to Impress wit that, 
and I'm really interested to implement it.

Can we define a plan ? We could even ask a student to work on that ?

That's no problem for me to work with the OOOo code, and backport it into
OOo4Kids or the opposite.

And if you are interested, I integrated the Presenter Screen into the set (it is
no longer an extension). Just in case, the code can be reversed too, no problem
either :)

 

I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:  dev@openoffice.apache.org

Thanks!

-Rob

Reset assigne to the default "issues@openoffice.apache.org".