Created attachment 157030 [details] drawings only shown in the left pane preview in version 6.2.0.0.alpha1 1. Enter presentation mode, right-click and select "mouse pointer as pen" in the context menu and we can draw on the slide, but the drawings wouldn't be saved after leaving the presentation mode. That's okay. 2. Before entering presentation mode, go to "slide show settings" and check "mouse pointer as pen". Then enter presentation mode. The default mouse pointer would be a pen and we can draw on the slide without checking in the context menu. And the drawings would be saved after leaving the presentation mode. 3. However, after 6.2.0.0.alpha version, the drawings of the second condition would only be shown in the left pane preview, not in the slides, and hence have no way to delete that. It works in the version 6.1.5.2 but not in 6.2.0.0.alpha1. Version: 6.2.0.0.alpha1 Build ID: ff46ad24d1d3cbcea45895520483ed1fd4ff488b CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; Locale: zh-TW (zh_TW.UTF-8); Calc: threaded Version: 6.1.5.2 Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805 CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: kde4; Locale: zh-TW (zh_TW.UTF-8); Calc: group threaded
Created attachment 157031 [details] drawings show both in the left pane preview and in the slide in version 6.1.5.2
#122784 may be the same problem though it mentioned KDEConnect.
confirmed here with Version: 6.3.4.2.0+ Build-ID: 1:6.3.4-2 CPU-Threads: 2; BS: Linux 5.4; UI-Render: Standard; VCL: kde5; Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE Calc: threaded
Just learned of this feature from an Ask answer: https://ask.libreoffice.org/de/question/236005/freihand-schreiben/ This was originally broken in: commit 9826a4e4a6aa9953d3f354fe645a23f9dae59d77 Author: Regina Henschel <rb.henschel@t-online.de> Date: Fri Aug 17 19:02:55 2018 +0200 tdf#101242 Support draw:display and draw:protect attributes of ODF After that commit the drawn lines completely vanished in the normal and thumbnail slide list view. The presentation itself is unaffected. A bit later it was partially fixed in commit d59acca8d1e33585d6f29cd85e8cb0d598067f9b Author: Regina Henschel <rb.henschel@t-online.de> Date: Sat Sep 1 13:03:29 2018 +0200 tdf#119611 Use generic SetAll() in SdrPageView ctor. which made the lines again visible in the preview images, but they are still not visible or editable in normal mode, as before commit 9826a4e4a6aa9953d3f354fe645a23f9dae59d77. CC'ing Regina P.S. interestingly the lines are actually a multitude of consecutive, ungrouped draw:line shapes, so even a small "round" line "explodes" into a few hundred shapes. You can "see" these in the navigator, if you select "All shapes" in the "Show shapes" drop-down box, but no modification is possible (I had expected some delete action, at last). P.P.S. I guess the linked bug 122784 is a duplicate, but I didn't test that.
I have made some experiments. The painting while presentation is assigned to a layer "DrawnInSlideshow". I have to admit that I did not know that such a layer even existed. If the "mouse as pen" is already set in the slide show settings, then the layer is created, when leaving the presentation. But it arrives in edit mode with visible=false. I don't know why. It seems to be generated in SlideShowImpl::registerUserPaintPolygons(...). If I switch in presentation mode to Screen > Black and draw something, that drawing can be seen when back to normal presentation mode. And that drawing exists in edit mode. So bug 122784 is at least related. During my experiments I have got multiple layers all with layer name "DrawnInSlideshow". That should not happen. There is likely a condition missing, whether such layer already exists. If a file has already this situation, the superfluous layers have to be removed. They are in sub-file styles.xml in node draw:layer-set in office:master-styles. Before looking, why visibility is wrong here, bug 122784 has to be solved. I first thought, that it might be, that the layer is set to "locked", but that is not the case. I do not know, where in code painting with "mouse as pen" is done. A code pointer would be good.
Effectively unrelated to this is the new bug 131868, which I found while bibisecting this one - hah. Its commit 516ecd072f9dbfbacce77127a02b666ce387982d was fixing the paint functionality of the presentation mode, breaking the modified state of the document along the way. That is maybe a good code point to understand, how all this user / mouse painting is handled. Or ask Thorsten, who may have some further ideas :-)
(In reply to Jan-Marek Glogowski from comment #4) > > P.S. interestingly the lines are actually a multitude of consecutive, > ungrouped draw:line shapes, so even a small "round" line "explodes" into a > few hundred shapes. You can "see" these in the navigator, if you select "All > shapes" in the "Show shapes" drop-down box, but no modification is possible > (I had expected some delete action, at last). > That has already been in that way in LO 5.4. I still don't know how the show annotations are drawn, but they should be transformed to 'freeform lines'. If that is not possible, the lines should at least be grouped to reduce the noise in the Navigator. But that is a different topic and should go into a new issue. I have found already the reason for getting the additional DrawnInSlideshow-layers. @Franklin Weng: You can use the macro attached to bug 128730 to make the layer visible, so that you can change the show annotations in edit view.
(In reply to Jan-Marek Glogowski from comment #6) > > Its commit 516ecd072f9dbfbacce77127a02b666ce387982d was fixing the paint > functionality of the presentation mode, breaking the modified state of the > document along the way. That is maybe a good code point to understand, how > all this user / mouse painting is handled. Yes that helps. It leads to cws eraser01, where larger changes were made. I'll investigate further.
@Franklin Weng: And a solution without macros: In edit mode use menu Window > New Window. It opens the same presentation in a new view and there the painting is available in the center window. You can simple close the old window to work as usual.
Proposed patch in https://gerrit.libreoffice.org/c/core/+/92502
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eb2d669af61b8808d5819b16157c59d3c6c3e03b tdf#129898 Use layer DrawnInSlideshow in edit mode It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The state is now, that the lines are visible in most cases. I see only a small problem: When first time drawing in the slide show and coming back to edit mode, the edit window is not refreshed. This was not reproduced on Linux, but I see it in Windows. It is only a refresh problem. Switching to next slide and back or switching to Outline view and back to Normal view forces a repaint and the lines are visible. I don't know how to force a repaint of the edit window in this case.
There was "regression" here and bibisect but script put bibisectRequest which I remove now. After this much done, it would be fine to find someone push this. Maybe @Xisco has an idea.
So we have an almost working fix since LO 7.0. That fix is from 2020-05. The ticket is still assigned since ~1y. My preferred solution is a new bug based on comment 12, because according to it, there is just a minimal refresh bug left on Windows. Then this bug can be closed and referenced from the new one.
(In reply to Jan-Marek Glogowski from comment #14) > So we have an almost working fix since LO 7.0. That fix is from 2020-05. The > ticket is still assigned since ~1y. My preferred solution is a new bug based > on comment 12, because according to it, there is just a minimal refresh bug > left on Windows. Then this bug can be closed and referenced from the new one. I agree