Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Display the presenter screen on the right monitor|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Issue Type:||PATCH||Latest Confirmation in:||---|
Description eric.bachard 2011-01-05 07:25:10 UTC
By default, the presenter screen is displayed on the bad monitor, and this is a bad User Experience. The attached patch (tested on Mac only) seems to fix the bug, but needs a review, and comments Process: * Check for present external monitor(s) for every test * Open Impress * Open a presentation * Start the diaporama Tests made in the following cases (verified on Mac Intel 10.4 only) : 1) start with one monitor only : choice initialized to not display the Presenter Screen, and the Presentation appears as expected. 2) start with laptop + external monitor (simulating the beamer). Once sure the external monitor is detected : the presenter screen displays on the laptop only (uff). 3) multi monitors (aka extended mode) : untested, and could desserve a little change. Not tested on Linux nor Windows. Thanks in advance !
Comment 1 eric.bachard 2011-01-05 07:27:04 UTC
Created attachment 75468 [details] The patch fixing the bug. Reversed from OOo4Kids by EducOOo
Comment 2 eric.bachard 2011-01-05 09:46:55 UTC
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
Comment 3 eric.bachard 2011-01-10 11:05:36 UTC
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.
Comment 4 eric.bachard 2011-01-10 11:06:57 UTC
Created attachment 75521 [details] New patch, workig well on both Linux and MAc OS X (10.4 Intel)
Comment 5 groucho266 2011-01-11 09:53:21 UTC
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?
Comment 6 eric.bachard 2011-01-11 13:12:12 UTC
@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 ?
Comment 7 groucho266 2011-01-12 10:02:35 UTC
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.
Comment 8 clippka 2011-01-12 12:44:48 UTC
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.
Comment 9 eric.bachard 2011-01-12 12:48:58 UTC
@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
Comment 10 eric.bachard 2011-01-12 12:55:16 UTC
@cl I first thought to add some method in SalSystem, returning the "SecondDisplay" value, if ever it exists. Maybe pl could answer ?
Comment 11 clippka 2011-01-12 22:27:23 UTC
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.
Comment 12 eric.bachard 2011-01-14 10:21:25 UTC
@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 :)
Comment 13 Rob Weir 2013-03-11 15:03:00 UTC
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: email@example.com Thanks! -Rob