The OpenLP team (openlp.org) have built controls to run presentations from their software using the uno bridge. Now the Presenter Console has been made mandatory it is not possible to see the OpenLP screen when showing presentations. OpenLP is a fully cross platform product so on linux this the only office product available. Would it be possible to add a switch / api call to remove the Presenter Console.
Presenter Console is an extension, you can remove it. You probably need to launch LibreOffice with administrative right to do that.
None of the dev or users have managed to remove it.
(In reply to comment #2) > None of the dev or users have managed to remove it. Why? You can remove it from your own LibreOffice installation.
So the solution is to hack the installation! This is not a good idea to tell our users to hack their installation. They may want to use it at some other time. The Fedora installation does allow for a selective install.
I would think it is a good idea to be able to turn off the presenter-console.
Setting this as a enhancement request
I read on the LibreOffice 4.0 release notes that the Presenter Console has been made a part of core. I asked around at #libreoffice on Freenode, and was told that it cannot be turned off. Before this I was able to turn it off by removing the extension files from the LO installation directory after every upgrade. This is a blocker bug for me. We use LibreOffice at our congregation to show slides and song lyrics and have to use the computer to manage recordings and other stuff at the same time. There needs to be a setting to turn the Presenter Console off permanently (a per presentation setting won't be enough). I have changed the LibreOffice version of the enhancement request to 4.1, because as far as I know the change cannot be made for 4.0 anymore. Let me know if I shouldn't have touched it.
I was told to keep the version at the original one so I'm setting it back.
If you do not use animations in your presentations, you can export them in pdf format and show them with your pdf viewer which has a presentation mode (hit F5 in Evince). Best regards. JBF
This is not user friendly when running on windows and one is trying to prevent the purchase of Microsoft software. Powerpoint has this as an option but having this enforced reduces the usability of the software where one needs to integrate it with other software packages.
That's not what Jean-Baptiste is trying to say. He tries to offer a workaround for the time being. It is a good feature to have but as it isn't there yet we don't have another solution now.
(In reply to comment #11) > That's not what Jean-Baptiste is trying to say. > He tries to offer a workaround for the time being. It is a good feature to > have but as it isn't there yet we don't have another solution now. Indeed, and pdf format has nothing to do with Microsoft. It is an open standard and you can read PDF files without using proprietary softwares.
Just wanted to add a vote for this feature/bug.
Just a note on this for anyone following: It seems you can disable the presenter screen by deleting the file "C:\Program Files\LibreOffice 4.0\program\PresenterScreen.uno.dll", as per https://bugs.freedesktop.org/show_bug.cgi?id=33495#c5 I myself will probably use this until we get a real config setting.
Some code pointers, to turn this into an EasyHack: The presenter screen registers a job that runs on every new Impress document, here: officecfg/registry/data/org/openoffice/Office/Jobs.xcu , which then runs PresenterScreenJob::execute() from sdext/source/presenter/PresenterScreen.cxx, which in turn registers a slideshow listener, that fires up the console once slideshow is started (and more than one display is connected). Easiest hack: switch off this PresenterScreenJob direclty in Jobs.xcu. That sucks slightly, because it does not have an effect (neither disable nor enable) for already loaded documents. Slightly more involved hack: kill off the PresenterScreenJob entirely (since we're no extension anymore), instead instantiate PresenterScreen direclty where this OnStartPresentation event is sent (SlideshowImpl::startShowImpl(), in sd/source/ui/slideshow/slideshowimpl.cxx). Have UI for that in the Slideshow->Slideshow settings dialog.
A note on the UI, which I already stated on #libreoffice: There are a few ways that I can think of to create the UI part. As I understand, most of the settings in "Slideshow -> Slideshow settings" are per-slideshow. A per-slideshow way to turn off the presenter screen is not enough IMO, so we need a global setting. That would be, again IMO, confusing to have in Slideshow settings. Here's a few ways that I think are possible, with their respective cons: 1) Have a global option to turn on/off the presenter screen. Could get annoying if you need to toggle it often. a) This global option can be in the main settings, where it's not accessible as easily. b) Or it can be in Slideshow settings, where I think it may be confusing to have global settings. 2) Have a global and a per-presentation setting. Could be confusing for users to have similar settings in two places. 3) Have two ways to launch a presentation: with or without presenter screen. Could be very confusing. I myself lean on just putting a global setting in the main settings dialog, under the Impress section somewhere. I don't think many people have the need to toggle the setting on and off very often (of course this is just a baseless assumption), in which case the main settings dialog should work well.
I disagree and think there is a need to be able to control if the presenter view is going to show and for that setting to remain in place as set the next time you launch LibreOffice. In other words an easy toggle on and off. Have you taken a look at the setting in the "Other" office product. I suggest it needs to work like that.
What do you disagree with? What I suggest is the same as yours (a global setting in the main settings dialog).
Two things. One Powerpoint (which I use at work has it on the presentations screen) and it stays set as a global parameter. The original requirement was also to be able to disable it via an API as the software we have released interacts with LibraOffice via API's.
Sorry, I was disagreeing with you assertion that users wouldn't want to change it often. (In reply to comment #18) > What do you disagree with? What I suggest is the same as yours (a global > setting in the main settings dialog).
Now this is very easy, Apache OpenOffice have just implemented this: http://cgit.freedesktop.org/libreoffice/core/commit/?h=aoo/trunk&id=1eb66b9730e16f1dd1be426c7d0901b41c300b34
The only non-trivial part is that is that in sd/source/ui/dlg/tpoption.src, the option window doesn't use widget layout yet, so this new option and the "enable remote control" one would have the same position. Be sure to check that window before submitting the patch. :-)
Can someone explain exactly what that patch does in English, so we can decide if it's the best way of doing it? Does it add a setting in the Slideshow settings dialog, or some other place?
(In reply to comment #23) > Can someone explain exactly what that patch does in English, so we can > decide if it's the best way of doing it? Does it add a setting in the > Slideshow settings dialog, or some other place? It adds a setting in the global Options dialog (Impress->General->Presentation) A better place might be "Slide Show Settings" Dialog in the Section "Multiple Displays".
I disagree. In my opinion the global settings dialog is the right place for it, because my intuition tells me Slideshow settings are per-slideshow and shouldn't last (though I understand there are some there that are actually global settings).
Is it not something you want from both. The global setting is the default but can be overridden on a per case basis. You mat not want it on for the development of a slide show but when you are showing it you then switch it on.
(In reply to comment #15) > Some code pointers, to turn this into an EasyHack: > > The presenter screen registers a job that runs on every new Impress > document, here: > officecfg/registry/data/org/openoffice/Office/Jobs.xcu > > , which then runs PresenterScreenJob::execute() from > sdext/source/presenter/PresenterScreen.cxx, which in turn registers a > slideshow listener, that fires up the console once slideshow is started (and > more than one display is connected). > > Easiest hack: switch off this PresenterScreenJob direclty in Jobs.xcu. That > sucks slightly, because it does not have an effect (neither disable nor > enable) for already loaded documents. > > Slightly more involved hack: kill off the PresenterScreenJob entirely (since > we're no extension anymore), instead instantiate PresenterScreen direclty > where this OnStartPresentation event is sent > (SlideshowImpl::startShowImpl(), in > sd/source/ui/slideshow/slideshowimpl.cxx). > > Have UI for that in the Slideshow->Slideshow settings dialog. Hey, I've done the above hack and it is now working if you restart after changing options, now I want to move over to second one. The problem I'm facing is, how do I include the PresenterScreen.hxx in the slideshowimpl.cxx and when I do, do I just create an object and everything else will just work?
Hi Manik, good to see you working on this. can you send a 'git diff' of what you've done together with your question to the Mailing List? There you get more attention than here.
(In reply to comment #28) > Hi Manik, > good to see you working on this. > can you send a 'git diff' of what you've done together with your question to > the Mailing List? > There you get more attention than here. I hope I'm not disturbing you, I just wanted to confirm before disturbing a whole lot of more people if my approach was acceptable. I had earlier removed the Job which meant that once Listener was activated (On startup) it looked if the Enable Presentation Screen was checked and accordingly added or ignored the Job. Now I have moved the condition to the actual event listener function void SAL_CALL PresenterScreenListener::notifyEvent( const css::document::EventObject& Event ) throw (css::uno::RuntimeException); And only initialised the presenterScreen object if object is enabled which now works flawlessly. I followed the norms and the function which checks if the option is enabled is defined in presenterScreen interface and implemented in presenterScreen implementation and uses presentationConfiguration and existing context.
Sorry, I don't know that code and can't help you. You are not disturbing people on that list, it *is* for development questions. So don't hesitate to ask your questions there :)
Just got the patch accepted https://gerrit.libreoffice.org/#/c/3762/
mmeof committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=39da7ee77e5c5add8aaef12bf1e80c66132782fa fdo#56995 Created global option to disable presenter console in Impress The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
This is great work. Thank you so much, Manik. I hope this makes it into 4.1, then I can resume using the latest version of LO. :)
(In reply to comment #33) > This is great work. Thank you so much, Manik. I hope this makes it into 4.1, > then I can resume using the latest version of LO. :) The patch has been pushed to master then it will be in LO 4.2. I am not sure if it can be backported to 4.1 because features freeze has passed and the change needs at least new string in the UI that has to be translated in each supported language. I guess you will have to wait until the release of LO 4.2.0. Best regards. JBF
Right - the string & UI freeze is ~today, but I guess if I can round up some tripple review it should be possible - it is after all not the world's most complicated patch (from a UI and string perspective). I'll have a go ... :-) thanks so much for the contribution !
Ho hum; turns out it is already in 4.1 :-) In which case I'll add the feature to the 4.1 wiki page. Good ...
(In reply to comment #36) > Ho hum; turns out it is already in 4.1 :-) In which case I'll add the > feature to the 4.1 wiki page. Good ... Indeed, comment#32 was sent before the 4.1 branch. Sorry for the inconvenience. Best regards. JBF
Migrating Whiteboard tags to Keywords: (EasyHack,DifficultyBeginner,SkillCpp ) [NinjaEdit]