Impress offers a way to include a slide from a separate odp presentation, using the menu option "Insert -> File". Choosing the "Link" option during the slide importation allows you to update the included slide should the original slide undergo changes. Very nice. There appears to be a problem with the implementation, however. There doesn't seem to be any way to visually know that a slide depends on (is linked to) an external "master" slide. So a user could / will unknowing make changes to a slide and then proceed to overwrite these changes the next time they open the Impress slide set by accepting the "update linked slides" prompt. This likely scenario leads to data loss. I'd suggest that a visual clue be added to show a slide that is linked to an external slide (I suspect that implementation cannot be too difficult). Ideally, the clue would indicate the file containing the linked slide and updates to a linked slide would propagate back to the external master slide or, probably safer, the linked slide would be read-only.
AFAIK this is no regression from 3.5 - and is present there too; as such I'll move it to the 3.5 MAB list instead [ eventually they will all be moved to 3.6 as 3.5 closes out it's development history but we like to keep this bug clean as we approach release ]. Thanks !
At least for me - in the slide-sorter these slides also have a visually distinct blue background - which makes it easier to see them vs.the others. Not sure what happens if you use a blue background but ... ;-)
(In reply to comment #2) > At least for me - in the slide-sorter these slides also have a visually > distinct blue background - which makes it easier to see them vs.the others. Not > sure what happens if you use a blue background but ... ;-) That sounds like a really good start... but my linked slides have the same white background color of the originals (using 3.6.0.0.beta3 (Build ID: 3e2b862) on Fedora). There is a blue border which appears in slide sorter around the currently highlighted slide, but this is independent of the linked status. If you have any insight as to what might make this highlighting appear, that would be wonderful. The data loss issue still applies as in Edit mode a normal user is unlikely to remember which slide displayed in the sorter was linked.
(In reply to comment #1) > AFAIK this is no regression from 3.5 - and is present there too; as such I'll > move it to the 3.5 MAB list instead [ eventually they will all be moved to 3.6 > as 3.5 closes out it's development history but we like to keep this bug clean > as we approach release ]. > > Thanks ! Excellent. Thank you for looking at this.
Mmh, when I try to reproduce this behavior I get an error when reopening the document. A message pops up: "This document contains one or more links to external data. Would you like to change the document, and update all links to get the most recent data?" -> Yes result in: 'The file could not be loaded!' How to reproduce: * Open Impress * Insert > File * Select a presentation * Check 'Link' * OK * Do some changes (delete something that is very obvious) * Save as ODP * Reopen Behavior: message pops up (see above) -> 'The file could not be loaded!' Tested using Linux Mint 14 x64 with LibreOffice 4.0.0.3 (= release) @Bug reporter: can you reproduce this using LibreOffice 4.0? (In reply to comment #1) [ eventually they will all be moved > to 3.6 as 3.5 closes out it's development history but we like to keep this > bug clean as we approach release ]. We are trying to do that NOW :-)
The import file one seems to behave strange.... When I imported 2 files the second one was highlighted as well blue in the sorter, but I assume thas was due to a another master, but I'm not sure. And I would like to remove the whole import again! So there shoudl be a kind of unlink option! Are there any plans to implement this?
Just to clarify Michael Meeks comment about the blue slide background seen in the sorter for imported slides (not just currently highlighted slide(s): sepp.mue@gmx.de is right, the blue background is due to the use of a different slide master in the imported slides. It has nothing to do with if a slide is linked or not.
Currently no plans to implement it no - but if you want to hack on it no doubt we can find some code-pointers to help out. Given the age of this issue, it seems like the request might be covered by being able to undo the update of linked masters [ is that an undo-able operation? ], I'm really not sure it should be on the MAB list. So removing for now. Ultimately it seems to me no different from various other operations which cannot be undone, which you could think of as loosing data.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-01
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
This is still present as described in the original issue. You have no way of seeing a slide is linked to another slide in another file, and any edits you do will be discarded if you update links on the next reopoen. I don't think this is a bug though, but rather a feature request? So revising the priority Adding the UX group to make a decision, so revising Version: 6.3.0.0.alpha0+ Build ID: beae6c7a7f163daad0d4dea63a3d403af2745fd1 CPU threads: 2; OS: Mac OS X 10.13.6; UI render: default; VCL: osx; TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2018-12-06_23:52:29 Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
The function is now located at Slide > Insert Slide from File... and the user has to confirm the update on loading. Any change to the linked slide are stored with the current presentation. For example, <1> <Hello World> <2> (with Hello World linked from Untitled2) changed to "Hello New World" will be saved and loaded unless the link is being updated. So we have two issues, first to know what slide(s) are linked (there is no information at the Navigator) and to support the user on update or not. Simplest solution is to just not permit changes of linked files. Something like a lock icon at the Navigator and at the status bar along with a message box "You cannot edit this slide directly. Do you want to open the linked file [Yes/No]" would be handy. Alternatively, we need to show some kind of diff as changes could have been made on both presentations. Sounds like a lot of effort.
(In reply to Heiko Tietze from comment #13) > So we have two issues One issue per report pls :p > first to know what slide(s) are linked (there is no information at the Navigator) and to support the user on update or not. Looking for similarity with Calc and Writer: In Calc linked data can be recognized by the cell content. In Writer linked content is placed in a section. So yes, a visible recognition is missing. Would that exist, then the problem is ~solved? Mind that Edit > Link to External Files is inactive in a presentation where a slide from another one is linked. Looks as (another) bug.
(In reply to Heiko Tietze from comment #13) > Simplest solution is to just not permit changes of linked files. We talked about this topic in the design meeting and agreed on this solution. But there should be a chance for the user to override and this could be done per infobar as known from Writer when a document is readonly. Sounds like an easyhack, though not too simple.